Опера не спешит закрывать уязвимость

Опера не спешит закрывать уязвимость

Если вы считаете, что знакомы с языком HTML и принципами работы браузеров, попробуйте прямо сейчас ответить для себя на вопрос — может ли картинка вставленная через тег IMG сделать редирект той странице, на которой она вставлена? Странный вопрос, скажете Вы. Тем не менее ответ на него не такой однозначный «нет», как кажется на первый взгляд.

В браузере Опера это возможно, что даёт огромное поле деятельность по угону пользовательских аккаунтов, особенно с учетом того что уязвимость до сих пор не закрыта. А по заявлениям компании Опера — будет оставаться незакрытой еще неопределенное время.

В начале октября была обнаружена уязвимость в браузере Опера 12, которая позволяет через вставленную картинку и определенным образом отданные заголовки для нее перенаправлять посетителя на другой сайт. Атаке через эту уязвимость успели подвергунться крупнейшие сайты рунета, позволяющие вставлять картинки через УРЛ (например, rutracker — ссылка). Сайты, поддержкой которых занимаюсь я сам также были атакованы, пишет habrahabr.ru.

Как работает

Если в коде открываемой странице злоумышленник может разместить тэг вида:
<img src="http://evil.com/evil.png">
(где evil.com подконтрольный ему сервер)
и отдать при запросе http://evil.com/evil.png следующие заголовок:

Refresh: 0; url=data:application/internet-shortcut,[INTERNETSHORTCUT]%0D%0AURL=http://evil.com/

то браузер Опера не спросив и не предупредив пользователя, совершит переход по этому адресу.

А уже там может быть что угодно, начиная от формы ввода логина и пароля в оформлении атакуемого ресурса. В случае с моими сайтами — требовали ввести свой номер телефона (так и не понял, зачем им это было нужно).

Подвержены все сайты, которые позволяют пользователям вставлять свои картинки через УРЛ, а это возможно практически везде, начиная с форумов на phpbb, ЖЖ, Хабрахабра (!) и заканчивая письмами в mail.ru (где картинки в письме загружаются по умолчанию).

Официальный ответ Opera

В диалоге представителя Opera в России Ильи Шпанькова (shpankov) и администрации rutracker.org прозвучли следующие заявления:
«Как выяснилось, в Opera уязвимости нет и проблема не является результатом ошибок в браузере, но совместно с разработчиками Opera мы нашли решение, как избежать подобных проблем в дальнейшем, и это решение будет применено в ожидаемой скоро новой версии Opera 12.1»

А также привел слова технических специалистов Opera Software:
«У нас в Opera принято помогать сайтам, даже когда они делают что-то неправильно. Поэтому в Opera 12.10 мы отключим следование шорткатам в контенте, загружаемом внутри тега . Это именно то, что согласно ожиданиям веб-сайта должен делать браузер, хотя на самом деле такое поведение не описывается ни одним стандартом. Таким образом, мы сделаем то, что они хотят, очень скоро.»

Выводы

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

Что же касается ситуации в целом, то всё очень и очень грустно. Браузер Опера на данный момент занимает в РуНете порядка 15%, при этом открыто заявляется что «проблемы негров шерифа не волнуют» и переадресация сайтов черт знает куда без ведома пользователя «уязвимостью не является».
Явные же проблемы пользователей, разработчики почему то называют проблемами «владельцев сайтов». Хотя их продуктом пользуются не владельцы сайтов, а люди, чью личную информацию браузер Опера подвергает опасности.

Да, они заявляют что уязвимость исправлена в следующей версии браузера (12.10), но не называют даже примерных сроков ее релиза. А тем временем любой — даже не хакер — любой вообще человек, воспользовавшись информацией об этой уязвимости (опубликованной на днях на РуТрекере), может причинять реальные проблемы и страдания пользователям этого браузера.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Две уязвимости в 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-интерфейс ядра.

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

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

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