37 уязвимостей в различных реализациях VNC

Павел Черемушкин из Лаборатории Касперского проанализировал различные реализации системы удалённого доступа VNC (Virtual Network Computing) и выявил 37 уязвимостей, вызванных проблемами при работе с памятью. Выявленные в реализациях VNC-серверов уязвимости могут быть эксплуатированы только аутентифицированным пользователем, а атаки на уязвимости в клиентском коде возможны при подключении пользователя к серверу, контролируемому злоумышленником.

Наибольшее число уязвимостей обнаружено в пакете UltraVNC, доступном только для платформы Windows. Всего в UltraVNC выявлены 22 уязвимости. 13 уязвимостей могут потенциально привести к выполнению кода в системе, 5 к утечке содержимого областей памяти и 4 к отказу в обслуживании.
Уязвимости устранены в выпуске 1.2.3.0.

В открытой библиотеке LibVNC (LibVNCServer и LibVNCClient), которая используется в VirtualBox, выявлено 10 уязвимостей.
5 уязвимостей (CVE-2018-20020, CVE-2018-20019, CVE-2018-15127, CVE-2018-15126, CVE-2018-6307) вызваны переполнением буфера и могут потенциально привести к выполнению кода. 3 уязвимости могут привести к утечке информации, 2 к осуществлению отказа в обслуживании.
Все проблемы уже устранены разработчиками, но изменения пока отражены только в master-ветке.

В TightVNC (тестировалась кросс-платформенная устаревшая ветка 1.3, так как актуальная версия 2.x выпускается только для Windows), обнаружено 4 уязвимости. Три проблемы (CVE-2019-15679, CVE-2019-15678, CVE-2019-8287) вызваны переполнением буфера в функциях InitialiseRFBConnection, rfbServerCutText и HandleCoRREBBP, и потенциально могут привести к выполнению кода. Одна проблема (CVE-2019-15680) приводит к отказу в обслуживании. Несмотря на то, что разработчики TightVNC были уведомлены о проблемах ещё в прошлом году, уязвимости так и остаются неисправленными.

В кросс-платформенном пакете TurboVNC (форк TightVNC 1.3, использующий библиотеку libjpeg-turbo), найдена только одна уязвимость (CVE-2019-15683), но она является опасной и при наличии аутентифицированного доступа к серверу, даёт возможность организовать выполнение своего кода, так как при переполнении буфера имеется возможность контролировать адрес возврата. Проблема устранена 23 августа и не проявляется в актуальном выпуске 2.2.3.

Источник: opennet.ru

Добавить комментарий