| · | 23.10 | Около 10% выходных узлов Tor были вовлечены в атаку по перехвату SSH-подключений (30 +6) |
|
Опубликованы детали инцидента, в ходе которого злоумышленникам удалось получить контроль над 333 выходными узлами сети Tor (всего в Tor около 3000 выходных узлов) и организовать на них перехват нешифрованного трафика и перенаправление SSH-соединений. Атака началась 2 октября (в пятницу вечером), но была выявлена и начала блокироваться 4 октября. 5 октября все скомпрометированные серверы были отключены операторами или самими атакующими. Разбирательство показало, что атакующие получили доступ к серверам за два месяца до начала атаки на пользователей Tor и установили в скомпрометированных системах вредоносное ПО Ebury 1.8.3.
Целью атаки был перехват паролей, ключей и конфиденциальной информации в транзитном незашифрованном трафике, а также захват паролей к SSH. При анализе незашифрованного трафика атакующие сосредоточились на обращениях без шифрования к почтовыми серверам. Для стимулирования отката на работу без шифрования на выходных узлах было произведено блокирование сетевых портов, применяемых для организации шифрованного канала связи с почтовыми серверами. Нешифрованный трафик анализировался на лету. Для сбора паролей к SSH было организовано перенапрваление SSH-запросов на один из 12 серверов злоумышленников. Данные серверы принимали соединение по SSH и выводили запрос пароля от имени сервера, к которому осуществлялось подключение. Так как хостовые ключи не совпадали, ssh на стороне клиента выдавал предупреждение о подключении к неизвестному серверу. Если пользователь игнорировал данное предупреждение и вводил пароль для подключения, то вредоносный сервер транслировал через себя подключение к легитимному целевому SSH-серверу, сохранял введённый жертвой пароль и перехватывал информацию о действиях в SSH-сеансе. Параллельно осуществлялось подключение к целевому серверу с захваченным паролем и установка на него вредоносного ПО Ebury. Получая контроль над Linux-серверами, не являющимися выходными узлами Tor, атакующие меняли настройки в файле torrc и превращали их новые вредоносные выходные узлы Tor.  Для определения всех вредоносных выходных узлов выявивший проблему исследователь использовал утилиту exitmap для перебора всех выходных узлов, установки SSH-соединения через каждый из них и проверки факта пренаправления запроса. Как именно атакующие получили доступ к захваченным Tor-узлам пока не ясно, среди прочего высказываются предположения о компрометации операторов хостинга.
| ||
|
Обсуждение (30 +6) |
Тип: Проблемы безопасности |
| ||
| · | 23.10 | Аnthropic развивает технику для формальной верификации существующего ПО при помощи AI (102 +3) |
|
Компания Аnthropic представила результаты экспериментов по использованию AI-моделей для формальной верификации надёжности и безопасности уже существующих проектов. В ходе эксперимента при помощи AI-моделей для 123 открытых библиотек, протестированных в инфраструктуре OSS Fuzz, были сгенерированы математические доказательства отсутствия ошибок при работе с памятью.
Проверка проводилась на уровне скомпилированного ассемблерного кода для архитектуры RISC-V. Общий объём сгенерированных доказательств составил около 180 миллионов строк кода для системы верификации Rocq Prover (около 600 тысяч строк на бинарный файл с 18 тысячами RISC-V инструкций). Доказательства формировались путём автоматического преобразования существующих fuzzing-тестов в формальные спецификации, после чего AI-модель Claude доказывала, что при любых входных данных объёмом до 64 МБ в программе не возникает сбоев. В процессе построения доказательств AI-модель смогла выявить и подготовить исправления для сотен ошибок, ранее не замеченных при fuzzing-тестировании. Среди прочего, были выявлены уязвимости, приводящие к переполнению буфера при обработке определённых входных данных (например, CVE-2026-56132 в libexpat), а также логические ошибки. Помимо этого, AI-модель была использована для доказательства соответствия реализации алгоритма zlib в ядре Linux спецификации RFC 1950. Также на языке Rust был сгенерирован интерпретатор для подмножества языка Python, для которого при помощи инструментария Verus подготовлено формальное доказательство соответствия семантике CPython. Для сравнения поведения с CPython было выполнено более 1.7 миллионов случайно сгенерированных Python-программ. В 99.95% случаев результаты выполнения этих программ в новой реализации и в CPython совпали, а выявленные расхождения оказались известными граничными случаями. Проведённая формальная верификация гарантирует соответствие спецификации, но полностью не исключает возникновение проблем с безопасностью, так как остаются неформализованными риски, вызванные проблемами с многопоточностью, динамическим связыванием и аномальным поведением реального оборудования. Ключевым преимуществом предложенного подхода является работа непосредственно с бинарными файлами, что позволяет обойтись без необходимости переписывания существующего кода на формально верифицируемых языках.
| ||
|
Обсуждение (102 +3) |
Тип: К сведению |
| ||
| · | 23.10 | Для уязвимостей PHP2Shell анонсирован первый эксплоит, обходящий рандомизацию адресов (44 +7) |
|
Исследователи из компании VulnCheck заявили о получении первого эксплоита для уязвимости PHP2Shell (CVE-2026-109618б), обходящего механизм рандомизации адресов (ASLR) на системах x86-64 с типовой конфигурацией PHP. Эксплоит позволяет атаковать системы с PHP 8.4.10-8.4.26 в конфигурации по умолчанию. Ранее трудность определения раскладки памяти в модуле mod_php мешала реализации эксплоита, позволяющего добиться выполнения кода на реальных системах. Для обхода ASLR в эксплоите задействована утечка информации об адресах в коде отображения информации об ошибках.
Заявлено, что доступ к рабочему эксплоиту предоставлен только клиентам, занимающимся защитой информации, но злоумышленники могут воссоздать используемую технику при помощи AI. Для обходного пути блокирования утечки информации о раскладке адресов следует выставить в php.ini параметр "display_errors=off", помимо ранее опубликованных рекомендаций. VulnCheck также упоминает о том, что на GitHub появились сотни прототипов эксплоитов, но только единицы оценены как рабочие и лишь один прототип был способен обойти ASLR. Помимо этого, директор Cloudflare сообщил, что компания фиксирует миллионы попыток эксплуатации уязвимостией PHP2Shell, при том, что за 10 часов до анонса наличия уязвимостей таких попыток уже были тысячи, а через 2 часа после официального раскрытия информации достигли сотен тысяч. Судя по всему, в атаках используются прототипы эксплоитов, лишь фиксирующие наличие уязвимых версий PHP, так как пока нет информации о подтверждённых фактах взлома через уязвимости PHP2Shell. По данным компании Amazon первые попытки эксплуатации зафиксированы развёрнутыми honeypot-системами ещё 17 октября, т.е. за 3 дня до утечки первых сведений об CVE-идентификаторах. Активность усилилась 21 октября, за 12 часов до публикации корректирующих обновлений PHP, в это время зафиксированы попытки атак с использованием нескольких вариантов прототипов эксплоитов. Попытки атак до официального раскрытия информации также зафиксировала компания Hadrian.
| ||
|
Обсуждение (44 +7) |
Тип: Проблемы безопасности |
| ||
| · | 22.10 | Релиз менеджера паролей KeePassXC 2.8 (141 +28) |
|
Опубликован выпуск открытого кроссплатформенного менеджера паролей KeePassXC 2.8.0, предоставляющего средства для безопасного хранения обычных паролей, одноразовых паролей (TOTP), SSH-ключей и прочей информации, которую пользователь считает конфиденциальной. Данные могут храниться как в локальном зашифрованном хранилище, так и во внешних облачных хранилищах. Код проекта написан на языке C++ с использованием библиотеки Qt и распространяется под лицензиями GPLv2 и GPLv3. Готовые сборки подготовлены для Linux (AppImage, Flatpak, Ubuntu PPA, Snap), Windows и macOS.
Основные возможности:
 Ключевые изменения в новом выпуске:
