Если вы когда-нибудь отправляли отчет о безопасности в PHP, а затем каждое утро в течение трех недель обновляли страницу бюллетеней, привет, эта статья для вас, и да, мы ее читаем. PHP обеспечивает работу значительной части веб-пространства, поэтому поддержание его безопасности и оперативное реагирование имеют значение далеко за пределами этого проекта, и мы относимся к этому со всей серьезностью. Небольшая группа волонтеров и подрядчиков PHP Foundation делает все возможное, чтобы обеспечивать безопасность ядра PHP в условиях ограниченного времени и доступных ресурсов, и в этой публикации мы расскажем, как именно мы это делаем. Учитывая важность безопасности PHP для многих бизнесов, финансовая поддержка The PHP Foundation позволяет нам помогать компаниям оставаться в безопасности и адекватно реагировать на угрозы. Без этой финансовой поддержки мы все сталкиваемся с возрастающим риском эксплойтов, поэтому мы призываем вас стать нашими партнерами через спонсорство.

Кто находится по ту сторону

Я являюсь частью команды безопасности PHP, которая проводит триаж отчетов, поступающих для php-src. Эта команда состоит из участников сообщества и разработчиков, финансируемых PHP Foundation, и работает автономно, отдельно от фонда. Команда безопасности экосистемы фонда работает бок о бок с нами. Ни один отчет не получает окончательного вердикта, пока кто-то из нас не прочитает его, не попытается воспроизвести проблему и не проверит ее на соответствие нашей политике классификации.

Что мы выпустили с июля

С 1 июля мы опубликовали  15 CVE. Мы также закрыли  106 отчетов после того, как выяснили, что они не представляют собой уязвимости, дублируют уже имеющиеся в очереди или не воспроизводятся. Некоторые из них поступили от чересчур уверенных в себе фаззеров, которые запускали PHP способами, не применяемыми ни в одной продакшен-среде. Каждый из таких отчетов был изучен перед закрытием, поэтому, если ваш был одним из них, кто-то из команды его прочитал. Закрытие отчета не всегда означает полный отказ от проблемы. Те отчеты, которые не являются уязвимостями, но классифицируются как баги или делают PHP надежнее, переходят в разряд работ по харднингу. Недавно к Команде безопасности экосистемы присоединился Дэниел Шерцер (Daniel Scherzer), чтобы заняться этой работой.

Идентификаторы CVE для наших бюллетеней также создаем мы сами. The PHP Group является центром нумерации CVE (CVE Numbering Authority) с областью охвата php-src и присваивает собственные идентификаторы CVE с 2019 года, поэтому  нам не нужно ждать кого-то еще, чтобы получить CVE для уязвимости в PHP. Это важно в текущем году, так как очередь бюллетеней на GitHub выросла настолько, что проверка некоторых отчетов занимает недели, и проекты, зависящие от GitHub в вопросах получения CVE, вынуждены ждать вместе с ним. Мы не зависят от этой очереди, поэтому, когда исправление готово,  бюллетень и связанный с ним CVE публикуются по нашему собственному графику.

У нас все еще есть бэклог отчетов о безопасности, и мы предпочитаем сказать об этом прямо, а не делать вид, что все иначе. Мы продолжаем работать с ним, и  отсутствие новых публикаций в бюллетене не означает, что о проблеме забыли. Если вы ждете ответа, спасибо за терпение, и, пожалуйста, воздержитесь от создания публичных ишью с целью нас подтолкнуть, так как это раскрывает информацию о баге всем до того, как появится исправление. Но если ваш бизнес зависит от безопасности PHP и вы еще не являемся спонсором PHP Foundation, мы настоятельно призываем вас им стать, чтобы помочь нам в этой важной работе.

Инструментарий

За последний год инструменты на базе ИИ значительно удешевили написание отчетов о безопасности, и в php-src их стали присылать гораздо чаще, чем раньше. Успевать обрабатывать их вручную нереально, поэтому мы автоматизируем большую часть работы и тоже используем ИИ на нашей стороне.

Мы воспроизводим проблемы на Linux, macOS, Windows и любых других платформах, требуемых для отчета. Наши сборки используют AddressSanitizer и UndefinedBehaviorSanitizer и настроены аналогично нашей CI. Крэш, который проявляется только на одной кастомной сборке, мало что говорит нам о том PHP, который развертываете вы.

Мы также добавили в наш инструментарий  Daybreak Red. Это высший уровень программы Daybreak от OpenAI, доступный только проверенным защитникам и созданный для исследования уязвимостей и проверки эксплойтов, так что  мы полностью укомплектованы для такого рода работы. OpenAI предоставила проекту доступ к нему в рамках поддержки мейнтейнеров открытого ПО. Мы используем его двумя способами: он помогает нам проверять отчеты, прослеживая proof of concept через движок, и проверяет, подтверждается ли заявленное влияние. Он также помогает нам сортировать очередь, выявляя отчеты, которые бьют в одну и ту же корневую причину с разных сторон, и указывая, какие из них стоит прочитать в первую очередь.

Ранее в этом году у нас также был доступ к  Claude Mythos — модели от Anthropic, которая на тот момент лидировала в сфере безопасности, и мы задействовали ее для защиты PHP. Этот доступ в основном был получен благодаря связям, установленным через Alpha-Omega, и мы очень им за это благодарны. Наличие за нашей спиной такой организации, как PHP Foundation, дает нам структурированный доступ к подобным ресурсам.

 Однако окончательные решения принимают не модели. Каждый вердикт выносится человеком, который устанавливает уровень критичности и пишет или проверяет каждый патч, и ни один автор отчета не получает ответ по анализу, который человек предварительно не попытался воспроизвести.

Как сообщать о проблемах, чтобы мы могли действовать быстро

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

Быстрее всего через нашу очередь проходят отчеты, содержащие минимальный PHP-скрипт, вызывающий проблему, версию PHP или коммит, ОС и флаги конфигурации, а также полный вывод санитайзера, если он доступен. Прежде всего, лучшие отчеты указывают нам  влияние: какой ввод контролирует злоумышленник, в каком типе приложения и что именно он в результате получает. Влиянию чаще всего уделяют мало внимания, а ведь именно оно определяет степень критичности. Тем не менее, пожалуйста, избегайте излишне длинных и драматичных отчетов, которые заставляют нас тратить много времени на чтение ради того, что могло бы оказаться простым исследованием.

В нашей политике классификации безопасности перечислено то, что мы не считаем уязвимостью, и с ней стоит ознакомиться перед отправкой формы. Вредоносный код, являющийся валидным PHP, нефильтрованный ввод, передаваемый в такие функции, как  mysqli_query() , обходы FFI, обходы  open_basedir , нестандартные сборки и встроенный веб-сервер — все это находится за рамками политики. Многие из этих случаев по-прежнему остаются багами, и трекер публичных ишью с радостью их примет.

Об отчетах, написанных с помощью ИИ

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

На этом пока все

Пожалуйста, поддержите нашу работу по безопасности через спонсорство PHP Foundation. Мы продолжим выпускать исправления и бюллетени, а волонтеры и финансируемые фондом разработчики будут работать рука об руку. Если вы что-то нашли, отправьте это нам, и кто-нибудь из нас обязательно это прочитает. А если вы уже сделали это, пожалуйста, наберитесь терпения. Мы скоро вернемся с ответом!