Две уязвимости в ksmbd Linux позволяют получить root через SMB

Две уязвимости в ksmbd Linux позволяют получить root через SMB

Две уязвимости в ksmbd Linux позволяют получить root через SMB

Без лишней мистики: исследователь в области кибербезопасности BitsByWill подробно разобрал две критические уязвимости в ksmbd — встроенном в ядро Linux SMB-сервере. Речь о CVE-2023-52440 и CVE-2023-4130 — и самое неприятное, что они отлично склеиваются в рабочую эксплойт-цепочку.

Первая уязвимость, CVE-2023-52440, описывается как контролируемое SLUB-переполнение в функции ksmbd_decode_ntlmssp_auth_blob().

Как пишет BitsByWill, длина sess_key_len контролируется пользователем, и при определённой подаче данных можно переполнить фиксированный буфер sess_key во время вызова cifs_arc4_crypt. Проще говоря — достаточно модифицировать одну строку в ntlm-клиентской библиотеке (в примере — Impacket), чтобы сгенерировать специально подготовленное NTLM-сообщение и получить неаутентифицированное удалённое переполнение буфера с контролем размера и содержимого.

Вторая уязвимость, CVE-2023-4130, — это чтение за пределами буфера (OOB read) в smb2_set_ea(). Из-за плохой проверки расширенных атрибутов (EA) злоумышленник с правом записи на шаре может заставить ksmbd неправильно интерпретировать структуру и считать дополнительные записи. В результате соседние данные кучи попадают в xattr, откуда их можно извлечь через SMB3 queryInfo. То есть брешь позволяет вытянуть части памяти ядра и, например, сломать KASLR.

И вот где всё становится опасно: переполнение даёт запись, чтение даёт утечку. Связав CVE-2023-52440 и CVE-2023-4130, BitsByWill показал рабочий путь до реального ROP-эксплойта.

Для демонстрации потребовались учётные данные пользователя с правом записи на шару, поэтому исследователь пишет о 0-click с аутентификацией — формулировка спорная, но смысл понятен: если админ разрешил анонимную запись в шаре, шанс эксплуатации становится ещё выше.

Авторы анализа подчёркивают практические сценарии: модификация таблиц страниц для произвольного чтения/записи, вынимание секретов из соседних процессов или подготовка ROP-цепочки для исполнения кода в контексте ядра. Всё это — классика эскалации привилегий, но в данном случае — прямо через SMB-интерфейс ядра.

Патчи уже вышли, и производители/поддерживающие дистрибутивы закрывали эти баги, но реальная угроза — не только в уязвимом коде, а в конфигурациях и устаревших системах. Как обычно, напомним: открытые для записи шар-ресурсы, устаревшее ПО и несвоевременное обновление — идеальная среда для подобных атак.

Подпишитесь на новости

Джейлбрейк для iPhone пережил апдейт до iOS 27.2 при включённом Lockdown

Даже самый строгий режим защиты iPhone не спас от эксплойта. Команда Calif показала iPhone 18 Pro с включённым Lockdown Mode и джейлбрейком, который, судя по демонстрации, сохранился после обновления до iOS 27.2. Установить свежую систему оказалось недостаточно, чтобы вернуть устройство в исходное состояние.

Видео исследователи опубликовали в X. В ролике на смартфон отправляют PDF через AirDrop, а пользователь принимает и открывает файл.

Затем демонстрируется работа джейлбрейка — снятия системных ограничений iOS. После установки обновления и перезагрузки признаки взлома остаются.

Однако демонстрация не показывает, что телефон можно взломать, просто находясь рядом. Техническую цепочку Calif не раскрыла, поэтому по ролику нельзя установить все условия атаки.


Стоит также учитывать, что сохранение джейлбрейка после обновления не доказывает, что тем же способом можно взломать изначально чистый iPhone, уже работающий на iOS 27.2. Этот вопрос пока открыт. Ранее команда сообщала, что передаёт найденные уязвимости Apple и не планирует выпускать общедоступный инструмент для джейлбрейка.

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

RSS: Новости на портале Anti-Malware.ru