| ||
|
Обсуждение (141 +28) |
Тип: Программы |
| ||
| · | 22.10 | Опубликован сетевой стек F-Stack 2.0, работающий в пользовательском пространстве (62 +14) |
|
Состоялся релиз проекта F-Stack 2.0, развивающего редакцию сетевого стека FreeBSD, адаптированную для обособленной работы в пользовательском пространстве в форме библиотеки. Проект создан крупнейшей в Китае телекоммуникационной компанией Tencent и используется в её продуктах и сервисах. Код написан на языке Си и распространяется под лицензией BSD. Поддерживается работа в Linux и FreeBSD. Проектом также поддерживаются переведённые на использование F-Stack редакции Nginx 1.28 и СУБД Redis 6.2.6, демонстрирующие производительность выше обычных сборок, работающих поверх системного сетевого стека.
F-Stack позволяет задействовать в приложениях собственный локальный сетевой стек, не зависящий от сетевого стека операционной системы, функционирующий в пользовательском пространстве и напрямую работающий с сетевым оборудованием. F-Stack позиционируется как решение, позволяющее повысить производительность обработчиков сетевых запросов в условиях, когда штатный TCP/IP стек ядра Linux становится узким местом и ограничивает масштабирование. Теоретически F-Stack позволяет достигнуть потолка сетевой производительности, возможного для используемой сетевой карты, и в некоторых ситуациях даёт возможность в разы увеличить число обрабатываемых мелких сетевых запросов. Повышение производительности достигается за счёт исключения таких операций, как копирования сетевых пакетов, планирование потоков, обработка прерываний и обращение к системным вызовам. Для взаимодействия с сетевой картой, минуя интерфейсы ядра операционной системы, применяется фреймворк DPDK (Data Plane Development Kit), развивающий набор библиотек для низкоуровневой работы с сетевыми адаптерами. DPDK даёт возможность снизить накладные расходы и уложиться в минимальное число циклов CPU при приёме или отправке сетевых пакетов. Функциональность стека TCP/IP соответствует сетевому стеку FreeBSD 15 и выделена из данной операционной системы в независимую библиотеку. Для разработки приложений можно использовать стандартный API POSIX (socket, epoll, kqueue) или собственный программный интерфейс на основе микропотоков, упрощающий создание сетевых приложений и позволяющий обойтись без сложной логики асинхронной обработки запросов. Возможно использование с немодифицированными приложениями с загрузкой через LD_PRELOAD. Наиболее заметные изменения в новом выпуске:
| ||
|
Обсуждение (62 +14) |
Тип: Программы |
| ||
| · | 22.10 | В PyPI-пакет и Docker-образ с LiteLLM подставлено вредоносное ПО (30 +13) |
|
Зафиксирована публикация в репозитории PyPI вредоносного выпуска библиотеки LiteLLM, насчитывающей 23 млн загрузок в неделю, а также подстановка вредоносного кода в официальный Docker-образ проекта. Это не первый подобный инцидент с LiteLLM - в марте этого года атакующие уже публиковали вредоносные выпуски после перехвата учётных данных сопровождающего. На этот раз атакующие разместили версию LiteLLM 1.107.0, в которую был встроен вредоносный код для организации удалённого выполнения команд, а также поиска и отправки учётных данных, ключей и токенов доступа.
Вредоносный код был подставлен на этапе сборочного процесса без компрометации git-репозитория. После установки вредоносный код активируется до импорта LiteLLM через установку файлов cook.pth, cook.py и sitecustomize.py в директорию с библиотеками Python. Данные файлы запускаются при каждом выполнении Python в системе без необходимости совершения пользователем каких-либо действий. Вначале Python запускает файл cook.pth, в котором имеется только одна строка "import cook" для импорта скрипта cook.py, собирающего учётные данные. Далее импортируется скрипт sitecustomize.py, применяемый для фоновой загрузки внешнего кода (параметры загрузки определяются по ссылке "raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt"). Вредоносный код в обоих скриптах сжат через zlib и закодирован методом Base64. Индикатором компрометации может служить появление в системе файлов "/tmp/.pc_once_*" и "/tmp/remote_code_loader.lock". После активации файл cook.py выполняет сканирование параметров подключения к облачным сервисам, репозиториям и системам непрерывной интеграции (AWS, Azure, Google Cloud, Kubernetes, Docker, GitHub CLI, Vault, Terraform, Packer), учётных записей разработчиков, параметров подключения к Git, настроек npm и PyPI, файлов с переменными окружения, закрытых ключей для SSH, PGP и TLS, настроек AI-инструментов, браузерных БД c Cookie, хранимыми данными и историей, информации о процессах и переменных окружения. Обнаруженные данные шифруются с использованием алгоритмов AES-256-CBC + RSA-4096 и отправляются в форме проверочного запроса на сайт litellm.dev, созданный злоумышленниками.
| ||
|
Обсуждение (30 +13) |
Тип: Проблемы безопасности |
| ||
| · | 22.10 | Проблемные корневые сертификаты eMudhra были сгенерированы в HSM и прошли независимый аудит (157 +37) |
|
Компания eMudhra опубликовала заявление, связанное с инцидентом, в результате которого у восьми корневых сертификатов удостоверяющего центра оказались легко подбираемые закрытые ключи, имеющие всего 1 байт энтропии вместо 48. eMudhra утверждает, что сертификаты были сгенерированы в апреле 2025 года на публичной церемонии с использованием аппаратных модулей HSM (Hardware Security Module), имеющих сертификат соответствия требованиям FIPS 140-2 Level 3.
В процессе генерации ключей произошёл сбой, из-за которого на этапе упаковки/распаковки в HSM (wrap/unwrap, шифрование и расшифровка ключом-обёрткой) в дополнение к основному набору криптостойких ключей был создан второй набор слабых ключей с обнулёнными старшими байтами, который и был задействован в сертификатах. Сбой не был распознан, так как закрытые ключи создаются и хранятся только в HSM и не попадают в открытом виде за его пределы. Причина произошедшего сбоя пока не ясна и компания проводит связанное с этим расследование. Утверждается, что проблемные корневые сертификаты, созданные с использованием слабых ключей, прошли независимый аудит и два года оставались в списке доверенных во всех хранилищах корневых сертификатов. Дополнение: Компания eMudhra объявила о прекращении деятельности удостоверяющего центра и сосредоточении бизнеса на разработке корпоративных решений и сервисах, связанных с обеспечением безопасности. Отмечается, что связанная с TLS-сертификатами деятельность приносила около 1% от общей выручки компании.
| ||
|
Обсуждение (157 +37) |
Тип: Проблемы безопасности |
| ||
| · | 22.10 | Нарушения эмбарго и затягивание разработки патчей в ходе устранения уязвимостей в PHP (134 +38) |
|
Разработчики PHP опубликовали отчёт о проблемах, возникших в процессе устранения исправленных вчера критических уязвимостей в PHP. Информация об уязвимости, возникающей при исчерпании доступной памяти, была получена в ходе внешнего аудита ещё в 2024 году, но была воспринята лишь как теоретическая возможность совершения атаки. Исправление затянулось из-за проблем с достижением консенсуса среди разработчиков PHP о способе устранения уязвимости. Рассматривалось несколько конкурирующих предложений о решении проблемы, каждое из которых имело свои минусы. Приходилось выбирать между нарушением обратной совместимости, появлением новых векторов для атак, вызывающих отказ в обслуживании, и необходимостью внесения изменений во множество сторонних дополнений.
Несколько месяцев назад компании Calif и Wiz независимо друг от друга при помощи AI-моделей GPT‑5.6 и Gemini 4 Argon выявили рабочие методы эксплуатации проблемы и 11 и 24 августа 2026 года сообщили об этом разработчикам PHP. После этого разработке исправлений был назначен наивысший приоритет и начато реформирование процесса принятия решений для более оперативного реагирования в вопросах, связанных со сложными компромиссами (подобные решения теперь могут приниматься большинством голосов без строгого достижения консенсуса). Изначально, скоординированная с дистрибутивами дата публикации исправления была назначена на 22 октября, но затем была перенесена на 21 октября после утечки 20 октября в социальные сети сведений о CVE-идентификаторах и некорректных данных о времени публикации предстоящих корректирующих выпусков. Вскоре после анонса предстоящих исправлений в компания Calif, выявившая одну из уязвимостей, по ошибке опубликовала видеоролик с демонстрацией работы эксплоита, в котором были заметны некоторые детали, позволяющие сузить область поиска и воссоздания информации о проблеме. Ролик был быстро удалён, что лишь подстегнуло у исследователей желание докопаться до сути уязвимости и форсировало работу над альтернативными прототипами эксплоитов. Помимо этого, за шесть часов до намеченной публикации исправлений компания Chainguard нарушила эмбарго и опубликовала сборки своего дистрибутива, содержащие исправленную версию PHP. Подобное нарушение дало возможность злоумышленникам изучить исправление до официального релиза, а также перечеркнуло всю работу по скоординированному раскрытию информации и одновременной публикации исправлений в разных дистрибутивах. Дополнение: Спустя 16 часов после раскрытия деталей об уязвимостях универсального рабочего эксплоита ещё не появилось и массовых атак пока не наблюдается, что объясняется сложностью эксплуатации уязвимости из-за необходимости определения раскладки структур в памяти процесса, которая специфична в каждой сборке. Опубликованные рабочие прототипы эксплоитов завязаны на отдельные конфигурации и проведение атаки в лабораторных условиях. Также появилось много фиктивных эксплоитов, являющихся галлюцинациями AI, лишь создающих видимость атаки, завязанных на ошибки в конфигурации или работающих только при наличии других критических уязвимостей.
| ||
|
Обсуждение (134 +38) |
Тип: К сведению |
| ||
| · | 21.10 | Выпуск пользовательского окружения Dux Shell 2.0 (82 +2) |
|
Опубликован релиз пользовательского окружения Dux Shell 2.0, поддерживающего работу поверх композитных серверов niri, Hyprland, Sway, MangoWC, labwc, Scroll, Aqueous и Miracle WM. Это первый выпуск после переименования проекта DankMaterialShell (DMS) в Dux Shell. Новое имя проще, созвучно с пингвином Tux и не включает в часть названия чужого бренда. Dux Shell развивает набор сочетающихся между собой компонентов для формирования рабочего стола, таких как панель задач, переключатель виртуальных рабочих столов, интерфейс навигации по установленным приложениям и конфигуратор. Оформление соответствует концепции Material Design 3.
Dux Shell поддерживает динамические темы оформления, автоматически применяемые к GTK, Qt и системным приложениям. Цветовые схемы для тем формируются с учётом цвета выбранных обоев рабочего стола. Имеется возможность включения ночного режима работы, а также переключения между светлой и тёмной темами оформления. Функциональность может расширяться через плагины. Код фонового процесса для интеграции с системой, инструментария и инсталлятора написаны на языке Go и распространяются под лиценизей MIT. Компоненты интерфейса, панели, виджеты и графические приложения подготовлены на языке QML с применением фреймворка Quickshell, написанного на C++ с использованием Qt. В состав входят:
 Среди изменений в новом выпуске:
