LINUX.ORG.RU

Уязвимость в Linux-драйвере exFAT, позволяющая поднять привилегии в системе

 , , , ,


2

2

В поставляемом в ядре Linux драйвере для файловой системы exFAT выявлена уязвимость (CVE-2023-4273), позволяющая при монтировании специально оформленного раздела (например, при подключении вредоносного USB Flash) добиться переполнения стека и выполнения своего кода с правами ядра. Проблема устранена в выпусках ядра Linux 6.4.10, 6.1.45, 5.15.25, 5.10.90, 5.4.253, 4.19.291, 4.14.324 и 6.5-rc5. Проследить за исправлением в дистрибутивах можно на следующих страницах: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch.

Отсутствие проверки размера при копировании имени файла в буфер, размещённый в стеке, приводит к переполнению стека ядра в случае задания очень длинного имени файла, превышающего ограничение ФС в 255 символов. Уязвимость присутствует в функции exfat_get_uniname_from_ext_entry, выполняющей реконструкцию длинных имён через цикличное чтение записей с частями имени файла из индекса каталога и слияния полученных частей имени в итоговое длинное имя. Проверка размера в коде exfat_get_uniname_from_ext_entry выполнялась в привязке к каждой записи с частью имени, но не охватывала итоговое имя (например, имя можно разбить на 100 частей и добиться записи в буфер 1500 символов вместо 258).

Выявивший уязвимость исследователь смог подготовить прототип эксплоита, который позволяет повысить свои привилегии в системе. При тестировании в виртуальном машине VirtualBox эксплоит срабатывает в 100% случаев, но при запуске в обычном окружении, работающим поверх оборудования, вероятность срабатывания снижается до примерно 50%. Уязвимость также может быть использована для компрометации ядер, загружаемых в режиме UEFI Secure Boot.

>>> Подробности (opennet.ru)

★★★

Проверено: hobbit ()
Последнее исправление: Dimez (всего исправлений: 2)
Ответ на: комментарий от vbr

Для опытного взломщика чтение дизассемблированного кода вполне комфортный процесс. С, конечно, проще, но не прям намного.

Экие глупости. :) Такие уязвимости фаззером ищут, или смотрят в описание структуры ФС, и думают, как бы её так нарушить, чтобы были шансы, что автор драйвера именно такое нарушение и не учёл. В документации много моментов могут быть неоднозначно расписаны, и часто можно заподозрить, где автор драйвера мог из-за этого косякнуть. И только потом уже, возможно, смотрят дизасм того куска, где вылетает.

Никто и никогда не ищет уязвимости исключительно через аудит асмового кода.

anonmyous ★★
()
Ответ на: комментарий от ya-betmen

Уже есть эксплойт чтобы всякую проприетарь рутовать?

Только в это проприетари скорее всего может не быть extfat в ядре.

hbars ★★★★★
()
Ответ на: комментарий от firkax

Думаю основной сценарий использования другой: даёшь кому-то злонамеренную флешку, он её монтирует чтоб взять с неё какие-то файлы, и получает атаку.

неа, он получает переполнение
на этом все
с некими доп телодвижениями он может получить повышение привилегий
на этом то-же все

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

rukez ★★★★
()
Ответ на: комментарий от hbars

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

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от windows10

В случае ПО с закрытым исходным кодом, уязвимости можно находить только эмпирическим методом, целенаправленно либо же случайно.

Не ври, если кто-то зачем-то полезет в дизассемблированный код, то точно так же всё прекрасно увидит. Ясное дело, не нуб вроде тебя, это да.

firkax ★★★★★
()
Ответ на: комментарий от windows10

В случае ПО с закрытым исходным кодом, уязвимости можно находить только эмпирическим методом, целенаправленно либо же случайно.

Не ври, если кто-то зачем-то полезет в дизассемблированный код, то точно так же всё прекрасно увидит. Ясное дело, не нуб вроде тебя, это да.

firkax ★★★★★
()
Ответ на: комментарий от anonmyous

Не зря fuse пилят. Раст растом, но помойки с драйверами для 100500 различных ФСок для внешних носителей, должны всё же в юзерспейсе быть, имхо.

Fuse надо пилить на rust'e!

vasya_pupkin ★★★★★
()
Ответ на: комментарий от anonmyous

Никто и никогда не ищет уязвимости исключительно через аудит асмового кода.

Может специально и не ищут, но случайно я вполне находил, разглядывая асм код в целях узнать как работает прога. В чём-то даже проще т.к. не надо рыться в куче отдельных исходных файлов и defin-ов.

firkax ★★★★★
()
Ответ на: комментарий от CrX

Что с ЛОРом, почему этого ещё никто не запостил?

И тега нет!

crutch_master ★★★★★
()
Ответ на: комментарий от zx_gamer

Зря. Ради этого куска говна приходится тащить 2 компилятор и все его зависимости (LLVM).

Те лучше использовать решето на сях?

vasya_pupkin ★★★★★
()

Дали им Reiser4. Нет, хочу жрать exFAT.

Camel ★★★★★
()
Ответ на: комментарий от Suigintou

кстати, было дело, я занимался переносом (backport) исправлений по безопасности на старые системы,где почему-либо нельзя было поновее поставить.

mumpster ★★★★★
()

Проблема устранена в выпусках ядра Linux 5.15.25

На kernel.org уже давно 5.15.128. Вы там ничего не путаете?

Gonzo ★★★★★
()
Ответ на: комментарий от anonmyous

Не так уж и много этих ФС. По сути их всего две - FAT32 и exFAT. Все остальное в подавляющем большинстве – редкие фс, которые нигде кроме линукса не работают.

