Разработчики Firefox рассматривают вопрос о полной блокировке Java-функционала

Разработчики Firefox рассматривают вопрос о полной блокировке Java-функционала

Некоторое время назад независимые исследователи продемонстрировали, как эксплойт-код BEAST может без особенного труда расшифровать данные, передаваемые по защищенному Интернет-соединению. Теперь производители браузеров размышляют над тем, как побороть реализованный в BEAST метод компрометации данных; специалисты Mozilla, похоже, готовы пойти даже на весьма радикальные шаги.


Атакующий код Browser Exploit Against SSL/TLS внедряет в SSL-сеанс особый сценарий на JavaScript; с высокой степенью вероятности предсказывая возможное расположение защищаемой информации в потоке данных, его создатели смогли в конечном счете добиться извлечения и восстановления конфиденциальных сведений. Разработчики популярного обозревателя Firefox, пытаясь найти "вакцину", похоже, всерьез задумались о глобальных хирургических мерах: по имеющейся информации, в числе возможных решений они рассматривают полный отказ от обработки Java в обозревателе.

По словам специалистов, они понимают, что подобный шаг весьма негативно повлияет на удобство работы пользователей в Интернете, однако в силу того, что на данный момент нет никакой информации о возможных контрмерах со стороны Oracle (которая ответственна за Java), а также по причине серьезности угрозы, представляемой BEAST-подобными атаками, возможно внесение всех версий Java-плагина Firefox в стоп-список. Пока что разработчиков все еще одолевают сомнения, и они взвешивают положительные и отрицательные стороны обсуждаемого решения.

Заметим, что создатели Google Chrome, например, столь резких мер принимать не стали. Они придумали другой вариант, который уже  реализовали в тестовой версии своего браузера: сообщения разбиваются на случайно перемешиваемые фрагменты, так что в случае перехвата и исследования данных эксплойт-коду и криптоаналитику придется иметь дело уже не со связным текстом, а с беспорядочным набором данных. Такой подход, впрочем, вызвал проблемы совместимости с некоторыми веб-сайтами, и пока не известно, сумеют ли разработчики Google их разрешить. Занимается этой проблемой и Microsoft, но до сего момента никаких конкретных вариантов корпорация не предложила; в каком направлении работают ее специалисты, соответственно, тоже еще не ясно.

The Register

Письмо автору

Эксперты: за год число вредоносных opensource-компонентов возросло в 11 раз

В 2025 году в компании CodeScoring зарегистрировали 457 тыс. вредоносных библиотек с открытым исходным кодом — в 11 раз больше, чем в предыдущем году. Зафиксировано также 14 тыс. новых уязвимостей в таких компонентах.

По словам специалистов, сохраняют актуальность и более ранние неприятные находки — к примеру, RCE-уязвимость Log4Shell, которая все еще присутствует в 15 тыс. сторонних библиотек. Публикация подобных пакетов грозит атаками на цепочку поставок.

В уходящем году также зафиксировано появление новой, еще более опасной угрозы — самоходного червя Shai Hulud, способного создавать новые репозитории и воровать конфиденциальные данные с CI/CD-платформ.

В связи с бурным ростом популярности ИИ объявился новый вектор атаки — slopsquatting: злоумышленники начали использовать склонность больших языковых моделей (БЯМ, LLM) к галлюцинациям для внедрения в легитимные проекты небезопасного кода.

Из-за этой особенности умный помощник по разработке может ошибиться и вместо легитимной библиотеки предложить для использования вредоносную со схожим названием. По данным CodeScoring, в России ИИ-ассистентов применяют 30% разработчиков, и потенциально опасные галлюцинации происходят у LLM в 20% случаев.

Чтобы защититься от атак на цепочку поставок, эксперты советуют вести тщательный учет компонентов, используемых для сборки софта, при установке библиотек выставлять запрет на исполнение скриптов, а также следовать стандарту ГОСТ Р 56939-2024 и активнее внедрять технологии безопасной разработки.

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