| ||
|
Обсуждение (82 +2) |
Тип: Программы |
| ||
| · | 21.10 | Раскрыты детали критических уязвимостей в PHP и опубликованы корректирующие обновления (115 +29) ↻ |
Опубликованы корректирующие выпуски PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а также патчи для уже не поддерживаемых веток PHP 7.4, PHP 8.0 и PHP 8.1 (уязвимые версии с 5.4 по 7.3 остаются без патчей), в которых исправлены две критические уязвимости:
Заявлено, что полное блокирование уязвимостей возможно только через установку обновления. Следующие меры позволяют снизить вероятность успешного проведения атак, но не делают систему полностью безопасной:
Статус устранения уязвимостей в дистрибутивах можно оценить на данных страницах: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch, Fedora, FreeBSD. Дополнение 1: Уязвимости выявлены при помощи AI-моделей GPT‑5.6 и Gemini 4 Argon. Компания OpenAI опубликовала утилиту php2shell-checker для проверки подверженности уязвимостям сайтов и локальных исполняемых файлов, но эта утилита лишь проверяет номер версии PHP, возвращаемый HTTP-сервером или командой "php -v", без детального анализа. Дополнение 2: Автор прототипа эксплоита, использующего уязвимость, вызванную двойным освобождением памяти (double-free), сообщил, что проблема остаётся не исправлена в выпуске PHP 8.5.12 и эксплоит продолжает работать. Ранее представители PHP заявляли, что эта уязвимость не связана с готовящимися исправлениями и не является реальной проблемой. Автор же эксплоита утверждает, что это совсем иная уязвимость. Дополнение 3: Спустя 16 часов после раскрытия деталей об уязвимостях универсального рабочего эксплоита ещё не появилось и массовых атак пока не наблюдается, что объясняется сложностью эксплуатации уязвимости из-за необходимости определения раскладки структур в памяти процесса, которая специфична в каждой сборке. Опубликованные рабочие прототипы эксплоитов завязаны на отдельные конфигурации и проведение атаки в лабораторных условиях. Также появилось много фиктивных эксплоитов, являющихся галлюцинациями AI, лишь создающих видимость атаки, завязанных на ошибки в конфигурации или работающих только при наличии других критических уязвимостей. Дополнение 4: Подготовлен неофициальный порт пакетов с ветками PHP 5.3 и 5.4 для пользователей Red Hat Enterprise Linux 6 и 7, которые также можно использовать в соответствующих ветках CentOS, Oracle Linux и Scientific Linux. Доступны как spec-файлы для сборки с патчами, так и готовые бинарные пакеты. Дополнение 5: Для уязвимостей PHP2Shell анонсирован первый эксплоит, обходящий рандомизацию адресов (ASLR).
| ||
|
Обсуждение (115 +29) ↻ |
Тип: Проблемы безопасности |
Интересно
| ||
| · | 21.10 | Выпуск среды рабочего стола COSMIC 1.11.0 (39 +11) |
|
Компания System76, разрабатывающая Linux-дистрибутив Pop!_OS, опубликовала выпуск среды рабочего стола COSMIC 1.10.0. Пакеты с COSMIC 1.11.0 доступны в дистрибутиве Pop!_OS 24.04 и в ближайшее время ожидаются в Fedora, NixOS, Arch Linux, openSUSE, aerynOS, Redox и CachyOS. Код написан на языке Rust и распространяется под лицензиями GPLv3 (приложения) и MPL-2.0 (библиотеки).
COSMIC развивается как универсальный проект, не привязанный к конкретному дистрибутиву и соответствующий спецификациям Freedesktop. Для построения интерфейса в COSMIC задействована библиотека Iced, которая использует безопасные типы, модульную архитектуру и модель реактивного программирования, а также предлагает архитектуру, привычную для разработчиков, знакомых с языком декларативного построения интерфейсов Elm. Предоставляется несколько движков отрисовки, поддерживающих Vulkan, Metal, DX12, OpenGL 2.1+ и OpenGL ES 2.0+. Разработчикам предлагается готовый набор виджетов, возможность создавать асинхронные обработчики и использовать адаптивную компоновку элементов интерфейса в зависимости от размера окна и экрана. Помимо использования языка Rust из особенностей COSMIC выделяются режимы гибридной мозаичной компоновки окон и стекового закрепления окон (группировка окон по аналогии со вкладками в браузере), которые могут включаться в привязке к виртуальным рабочим столам. Проектом также разрабатывается композитный сервер cosmic-comp на базе Wayland. Среди изменений:
| ||
|
Обсуждение (39 +11) |
Тип: Программы |
| ||
| · | 21.10 | Проект LiberNT развивает форк ReactOS, нацеленный на совместимость с Windows 11 (158 +6) |
|
В рамках проекта LiberNT создан форк операционной системы ReactOS, нацеленный на достижение совместимости с приложениями и драйверами для Windows 11 24H2, стилизацию внешнего вида под современные Windows и поддержку 64-разрядных аппаратных платформ, включая системы на базе архитектур ARM64, PowerPC и RISC-V 64. Отличительной особенностью форка также является активное использование AI-инструментов при разработке. Собственные наработки LiberNT распространяются под лицензией GPLv3, но код заимствованный из ReactOS продолжает поставляться под лицензией GPLv2+. Основные загрузочные сборки сформированы для систем x86_64 и ARM64, дополнительно публикуются экспериментальные сборки для PowerPC и RISC-V 64 (Banana Pi BPI-F3).
Среди достижений проекта:
| ||
|
Обсуждение (158 +6) |
Тип: К сведению |
| ||
| · | 21.10 | Опрос сопровождающих показал, что 25% pull-запросов являются AI-слопом (98 +19) |
|
Организация Linux Foundation подвела итоги опроса 234 сопровождающих и разработчиков открытых проектов, оценивающего влияние AI-инструментов на разработку. 59% опрошенных сопровождающих отметили увеличение числа присылаемых изменений, но около 25% присылаемых pull-запросов признаны низкокачественным AI-слопом. Если рассматривать только крупные проекты, то рост числа изменений отметили 69% опрошенных, а доля AI-слопа среди pull-запросов оценена в 31%.
Среди других тенденций:
| ||
|
Обсуждение (98 +19) |
Тип: Обобщение |
| ||
| · | 21.10 | Уязвимость в PHP, потенциально позволяющая скомпрометировать любой PHP-сайт (153 +21) |
|
Разработчики PHP анонсировали публикацию сегодня в 17:00 (MSK) экстренных корректирующих выпусков (8.5.12, 8.4.27, 8.3.36 и 8.2.35), в которых будут устранены две критические уязвимости. Всем администраторам серверов с PHP рекомендовано незамедлительно установить исправления на своих системах, сразу после их выпуска. Официально детали будут раскрыты только после появления исправлений, но судя по появившейся в открытом доступе информации, речь про уязвимости CVE-2026-109618 и CVE-2026-109619, потенциально позволяющие удалённо выполнить свой код на любом web-сервере, выполняющем PHP-скрипты в конфигурации по умолчанию. Проблемы проявляются во всех версиях, начиная с PHP 5.4.
В сети уже появились прототипы эксплоитов (1, 2) для проверки подверженности систем уязвимости. В примечании к эксплоиту утверждается, что уязвимости вызваны обращением к уже освобождённой памяти в обработчике отслеживания прогресса загрузки файлов на сервер (session.upload_progress). Наличия на сайте функциональности для загрузки файлов для совершения атаки не требуется, достаточно автоматического срабатывания в PHP-интерпретаторе обработчика контента "multipart/form-data". Для успешной эксплуатации требуется определение раскладки структур в памяти процесса, которая специфична в каждой сборке (проблема решается перебором в эксплоите смещений, заранее вычисленных для пакетов из разных дистрибутивов). В качестве обходного пути защиты встречаются рекомендации выставить в php.ini параметр "session.upload_progress.enabled = off" (или "php_admin_flag[session.upload_progress.enabled] = off" в PHP-FPM), но представитель проекта PHP, а также автор первого прототипа эксплоита утверждают, что для блокирования обеих уязвимостей этого недостаточно. В примечании ко второму прототипу эксплоита упоминается, что помимо вышеупомянутой настройки в php.ini для предотвращения атаки без применения патча требуется полная блокировка запросов с типом контента "multipart/form-data", которая приведёт к невозможности загрузки файлов через web-формы. В Apache httpd для блокировки multipart-запросов можно использовать следующее правило в mod_rewrite:
RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F,L]
Для блокировки в nginx:
if ($http_content_type ~* "multipart") {
return 403;
}
Для блокировки в Caddy: @multipart header_regexp Content-Type (?i)multipart respond @multipart 403 Дополнение: Опубликованы корректирующие выпуски PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а также подробности об исправленных критических уязвимостях. Разбор уязвимостей и официально рекомендованных обходных методов защиты опубликован в отдельной новости.
| ||
|
Обсуждение (153 +21) |
Тип: Проблемы безопасности |
| ||
| · | 20.10 | Ошибка при генерации ключей удостоверяющего центра eMudhra позволяла получить TLS-сертификаты для любых сайтов (125 +23) |
|
Компания Mozilla предупредила о компрометации закрытых ключей, связанных с восемью промежуточными (вторичными) корневыми сертификатами удостоверяющего центра eMudhra. Скомпрометированные ключи позволяли для любого сайта выпустить поддельные TLS-сертификаты, воспринимаемые как заслуживающие доверия во всех браузерах, и использовать их для перехвата или модификации транзитного трафика.
Закрытые ключи были воссозданы исследователями из имеющихся в публичном доступе данных, что стало возможным из-за ошибки в процессе генерации ключей на базе эллиптической кривой P-384. Ошибка привела к тому, что ключи были сгенерированы с использованием при инициализации целых чисел меньше 256 вместо криптографически стойких случайных чисел, т.е. размер закрытого ключа составил 1 байт вместо должных 48 байт. При такой генерации закрытый ключ может быть воссоздан c помощью алгоритма дискретного логарифмирования или простым перебором с генерацией первых 256 возможных ключей. Так как значения закрытых ключей теперь известны (4, 56, 66, 115, 155, 156, 230 и 237), всем пользователям рекомендуется срочно обновить браузеры и пакеты с корневыми сертификатами. В качестве доказательства утечки закрытых ключей сообщивший об инциденте исследователь опубликовал сообщение, подписанное закрытыми ключами от каждого из восьми скомпрометированных сертификатов eMudhra. Проверить свой браузер на предмет обновления информации об отозванных сертификатах можно на сайте, посвящённом инциденту. Экстренно сформированы корректирующие выпуски Firefox 158.0.1, 115.43.1 и 153.5.1, а также библиотеки NSS 3.131.1, в которых обновлено хранилище корневых сертификатов и заблокированы проблемные сертификаты. В Chrome и продуктах Google скомпрометированные сертификаты заблокированы 17 октября, в Apple - 19 октября, а в Microsoft - 20 октября. Блокировка также выполнена через централизованные списки отозванных сертификатов OneCRL, CRLite и CRLSets. Пакеты с обновлёнными корневыми сертификатами выпущены для Ubuntu (ca-certificates 20260816ubuntu0.2*.04.1), Debian (ca-certificates 20250419+deb13u1), Arch Linux (ca-certificates-mozilla 3.131.1-1), Gentoo (ca-certificates 20260816.3.125), curl, Homebrew, Go (1.27.3, 1.26.10), Python, RustTLS, Electron, Elixir, Node.js и FreeBSD. Необновлёнными остаются списки корневых сертификатов в Bun и Composer. До обновления пакета ca-certificates для ручного удаления проблемных корневых сертификатов в Debian и Ubuntu можно использовать команду:
sed -i \
-e 's|^mozilla/emSign_ECC_Root_CA_-_G3.crt|!&|' \
-e 's|^mozilla/Comodo_AAA_Services_root.crt|!&|' \
/etc/ca-certificates.conf && update-ca-certificates
В Fedora, RHEL, CentOS Stream, Rocky Linux, AlmaLinux и Amazon Linux 2023:
d=/etc/pki/ca-trust/source/blocklist; [ -d $d ] || d=/etc/pki/ca-trust/source/blacklist
trust extract --overwrite --format=pem-bundle \
--filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' \
$d/Comodo_AAA_Services_root.pem &&
trust extract --overwrite --format=pem-bundle \
--filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \
$d/emSign_ECC_Root_CA_-_G3.pem &&
update-ca-trust
В openSUSE и SLES:
d=/etc/pki/trust/blocklist; [ -d $d ] || d=/etc/pki/trust/blacklist
trust extract --format=pem-bundle \
--filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' \
$d/Comodo_AAA_Services_root.pem &&
trust extract --format=pem-bundle \
--filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \
$d/emSign_ECC_Root_CA_-_G3.pem &&
update-ca-certificates
В NixOS:
security.pki.caCertificateBlacklist = [
"Comodo AAA Services root"
"emSign ECC Root CA - G3"
];
В NetBSD: certctl untrust /usr/share/certs/mozilla/all/emSign_ECC_Root_CA_-_G3.pem && certctl untrust /usr/share/certs/mozilla/all/Comodo_AAA_Services_root.pem Дополнение: Компания eMudhra опубликовала связанное с инцидентом заявление, в котором говорится, что проблемные корневые сертификаты eMudhra были сгенерированы в сертифицированном HSM и прошли независимый аудит.
| ||
|
Обсуждение (125 +23) |
Тип: Проблемы безопасности |
Интересно
| ||
| Следующая страница (раньше) >> | ||
