Специалист по криптографии и информационной безопасности Паскаль Джунод (Pascal Junod) опубликовал готовый эксплойт для атаки на файловую систему Btrfs.

Btrfs (B-tree FS) — файловая система для Linux, основанная на структурах Б-деревьев. Это довольно производительная и перспективная файловая система, которая лишена многих недостатков, присущих другим файловым системам Linux, в то же время у неё есть некоторые интересные возможности, такие как дефрагментация в рабочем режиме, эффективная упаковка мелких файлов и индексированных каталогов, динамическое выделение инодов (нет ограничения на максимальное количество файлов в файловой системе), журналирование чтений-записей всех данных и метаданных, прозрачная компрессия данных и т.д. Поддержкой Btrfs занимается Крис Мэсон (Chris Mason), один из разработчиков ядра Linux.

Как оказалось, даже в самой лучшей системе можно найти баги. Дело в том, что файловая система Btrfs вычисляет и хранит хэши на каждый файл, используя при этом устаревший алгоритм CRC-32C, для которого легко вычислить коллизии хэшей. То есть имея хэш какого-то файла, вы можете создать другой файл с таким же хэшем, и не один, а десятки разных файлов с одинаковыми хэшами.

Крис Мэсон знает об этой проблеме. В письме Джуноду он сразу написал, что здесь ничего страшного, просто нужно избегать использования общих директорий, где разные пользователи могут создавать файлы — таких директорий как /tmp.

Немного рассерженный подобным ответом, Паскаль Джунод написал эксплойт — скрипт на Питоне, который создаёт около 500 файлов с 55 различными значениями CRC-32C. Как выяснилось, подобная ситуация полностью выводит файловую систему из штатного состояния, так что она просто не справляется с удалением этих файлов. Во время эксперимента Джунод убил процесс через 220 минут, так и не дождавшись удаления файлов.

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

Код скрипта Python для DoS-атаки на Btrfs

Паскаль Джунод рекомендует использовать вместо CRC-32C какой-нибудь лёгкий современный алгоритм, вроде SipHash. Крис Мэсон сказал, что постарается что-нибудь придумать к следующему релизу ядра Linux 3.8, но у него сейчас много работы: приходится обрабатывать большое количество баг-репортов.



Оставить мнение