CVE-2026-111585 - это уязвимость, связанная с целочисленным переполнением в компоненте обработки экрана удаленного управления в версиях TeamViewer Full Client, Portable и Remote Control App до 15.83. Злоумышленник на удаленном хосте может воспользоваться этой уязвимостью, чтобы вызвать отказ в обслуживании или потенциально выполнить произвольный код с привилегиями процесса просмотра. Для эксплуатации уязвимости пользователю необходимо инициировать сеанс удаленного управления на хосте, контролируемом злоумышленником или скомпрометированном. Уязвимость имеет высокую степень опасности с оценкой CVSS 8,8 и была устранена в версии 15.83 и нескольких предыдущих версиях.
 

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

В худшем случае вредоносная машина может в любой момент вывести из строя TeamViewer на компьютере атакуемого. Было показано, как запустить на компьютере атакуемого выбранную программу (как на видео), при этом клиент (атакуемый) должен быть полностью обновлён, а его обычные средства защиты - включены, то есть речь идёт об удалённом выполнении кода.
 
TeamViewer - один из самых популярных инструментов удалённого доступа в мире, на который полагаются компании, ИТ-отделы и службы поддержки по всему миру. По словам производителя, он установлен более чем на 2,5 миллиардах устройств.

Внизу всё сводится к одной арифметической ошибке в коде, определяющем размер буфера экрана. Дальше будет показано, как эта ошибка привела к запуску программы на компьютере атакуюемого.
 

В сеансе TeamViewer участвуют две стороны. Хост предоставляет доступ к своему экрану, зритель отображает этот экран и отправляет данные с мыши и клавиатуры. В данном случае злоумышленник выступает в роли хоста, а атакующий - в роли зрителя. В начале сеанса хост сообщает зрителю геометрию экрана, который он собирается транслировать. Эта информация поступает в виде DisplayParams сообщения, содержащего, помимо прочего, ширину, высоту и глубину цвета (количество бит на пиксель, или bpp). Зритель использует эти данные для выделения декодирующей поверхности - буфера пикселей в памяти, в который распаковываются входящие обновления экрана перед их отображением.

Эта поверхность является объектом под названием CBitmapBuffer. Зритель обращается к ней только в том случае, если для сеанса недоступен аппаратный видеодекодер, в противном случае кадры передаются по протоколу AV1 или H.264. Это важно, поскольку выбор зависит не только от зрителя. Хост, который отказывается согласовывать видеокодеки, вынуждает зрителя использовать растровый формат, а затем хост выбирает кодек без потерь, обновления которого декодируются непосредственно в CBitmapBuffer. Другими словами, злоумышленник может по своему усмотрению направить пользователя на уязвимую страницу.

Сами обновления экрана поступают в виде прямоугольников сжатых пикселей. Они делают эту поверхность легкой мишенью: средство просмотра обрабатывает их в цикле, который выполняется до тех пор, пока открыт сеанс, поэтому он всегда готов декодировать следующее обновление, отправленное хостом. Соответствующие кодеры используют RLE (кодирование длин серий, схема, в которой повторяющийся пиксель сохраняется один раз вместе со счетчиком). Каждое обновление несёт в себе прямоугольник, который оно покрывает, и сжатые байты, а декодер RLE средства просмотра записывает распакованные пиксели на поверхность в позиции, вычисленной на основе этого прямоугольника. Граница доверия - это провод: прямоугольник, сжатые полезные данные и более ранняя геометрия DisplayParams - все это байты, контролируемые злоумышленником от удаленного узла.
 
 

Самый быстрый способ увидеть, как два числа расходятся - подставить выбранные злоумышленником размеры в расчет собственного размера конструктора. Запросите поверхность размером 32768 на 32768 пикселей с глубиной цвета 32 бита на пиксель - такую геометрию не может отобразить ни один реальный экран, но ничто на пути не препятствует ее отображению:

Рисунок 1. Собственная арифметика конструктора с размерами, выбранными злоумышленником. Запланированный размер превышает 32 бита, поэтому operator new[] выделяется около 4 МБ для поверхности, которая по-прежнему сообщает о том, что в ней почти 33 000 строк. Каждая строка после 31-й выходит за пределы допустимого диапазона.

Если передать декодеру обновление экрана, прямоугольник которого покрывает весь заявленный размер, то декодер запишет всю поверхность в буфер, который содержит лишь ее часть. В стандартной версии TeamViewer для Windows это приводит к чистому, повторяющемуся сбою: удаленному отказу в обслуживании при обычном сеансе.
 

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

Конструктор CBitmapBuffer вычисляет размер в байтах для каждой цветовой плоскости, а затем выделяет память. При вычислении размера используется 32-битная арифметика, при выделении памяти и последующей проверке границ используются значения, которые никогда не усекаются. Сокращаем до важных строк:

