1.83K subscribers
3.23K photos
127 videos
15 files
3.52K links
Блог со звёздочкой.

Много репостов, немножко программирования.

Небольшое прикольное комьюнити: @decltype_chat_ptr_t
Автор: @insert_reference_here
Download Telegram
😁18😢3❤‍🔥1
😁26💯2🌚1😭1
#itsec

Uncovering GStreamer secrets

TL;DR: чел написал кастомный генератор начальных данных для фаззера и нашёл 29 новых потенциальных уязвимостей в GStreamer.

Фаззинг программ, разбирающих медиа-форматы, затруднителен тем, что готовые медиа-файлы слишком большие, чтобы эффективно использовать фаззинг, поскольку фаззеры обычно применяют побайтовые мутации к входным данным. Конкретно в случае с MP4 проблема усугубляется строением формата. Именно, файл MP4 состоит из нескольких box-ов, которые могут быть вложенными, и каждый из них начинается с заголовка, который включает в себя размер всего box-а. Если фаззер применяет мутацию, которая вставляет новые данные, он не в состоянии одновременно также и скорректировать размеры в нужных местах.

В статье описан алгоритм для генерирования случайных MP4-файлов. Коротко:

* создаётся случайное дерево, описывающее вложенные box-ы
* по узлам раскидываются теги
* листья дерева получают случайные размеры, размер остальных подсчитывается из суммы вложенных
* для каждого узла генерируются случайные данные в рамках выбранных размеров
* итоговое дерево сериализуется

К сожалению, из статьи непонятно, написал ли автор только генератор тестовых данных или ещё и мутатор.

Сами найденные ошибки, кстати, все типичные сишные: OOB-чтение/запись, разыменовывания NULL-указателей и даже одно use after free.
👍152😐1
#itsec #suckassstory

(кажется, первое обычно подразумевает второе)
😁321🌚1
#itsec #article

Towards the next generation of XNU memory safety: kalloc_type

Большинство связанных с memory safety уязвимостей основываются на type confusion: одни и те же данные интерпретируются, как значения разных типов, и у злоумышленника обычно есть доступ к одному из этих представлений. Одна из причин, по которой это возможно — use after free, когда новые данные другого типа размещаются по тем же адресам в памяти, что и старые.

Для того, чтобы закрыть этот вектор атаки, можно сделать аллокатор, который никогда не переиспользует одни и те же адреса для значений разных типов. Разработчики Apple, которые работают над ядром iOS, решили именно так и сделать. В полной мере этого достичь не удалось, поскольку полная изоляция адресов по типам вела к слишком большой фрагментации памяти, но итоговое решение значительно затруднило эксплуатацию ошибок, в том числе и за счёт некоторой рандомизации на этапе загрузки.

Текст примечателен ещё и подобным изложением недостатков описанного подхода.
👍81🔥1🥴1
#itsec

ha-ha, я тут живу работаю
👍21🤯1
#itsec #meme из рабочего чатика
🤯10😁6😢1🙏1
#itsec #article

XORry Not Sorry: The Most Amusing Security Flaws I've Discovered

Или немного о том, насколько плохо может быть реализована безопасность на примере реальных (со слов автора) приложений.
🤣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