Три дыры в антивирусе Avira ведут к одному финалу — локальный пользователь захватывает систему целиком

Обновление удаляет что попало, ускорение запускает что угодно, очистка стирает всё подряд…

В Avira Internet Security обнаружили сразу три уязвимости в модулях , которые выполняют служебные задачи с правами SYSTEM. Проблемы затронули обновление компонентов, ускорение работы системы и очистку временных файлов. На первый взгляд речь идет о штатных внутренних механизмах антивируса, но каждая из этих частей получила доступ к чувствительным операциям на уровне всей ОС, а проверки оказались слишком слабыми. В результате локальный пользователь может либо удалить произвольный файл от имени SYSTEM, либо довести атаку до полноценного повышения привилегий .

Уязвимыми оказались версии до 1.1.109.1990 включительно. Исправления вошли в выпуск 1.1.114.3113. Исследователи описали три сценария: произвольное удаление файла в модуле обновления с идентификатором CVE-2026-27748, небезопасную десериализацию в модуле ускорения системы под CVE-2026-27749 и удаление произвольной папки через состояние гонки типа time-of-check to time-of-use, или TOCTOU, в модуле очистки под CVE-2026-27750. Первая ошибка полезна сама по себе. Две другие уже дают прямой путь к SYSTEM.

Модуль обновления отвечает за доставку новых компонентов Avira и в ходе работы взаимодействует со сторонними исполняемыми файлами в каталоге C:\ProgramData\OPSWAT\MDES SDK\. Некоторые из таких файлов удаляются во время цикла обновления. Модуль ускорения следит за производительностью и пытается оптимизировать работу системы. При включении режима Performance Booster процесс Avira.SystemSpeedup.RealTimeOptimizer.exe запускается с правами SYSTEM. Модуль очистки ищет временные данные, кэш и прочий системный мусор, а после подтверждения со стороны пользователя удаляет найденное тоже с максимальными привилегиями.

Общая проблема у всех трех компонентов одна: привилегированный код слишком доверяет путям и данным, с которыми работает. Как только злоумышленник получает возможность подменить файл, папку или сериализованный объект, SYSTEM начинает выполнять чужую логику от своего имени.

Цифровой контроль неизбежен. Подпишитесь на нас

Две из трех атак опираются на старый и хорошо известный прием с каталогом C:\Config.msi. Схема завязана на службу установки Windows и ее механизме отката. Если заставить привилегированный процесс удалить C:\Config.msi, затем заново создать каталог с файлами отката .rbs и .rbf, а после этого вызвать сбой установки MSI-пакета, служба Windows Installer обработает сценарии отката с правами SYSTEM.

Дальше цепочка уже стандартная: через откат можно подложить динамическую библиотеку в каталог C:\Program Files\Common Files\microsoft shared\ink\HID.DLL, затем вызвать экран безопасности сочетанием CTRL+ALT+DEL и запустить osk.exe. Экранная клавиатура загрузит библиотеку, после чего злоумышленник получит оболочку SYSTEM.

Здесь есть важная оговорка. Удаление папки и удаление файла работают по-разному. В одном случае атака использует перенаправление удаления каталога, и такая техника по-прежнему работает. В другом случае злоупотребление строилось вокруг удаления альтернативного потока данных ::$INDEX_ALLOCATION. Начиная с Windows 11 24H2 Microsoft закрыла этот вариант, поэтому прежний трюк с удалением файла в новых сборках уже не дает тот же результат.

Первая уязвимость находится в модуле обновления. Во время обновления компонент удаляет файл C:\ProgramData\OPSWAT\MDES SDK\wa_3rd_party_host_32.exe. Проблема в том, что перед удалением путь не проверяется на наличие символьной ссылки . Если вместо обычного файла заранее подготовить такую ссылку, привилегированный процесс спокойно пройдет по ней и удалит уже другую цель.

Для демонстрации исследователи использовали набор утилит Джеймса Форшоу для проверки символьных ссылок. Сначала они создали каталог:

PS C:\temp> mkdir "C:\ProgramData\OPSWAT\MDES SDK"

Затем превратили его в точку подключения, ведущую в пространство имен \RPC Control:

PS C:\temp> .\CreateMountPoint.exe "C:\ProgramData\OPSWAT\MDES SDK" "\RPC Control"

После этого была создана символьная ссылка на целевой файл:

PS C:\temp> .\CreateSymlink.exe "\RPC Control\wa_3rd_party_host_32.exe" "C:\windows\system32\foobar.txt"  Opened Link \RPC Control\wa_3rd_party_host_32.exe -> \??\C:\windows\system32\foobar.txt: 00000158  Press ENTER to exit and delete the symlink

Когда пользователь запускал обновление, модуль удалял уже не ожидаемый служебный файл, а C:\windows\system32\foobar.txt. Монитор процессов Procmon показывал, что удаление выполнялось именно процессом SYSTEM. На версиях Windows до 24H2 такой примитив можно было объединить с приемом через Config.msi и довести атаку до повышения привилегий . На более новых сборках последствия зависят от выбранной цели: от отказа в обслуживании до нарушения целостности системы.

