#itsec
Uncovering GStreamer secrets
TL;DR: чел написал кастомный генератор начальных данных для фаззера и нашёл 29 новых потенциальных уязвимостей в GStreamer.
Фаззинг программ, разбирающих медиа-форматы, затруднителен тем, что готовые медиа-файлы слишком большие, чтобы эффективно использовать фаззинг, поскольку фаззеры обычно применяют побайтовые мутации к входным данным. Конкретно в случае с MP4 проблема усугубляется строением формата. Именно, файл MP4 состоит из нескольких box-ов, которые могут быть вложенными, и каждый из них начинается с заголовка, который включает в себя размер всего box-а. Если фаззер применяет мутацию, которая вставляет новые данные, он не в состоянии одновременно также и скорректировать размеры в нужных местах.
В статье описан алгоритм для генерирования случайных MP4-файлов. Коротко:
* создаётся случайное дерево, описывающее вложенные box-ы
* по узлам раскидываются теги
* листья дерева получают случайные размеры, размер остальных подсчитывается из суммы вложенных
* для каждого узла генерируются случайные данные в рамках выбранных размеров
* итоговое дерево сериализуется
К сожалению, из статьи непонятно, написал ли автор только генератор тестовых данных или ещё и мутатор.
Сами найденные ошибки, кстати, все типичные сишные: OOB-чтение/запись, разыменовывания NULL-указателей и даже одно use after free.
Uncovering GStreamer secrets
TL;DR: чел написал кастомный генератор начальных данных для фаззера и нашёл 29 новых потенциальных уязвимостей в GStreamer.
Фаззинг программ, разбирающих медиа-форматы, затруднителен тем, что готовые медиа-файлы слишком большие, чтобы эффективно использовать фаззинг, поскольку фаззеры обычно применяют побайтовые мутации к входным данным. Конкретно в случае с MP4 проблема усугубляется строением формата. Именно, файл MP4 состоит из нескольких box-ов, которые могут быть вложенными, и каждый из них начинается с заголовка, который включает в себя размер всего box-а. Если фаззер применяет мутацию, которая вставляет новые данные, он не в состоянии одновременно также и скорректировать размеры в нужных местах.
В статье описан алгоритм для генерирования случайных MP4-файлов. Коротко:
* создаётся случайное дерево, описывающее вложенные box-ы
* по узлам раскидываются теги
* листья дерева получают случайные размеры, размер остальных подсчитывается из суммы вложенных
* для каждого узла генерируются случайные данные в рамках выбранных размеров
* итоговое дерево сериализуется
К сожалению, из статьи непонятно, написал ли автор только генератор тестовых данных или ещё и мутатор.
Сами найденные ошибки, кстати, все типичные сишные: OOB-чтение/запись, разыменовывания NULL-указателей и даже одно use after free.
👍15❤2😐1
#itsec #article
Towards the next generation of XNU memory safety: kalloc_type
Большинство связанных с memory safety уязвимостей основываются на type confusion: одни и те же данные интерпретируются, как значения разных типов, и у злоумышленника обычно есть доступ к одному из этих представлений. Одна из причин, по которой это возможно — use after free, когда новые данные другого типа размещаются по тем же адресам в памяти, что и старые.
Для того, чтобы закрыть этот вектор атаки, можно сделать аллокатор, который никогда не переиспользует одни и те же адреса для значений разных типов. Разработчики Apple, которые работают над ядром iOS, решили именно так и сделать. В полной мере этого достичь не удалось, поскольку полная изоляция адресов по типам вела к слишком большой фрагментации памяти, но итоговое решение значительно затруднило эксплуатацию ошибок, в том числе и за счёт некоторой рандомизации на этапе загрузки.
Текст примечателен ещё и подобным изложением недостатков описанного подхода.
Towards the next generation of XNU memory safety: kalloc_type
Большинство связанных с memory safety уязвимостей основываются на type confusion: одни и те же данные интерпретируются, как значения разных типов, и у злоумышленника обычно есть доступ к одному из этих представлений. Одна из причин, по которой это возможно — use after free, когда новые данные другого типа размещаются по тем же адресам в памяти, что и старые.
Для того, чтобы закрыть этот вектор атаки, можно сделать аллокатор, который никогда не переиспользует одни и те же адреса для значений разных типов. Разработчики Apple, которые работают над ядром iOS, решили именно так и сделать. В полной мере этого достичь не удалось, поскольку полная изоляция адресов по типам вела к слишком большой фрагментации памяти, но итоговое решение значительно затруднило эксплуатацию ошибок, в том числе и за счёт некоторой рандомизации на этапе загрузки.
Текст примечателен ещё и подобным изложением недостатков описанного подхода.
Towards the next generation of XNU memory safety: kalloc_type - Apple Security Research
Improving software memory safety is a key security objective for engineering teams across the industry. Here we begin a journey into the XNU kernel at the core of iOS and explore the intricate work our engineering teams have done to harden the memory allocator…
👍8❤1🔥1🥴1
#itsec
Про то, как одной строчкой кода окирпичить iPhone. Уже пофиксили, если что.
t.me/linksfromme/805
Про то, как одной строчкой кода окирпичить iPhone. Уже пофиксили, если что.
t.me/linksfromme/805
Telegram
Too Long, Did Read
Как закирпичить iPhone одной строчкой кода
https://rambo.codes/posts/2025-04-24-how-a-single-line-of-code-could-brick-your-iphone
Супер крутая история: разработчик нашел уязвимость в iOS, которая позволяет "закирпичить" айфон буквально одной строчкой кода.…
https://rambo.codes/posts/2025-04-24-how-a-single-line-of-code-could-brick-your-iphone
Супер крутая история: разработчик нашел уязвимость в iOS, которая позволяет "закирпичить" айфон буквально одной строчкой кода.…
🤯7❤3
#itsec #article
XORry Not Sorry: The Most Amusing Security Flaws I've Discovered
Или немного о том, насколько плохо может быть реализована безопасность на примере реальных (со слов автора) приложений.
XORry Not Sorry: The Most Amusing Security Flaws I've Discovered
Или немного о том, насколько плохо может быть реализована безопасность на примере реальных (со слов автора) приложений.
predr.ag
XORry Not Sorry: The Most Amusing Security Flaws I've Discovered
Building your own cryptographic protocols, and why you probably shouldn't.
🤣3😁1🤔1
Технологический Болт Генона
Достижение выполнения кода при контроле над текстом комментария в Python-скрипте https://www.opennet.ru/opennews/art.shtml?num=63669 Участники могли отправить сетевой запрос к Python-скрипту, который создавал новый Python-скрипт cо случайными именем, добавлял…
#prog #itsec #python
В конце мне не нравится, что автор поёт дифирамбы ИИ. Ну и ещё у него есть функция
Это явно можно написать одновременно эффективнее и проще для восприятия:
В конце мне не нравится, что автор поёт дифирамбы ИИ. Ну и ещё у него есть функция
ascii_safe, которая написана просто ужасно:def ascii_safe(x: int) -> bool:
"""True if all four bytes have high bit clear."""
return all(((x >> (8 * i)) & 0x80) == 0 for i in range(4))
Это явно можно написать одновременно эффективнее и проще для восприятия:
def ascii_safe(x: int) -> bool
return x & 0x80808080 == 0
💯13🤡5
Технологический Болт Генона
Уязвимости в tar-fs и 7-Zip, позволяющие записать файлы за пределы базового каталога https://www.opennet.ru/opennews/art.shtml?num=63740 В NPM-пакете tar-fs выявлена уязвимость (CVE-2025-48387), позволяющая при распаковке специально оформленного tar-архива…
Telegram
Блог*
#prog
Dot Dot Considered Harmful, или почему в Fuchsia нет .. в составе путей.
TL;DR: проще контролировать доступ к файловой системе.
(thanks @alurm)
Dot Dot Considered Harmful, или почему в Fuchsia нет .. в составе путей.
TL;DR: проще контролировать доступ к файловой системе.
(thanks @alurm)
👍7🤡2
#prog #rust #itsec #article
hyper HTTP/2 (Didn't) MadeYouReset
Протокол HTTP/2 позволяет открыть несколько стримов поверх одного соединения, каждый из которых может быть отменён (reset) любой стороной в любой момент. В некоторых случаях это нужно сделать обязательно — например, когда одна из сторон присылает невалидные сообщения. Это сделало возможным уязвимость, названную MadeYouReset. Суть её в том, что злоумышленник инициирует соединение с максимально возможным числом стримов, а затем постоянно их сбрасывает путём отправки невалидных фреймов. Обработка всех этих запросов и следование протоколу отнимает ресурсы сервера, что делает возможным Denial of service.
Эта уязвимость очень схожа с уязвимостью Rapid Reset, но, как описано в статье от Cloudflare, она несколько более хитрая. Rapid Reset полагается на явную отмену стримов клиентом через посылку фрейма RST_STREAM. MadeYouReset же работает через посылку невалидных фреймов, заставляя сервер парсить запросы и отменять стримы уже с его стороны.
Многие реализации HTTP/2 на практике делали работу по обработке запроса даже после закрытия стрима. Простые меры предосторожности против Rapid Reset, отслеживающие только фреймы RST_STREAM от клиента, бесполезны против MadeYouReset.
h2 (Rust-библиотека для работы с протоколом HTTP/2) оказалась не подвержена этой уязвимости. Почему? На это есть несколько причин.
Во-первых, в h2 несколько лет назад добавили меру предосторожности против абьюза клиентами отмен стримов. Именно, h2 отслеживает, сколько раз фрейм от клиента привёл к отмене стрима со стороны клиента, и когда это число достигает настраиваемого порога, закрывает соединение целиком. Это уже хорошая защита, которая на практике успешно защищала от Rapid Reset, но она была не безупречна — для одного типа фреймов (WINDOW_UPDATE) на одном из путей исполнения это число не обновлялось (разумеется, это поправили).
Во-вторых, h2 — библиотека, а не фреймворк, и всегда передаёт вызывающему коду информацию об отмене стрима. Разумеется, от этого мало толку, если вызывающий код на это никак не реагирует.
И это подводит нас к третьей причине: контекст использования. На практике h2 использовалась совместно с hyper, Rust-библиотеке для HTTP, абстрагированной от конкретной версии протокола. В коде hyper для стримов ожидается исполнение двух футур: поставляющей новые фреймы из стрима и обрабатывающей запросы из этого стрима. При получении отмены стрима hyper отменяет футуру, обрабатывающую запрос.
Итого: даже без закрытия бага с WINDOW_UPDATE h2 не был подвержен MadeYouReset. Разумеется, это во многом заслуга продуманной архитектуры h2 и hyper. Но также это и заслуга того, как реализована асинхронность в Rust: с ключевым методом Future::poll, позволяющим достаточно просто дожидаться исполнения нескольких футур одновременно, и встроенная поддержка отмены футур просто через вызов drop. Добиться подобной защиты от MadeYouReset в языке с активными тасками и явной в коде отменой (как, например, в C# или в Go с context.Done) значительно сложнее.
hyper HTTP/2 (Didn't) MadeYouReset
Протокол HTTP/2 позволяет открыть несколько стримов поверх одного соединения, каждый из которых может быть отменён (reset) любой стороной в любой момент. В некоторых случаях это нужно сделать обязательно — например, когда одна из сторон присылает невалидные сообщения. Это сделало возможным уязвимость, названную MadeYouReset. Суть её в том, что злоумышленник инициирует соединение с максимально возможным числом стримов, а затем постоянно их сбрасывает путём отправки невалидных фреймов. Обработка всех этих запросов и следование протоколу отнимает ресурсы сервера, что делает возможным Denial of service.
Эта уязвимость очень схожа с уязвимостью Rapid Reset, но, как описано в статье от Cloudflare, она несколько более хитрая. Rapid Reset полагается на явную отмену стримов клиентом через посылку фрейма RST_STREAM. MadeYouReset же работает через посылку невалидных фреймов, заставляя сервер парсить запросы и отменять стримы уже с его стороны.
Многие реализации HTTP/2 на практике делали работу по обработке запроса даже после закрытия стрима. Простые меры предосторожности против Rapid Reset, отслеживающие только фреймы RST_STREAM от клиента, бесполезны против MadeYouReset.
h2 (Rust-библиотека для работы с протоколом HTTP/2) оказалась не подвержена этой уязвимости. Почему? На это есть несколько причин.
Во-первых, в h2 несколько лет назад добавили меру предосторожности против абьюза клиентами отмен стримов. Именно, h2 отслеживает, сколько раз фрейм от клиента привёл к отмене стрима со стороны клиента, и когда это число достигает настраиваемого порога, закрывает соединение целиком. Это уже хорошая защита, которая на практике успешно защищала от Rapid Reset, но она была не безупречна — для одного типа фреймов (WINDOW_UPDATE) на одном из путей исполнения это число не обновлялось (разумеется, это поправили).
Во-вторых, h2 — библиотека, а не фреймворк, и всегда передаёт вызывающему коду информацию об отмене стрима. Разумеется, от этого мало толку, если вызывающий код на это никак не реагирует.
И это подводит нас к третьей причине: контекст использования. На практике h2 использовалась совместно с hyper, Rust-библиотеке для HTTP, абстрагированной от конкретной версии протокола. В коде hyper для стримов ожидается исполнение двух футур: поставляющей новые фреймы из стрима и обрабатывающей запросы из этого стрима. При получении отмены стрима hyper отменяет футуру, обрабатывающую запрос.
Итого: даже без закрытия бага с WINDOW_UPDATE h2 не был подвержен MadeYouReset. Разумеется, это во многом заслуга продуманной архитектуры h2 и hyper. Но также это и заслуга того, как реализована асинхронность в Rust: с ключевым методом Future::poll, позволяющим достаточно просто дожидаться исполнения нескольких футур одновременно, и встроенная поддержка отмены футур просто через вызов drop. Добиться подобной защиты от MadeYouReset в языке с активными тасками и явной в коде отменой (как, например, в C# или в Go с context.Done) значительно сложнее.
seanmonstar
hyper HTTP/2 (Didn't) MadeYouReset
A new HTTP/2 attack vector was disclosed today called MadeYouReset. hyper’s h2 is negligably affected, weathering the attack well. But, we have provided patc...
❤11👍7🔥5