Рисунок 2. Умножение stride * (height + 0x10) выполняется в 32-битном формате и только после этого расширяется до 64 бит для operator new[]. Продукт оборачивается, поэтому выделенный объем может быть произвольно меньше, чем поверхность, которую он должен занимать, в то время как strideзаявленная ширина и заявленная высота сохраняют свои полные, не усеченные значения.

Вот что скрывается за рисунком 1: при циклическом сдвиге operator new[] остается буфер, занимающий лишь малую часть поверхности, которую, по мнению остальной части программы, она занимает.

Декодер, который сверял бы каждую запись с реальным размером выделенной памяти, справился бы с этой задачей. Декодеры RLE сверяют, но не с тем значением. Они сравнивают прямоугольник обновления с заявленной шириной и высотой поверхности, а не с выделенным размером:

Рисунок 3. Прямоугольник проверяется на соответствие заявленной поверхности, поэтому прямоугольник, занимающий всю поверхность, (0, 0, 32768, 32768) проходит проверку. Адрес записи - base + y*stride, а выделенная память покрывает только около 31 строки, поэтому каждая последующая строка записывает данные за пределы выделенной памяти. При проверке не учитывается реальный размер выделенной памяти, поэтому проверка не учитывает перенос.

В этом и заключается ошибка: при выделении памяти и проверке границ считываются два разных числа для одной и той же поверхности, а злоумышленник выбрал такие размеры, при которых эти числа отличаются почти на 2^32. Выделение памяти уменьшилось, а разрешение на запись - нет.

Наш первый подход заключался в том, чтобы проверить, как мы можем контролировать размеры и доходят ли они до уязвимого кода в неизменном виде или какой-то уровень ограничивает их по пути. Мы проследили путь получения данных и обнаружили, что ничего не происходит: размеры экрана, заявленные хостом, используются для определения размеров области рисования без каких-либо ограничений.

Это означает, что вредоносный или скомпрометированный хост может вызвать ошибку внутри обычного установленного сеанса, используя только те сообщения, которые уже поддерживаются протоколом. Мы подтвердили это в нашей лаборатории. Доставка не является препятствием.

Вывести цель из строя несложно. Важнее то, что злоумышленник может контролировать размер буфера. Размер буфера составляет (stride * (height + 16)) mod 2^32, поэтому злоумышленник может выбрать такие размеры, при которых буфер будет практически любого размера, а запись все равно будет занимать около 2^32 байт.

Размеры в 32768 квадратов, использованные выше, дают буфер размером в несколько мегабайт, который распределяется по всей куче. Другой вариант - намеренно уменьшить его: Width = 0xFFFFFFF5, Height = 1, BPP = 8 выделение памяти сокращается до буфера размером примерно 0x440 байт, который попадает в класс кучи с небольшим размером, рядом с объектами, которые может использовать злоумышленник. Таким образом, этот примитив - не просто масштабный сбой: это масштабное линейное переполнение кучи с содержимым, созданным злоумышленником, размер которого выбирает сам злоумышленник.

Сбой - это самый простой исход. Серьёзность последствий зависит от того, приведёт ли та же запись к выполнению кода на устройстве с полным уровнем защиты. Испорченная поверхность - это активный объект, который зритель позже вызывает через указатель в своем первом поле, поэтому перезапись этого указателя перенаправляет вызов. Control Flow Guard и DEP призваны предотвращать именно такие ситуации, но эта защита была обойдена и перенаправлен вызов в WinExec и запустили на устройстве просмотра код, выбранный злоумышленником.

Мы добились удаленного выполнения кода, при этом каждая ссылка работает с поставляемыми двоичными файлами. В демонстрационной версии повреждающие байты размещаются с помощью перехвата на стороне хоста, который заменяет полезную нагрузку Wire Tile. Он проходит по тому же пути и заменяет только этап очистки кучи.

Поверхность доступна в конфигурации по умолчанию. Достаточно принять сеанс, и это нормальный режим работы продукта. Команда безопасности TeamViewer Product Security подтвердила обнаружение с базовой оценкой CVSS 3.1 8,8 (высокая), вектор AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, где UI:R означает, что атакующий принимает сеанс.

Ошибка связана с умножением в 32-битной системе. Процедура, предназначенная только для отображения удалённого экрана, привела к удалённому выполнению кода на компьютере, на котором он просматривался, поскольку на пути записи не было ничего, что проверяло бы соответствие записи фактически выделенным байтам.

Этот метод был применён не только к TeamViewer, где бы ни вычислялся размер для выделения памяти и ни проверялись границы отдельно сохраненного измерения, убедитесь, что эти два значения никогда не будут противоречить друг другу и что ширина, которую вы фактически выделили, соответствует действительности. При выделении памяти и проверке, которая его сопровождает, не должно быть расхождений в вычислениях.
 
https://www.cve.org/CVERecord?id=CVE-2026-111585