Werenter ★★☆
()
Ответ на: комментарий от firkax

Не ври, если кто-то зачем-то полезет в дизассемблированный код, то точно так же всё прекрасно увидит. Ясное дело, не нуб вроде тебя, это да.

Дедушке расскажешь.

Ты свой собственный код на ассемблере не разберешь через неделю. Именно код, а не ассемблерные вставки.

Чужой код - тем более. Кашу после дизассемблирования - тем более. Учитывая динамически подключающиеся либы, которые сюрпрайз сюрпрайз не дизассемблируются - втройне тем более, лол.

Шо ты там находить мог, теоретик? Иди напиши простую прогу в десять строчек считывания файло в память без предварительной проверки размера, с последующим выводом в std, сконпельни, потом дизассемблируй в x86_64 асм, и пометь мне участок кода, с которого ты сделал вывод что прога может переполнить буфер. Это - простая школьная уязвимость.

Только не шлангуй.

windows10 ★★★★★
()
Ответ на: комментарий от WatchCat

Если б ещё fuse-fs были бы быстрыми и не нагружали так цп.

Тут вы правы конечно. Но всё ж когда речь идёт о сменных носителях, вероятно, производительность не так уж и важна… Я, впрочем, не знаю, почему fuse настолько тормозной, и можно ли это чем-то лечить, или это бай десигн…

anonmyous ★★
()
Ответ на: комментарий от vasya_pupkin

Fuse надо пилить на rust’e!

Да он и так тормозит. Ускорять его надо, а не на расте писать. :)

Вы поймите одно: никто ничего на расте переписывать не будет. Для каких-то новых, мега секьюрных вещей, его будут применять. Но всякие старые помойки переписывать на него не будет решительно ни кто. Это даже не планируется.

anonmyous ★★
()
Ответ на: комментарий от firkax

разглядывая асм код в целях узнать как работает прога.

Вы либо исходник асмовый разглядывали, либо прога была написана на асме, и по тому дизасм от исходника мало чем отличался.

Винда не написана на асме. Надо ли говорить о том, что исходник на асме, и сгенерённый компилятором асм сравнить - это даже не как жопу с пальцем сравнить - тут сходств ещё меньше на несколько порядков. :)

anonmyous ★★
()
Ответ на: комментарий от zx_gamer

Зря. Ради этого куска говна приходится тащить 2 компилятор и все его зависимости (LLVM).

Ну gcc-rs не допилили пока. Сам раст-то тут не виноват.

anonmyous ★★
()
Ответ на: комментарий от Werenter

Не так уж и много этих ФС. По сути их всего две - FAT32 и exFAT. Все остальное в подавляющем большинстве – редкие фс, которые нигде кроме линукса не работают.

Да я б так не сказал. Люди форматят флешки и в нтфс, и в старый добрый фат16. А бывают и iso9660 или udf, если используют всякие дампилки сидиромов на флешу. В этом случае, емнип, ещё и небольшой кусок fat12 в начале идёт, так как он на загрузочных сидиромах может присутствовать.

И все эти легаси ФС - огромная помойка, так как туда наворачивались длинные имена и прочие приблуды такими костылями, что и драйвер всегда становился помоечным.

anonmyous ★★
()
Ответ на: комментарий от windows10

обладая минимальными навыками чтения кода (на уровне джуниора) понаходить такие уязвимости

находить такие уязвимости

обладая минимальными навыками

Ты набрасываешь, или правда веришь в эту чушь?

mord0d ★★★★★
()
Ответ на: комментарий от U53R

Несомненно закрытый код выигрывает по многим позициям.

Хорошо что эта простая истина постепенно стала доходить до людей

До тех пор, пока есть тот, кто может вносить в него изменения.

Изменения вносят те, кто сразу хорошо писать не умеет

BydymTydym
()
Ответ на: комментарий от mumpster

тащемта я имел в виду команду radare а не PDF формат :)

Я тогда вообще не понял о чем ты. Что за radare? Adobe тут при том, что у них регулярно уязвимости вылезали, думаю что имея исходники народ бы вообще всю деятельность, связанную с форматом pdf застопорил.

BydymTydym
()
Ответ на: комментарий от U53R

Не буду :D
Надо на change.org петицию оформить за закрытие исходников ядра, достала уже эта анархия…

BydymTydym
()

При тестировании в виртуальном машине VirtualBox эксплоит срабатывает в 100% случаев, но при запуске в обычном окружении, работающим поверх оборудования, вероятность срабатывания снижается до примерно 50%

как енто

mrjaggers
()
Ответ на: комментарий от mrjaggers

Эта особенность появилась за грант от VMware, только это секрет

BydymTydym
()
Ответ на: комментарий от zx_gamer

Лучше писать нормальный код на С.

Ну ты же сам понимаешь, что это не возможно

vasya_pupkin ★★★★★
()
Ответ на: комментарий от anonmyous

Плохой из тебя телепат, исходник там был на Си (точнее С++ почти без плюсовых фич).

firkax ★★★★★
()
Ответ на: комментарий от BydymTydym

radare2 - свободный кроссплатформенный фреймворк для реверс-инжиниринга, написанный на Си, который включает дизассемблер, шестнадцатеричный редактор, анализатор кода и т. д. Используется при реверсе, отладке вредоносного ПО и прошивок. Википедия

JFYI

mumpster ★★★★★
()
Ответ на: комментарий от mumpster

Прикольно, спасибо. Не то чтобы мне это было сильно надо - я прошивкам реверс не делаю, я предпочитаю прошивки делать, но для общего развития… :D

BydymTydym
()

Больше Си используйте и арифметику с указателями - и не такое будет.

Nxx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.