Вторая уязвимость связана с модулем ускорения. Процесс Avira.SystemSpeedup.RealTimeOptimizer.exe, работающий с правами SYSTEM, читает файл C:\ProgramData\Avira\SystemSpeedup\temp_rto.dat и десериализует его содержимое через BinaryFormatter из .NET. Никаких фильтров или проверки типов в этом месте нет. Каталог ProgramData по умолчанию позволяет локальным пользователям создавать файлы, поэтому обычный пользователь может подложить собственный temp_rto.dat и дождаться, пока привилегированный процесс его обработает.

Исследование бинарного файла через dnSpy показало три точки десериализации: LoadDBFromFile, LoadCrashRestoreKnowledge и LoadProcessExceptionKnowledge. Основной интерес вызвала функция LoadCrashRestoreKnowledge, потому что в ней файл открывается напрямую, а затем без дополнительных ограничений передается в BinaryFormatter.Deserialize():

private void LoadCrashRestoreKnowledge()  {if (File.Exists(this.CrashRestoreKnowledgeBasePath)){ try {  FileStream fileStream = new FileStream(this.CrashRestoreKnowledgeBasePath, FileMode.OpenOrCreate);  BinaryFormatter binaryFormatter = new BinaryFormatter();  Dictionary crashRestoreKnowledge = this._crashRestoreKnowledge;  lock (crashRestoreKnowledge)  {this._crashRestoreKnowledge = (Dictionary)binaryFormatter.Deserialize(fileStream);  }  fileStream.Close(); } catch (Exception ex) {  Log.Warning(LogModule.General, "LoadCrashRestoreKnowledge exception: " + ex.Message); }}  }

Путь к файлу задается через свойство:

public string CrashRestoreKnowledgeBasePath { get; private set; } =Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) +"\\Avira\\SystemSpeedup\\temp_rto.dat";

Значение CommonApplicationData в данном случае соответствует каталогу C:\ProgramData. На чистой установке файла temp_rto.dat еще нет, и это упрощает атаку. Если же файл уже существует и не дает записать новое содержимое, исследователи отмечают, что предыдущая уязвимость с удалением файла помогает освободить место и создать объект заново.

Опасный код срабатывает, когда пользователь включает режим Performance Booster через графический интерфейс. Сам интерфейс работает от имени ограниченного пользователя, но после активации запускается привилегированный процесс, который читает temp_rto.dat. В Procmon видно, как SYSTEM обращается к этому файлу.

Для демонстрации использовалась утилита ysoserial.net. Полезная нагрузка строилась так:

ysoserial.exe -f BinaryFormatter -g TypeConfuseDelegate -c "whoami > c:\pwned.txt" -o raw > c:\temp\pwned.bin

После генерации файл копировался в каталог Avira:

C:\temp> copy c:\temp\pwned.bin C:\ProgramData\Avira\SystemSpeedup\temp_rto.dat 1 file(s) copied.

Дальше пользователь отключал флажок Performance Booster, подменял файл и снова включал функцию. В момент десериализации код выполнялся уже с правами SYSTEM, а команда из полезной нагрузки создавала файл c:\pwned.txt. Исследователи называют этот путь самым чистым из трех: без гонки, без узкого временного окна, достаточно подложить файл и щелкнуть по переключателю.

Третья проблема затронула модуль очистки. Логика там построена в два этапа: сначала Optimizer сканирует систему, находит временные каталоги и мусор, затем после подтверждения запускает удаление. Ошибка возникает между этими шагами. Во время проверки путь считается безопасным, но перед фактическим удалением его уже не проверяют повторно. Так возникает классическое состояние гонки TOCTOU , когда результат проверки и дальнейшее использование объекта расходятся во времени.

Сценарий атаки выглядит так. Локальный пользователь создает каталог, например в C:\temp, и ждет не менее десяти минут, потому что Optimizer считает мусором только достаточно старые временные папки. После этого пользователь открывает модуль очистки, запускает сканирование и дожидается, пока каталог появится в списке System Junk - Temporary System Files. На этом этапе путь уже прошел проверку.

Перед нажатием кнопки Optimize исследователь запускает вспомогательную утилиту FolderOrFileDeleteToSystem.exe, затем заменяет свой каталог на соединение с каталогом C:\config.msi. Снаружи для Optimizer все выглядит как та же самая папка, которую модуль уже проверил. Во время очистки привилегированный процесс идет по новому маршруту и удаляет уже C:\config.msi. Procmon подтверждает, что удаление выполняется от имени SYSTEM.

Дальше снова срабатывает известная цепочка с откатом MSI-установщика. В систему подбрасывается HID.DLL, библиотека попадает в каталог Microsoft Ink, а запуск osk.exe через экран безопасности дает оболочку SYSTEM.

В сумме все три уязвимости складываются в довольно неприятную картину. Три разных модуля, три отдельных ошибки, но одна и та же причина: код с максимальными привилегиями работает с файлами и путями так, будто локальный пользователь не может на них повлиять. Самым универсальным исследователи считают примитив произвольного удаления файла, потому что его можно использовать и отдельно, и как подготовительный этап. Самый прямой путь к SYSTEM дает небезопасная десериализация в модуле ускорения. Гонка в модуле очистки выглядит более капризной, но до сих пор остается вполне рабочей дорогой к полному захвату системы.