Buffer overflow + request smuggling = ? Возможно, данная техника прошла мимо вас, но она (как по мне) носит долгоиграющие последствия. Речь пойдет про request smuggling, который обычно упоминается с сочетании с HTTP протоколом. Но не простой смаглинг, а на уровне транспорта и клиентов. Наиболее полго раскрыл тему Paul Gerste на прошлогоднем Defcon. Для работы с внешними сервисами в различных языках программирования есть так называемые "драйвера". Это некоторая реализация общения между вашим кодом и внешней системой, например - СУБД. Канал данных между ними может быть любой. Чаще всего используется UNIX-сокет, в современных микросервисных архитектурах чаще всего TCP, но обдолбанные могут юзать и UDP :) Суть уязвимости Для общения по этим транспортным протоколам нужен общий язык. Как раз драйвер и описывает порядок, как маркируются сообщения, какая длина, тип и т.д. В MySQL под длину отведено 3 байта, затем порядковый номер пакета и сами данные, в PostgreSQL первый байт - это тип сообщения, затем 4 байта длина и сами данные. Вроде бы всё хорошо, только вот что будет, если передать данные большего размера, чем максимальная длина, которую можно уместить в 4 байта? Всё будет по-разному. Во-первых, некоторые системы усекают максимальный размер до определенного числа. Если используется знаковое число - 2147483647 (2^31 - 1), если беззнаковое - 4294967295 (2^32 - 1). В современном мире это не такой уж и большой объем данных. Улавливаете мысль? Драйвер сообщает во внешнюю систему, что длина пакета N, а по факту передает данные большей длины. Это вполне реалистичная ситуация. Предположим, что есть некоторый POST параметр, который пришел от пользователя. Его длина 4294967100, т.е. превышает допустимую вместимость uint32. Получается, что мы можем сконструировать фейковый пакет данных для нужного драйвера, расчитать нужную длину и выполнить произвольное действие на внешней системе, в СУБД, например, выполнить произвольный запрос. Т.е. на выходе получается что-то вроде SQL Injection, основанной на Protocol manipulation + Request smuggling. Несмотря на некоторые ограничения (понятно, что может существовать настройка, которая валидирует длину входящих данных на том же веб сервере, либо валидация входящих символом на алфавит и т.д.) были найдены в дикой природе уязвимые компоненты. Поль раскрыл детали про pgx, pgdriver, pq, pg (драйвера для PostgreSQL для golang), Npgsql - .Net компонент. Потенциально узявимы языки, в которых типы строк (именно тип string чаще всего используется для такого рода хранения) превышают макс. длину uint32, а это Golang, Rust, Python, в других же языках. Есть фишки, которые позволяют обходить это ограничение в других языках, например в JS есть бинарные буфферы, а там своя длина. Т.е. потенциал у баги большой. Думаю, мы еще не раз услышим о подобном способе атаки на систему с помощью данной техники.

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

При работе с микросервисами часто используются роутеры, которые упрощают работу по пробросу трафика в конкретный контейнер. В последнее время всё чаще встречаю в реальном мире Traefik. Это прокси, который стал замещать nginx. Конфигурации путей маршрутизации может задаваться как в отдельном yaml файле, так и через лейблы в Dockerfile. Кроме простой маршрутизации этот прокси предоставляет возможность навешивать кастомные мидлвары на определенные роуты. Обычно это какая-то логика по работе с заголовками HTTP. Выглядит конфиг примерно так:

Переполнение буффера в 2023 году В сети появился PoC для эксплуатации CVE-2023-4911 (Looney Tunables). Уязвимный код находится в динамическом загрузчике glibc, поэтому возможна эксплуатация на большом количестве систем. В основе атаки лежит манипуляция переменной окружения GLIBC_TUNABLES. Детали можно почитать здесь. Повышение привилегий до root было успешно проверено на Fedora {37,38}, Ubuntu {22.04,23.04}, Debian {12,13}. Быстро чекнуть систему на наличие уязвимости можно так:

env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" "Z=`printf '%08192x' 1`" /usr/bin/su --help

Если видно Segmentation fault (core dumped), то ?. Рабочий сплоент https://github.com/leesh3288/CVE-2023-4911