Андрей Коновалов из компании Google обнаружил (https://www.openwall.com/lists/oss-security/2019/08/20/2) 15 уязвимостей в USB-драйверах, предлагаемых в ядре Linux. Это вторая порция проблем, найденных при проведении fuzzing-тестирования - в 2017 году данный исследователь нашёл (https://www.opennet.dev/opennews/art.shtml?num=47523) в USB-стеке ещё 14 уязвимостей. Проблемы потенциально могут быть эксплуатируемы при подключении к компьютеру специально подготовленных USB-устройств. Атака возможна при наличии физического доступа к оборудованию и может привести как минимум к краху ядра, но не исключаются и другие проявления (например, для выявленной в 2016 году похожей уязвимости (https://www.opennet.dev/opennews/art.shtml?num=43920) в USB-драйвере snd-usbmidi удалось подготовить эксплоит (https://github.com/xairy/kernel-exploits/tree/master/CVE-201...) для выполнения кода на уровне ядра).
Из 15 проблем 13 уже устранены в актуальных обновлениях ядра Linux, но две уязвимости (CVE-2019-15290, CVE-2019-15291) остаются неисправленными в последнем выпуске 5.2.9. Неисправленный уязвимости могут привести к разыменованию указателя NULL в драйверах ath6kl и b2c2 при получении некорректных данных от устройства. Из других уязвимостей можно отметить:
- Обращения к уже освобождённым областям памяти (use-after-free) в драйверах v4l2-dev/radio-raremono, dvb-usb, sound/core, cpia2 и p54usb;
- Двойное освобождение памяти (double-free) в драйвере rio500;
- Разыменования указателя NULL в драйверах yurex, zr364xx, siano/smsusb, sisusbvga, line6/pcm, motu_microbookii и line6.URL: https://www.openwall.com/lists/oss-security/2019/08/20/2
Новость: https://www.opennet.dev/opennews/art.shtml?num=51333
никогда такого не было, и вот опять...P.S. Кто на С умел писать - умер, вот и имеем.
> никогда такого не было, и вот опять...Ну, ха-ха. Ну, смешно пошутил. Наверно.
...такое впечатление, что народ уже забыл когда уместно применять эту фразу и лепит ее где ни попадя.
Странно, что родственники или правообладатели не включили доильный аппарат.
>...такое впечатление, что народ уже забыл когда уместно применять эту фразу и лепит ее где ни попадя.никогда такого не было, и вот опять...
> народ уже забыл когда уместно применять эту фразу и лепит ее где ни попадя.Эхх... Вот уже старпёры начинают ныть о том, что в 90-х высказывания Черномырдина были зеленее, и Солнце ярче. Как время летит.
Я очень рекомендую почитать на досуге [1], оно может не совсем в тему, но по-моему должно провоцировать появление некоторых мыслей, которые очень полезны, если загнивающий язык порождает дискомфорт и тревожность.
[1] https://www.theguardian.com/science/2019/aug/15/why-its-time...
Б-г не может умереть.А остальные и не умели.
Бог ушёл туда, куда уходят боги.
А вот если бы было ядро переписали на Rust...
То был-бы Linux, написанный на си, у которого есть драйвера, сообщество и будущее. И был бы Rustomanix, у которого нет всего этого.
кто? сишники никогда на Rust не перейдут (я вам как сишник говорю), как не перешли в своё время на плюсы, а сами растоманы пока ни одного проекта серьёзного не сделали (чтобы только Rust, без unsafe, чтобы сам проект был со значительной кодовой базой и чтобы с тысячами пользователей).
CSS рендер Firefox написан на расте.
кому "CSS рендер Firefox" нужен кроме Firefox? это не проект, а часть проекта Firefox.я специально написал: "только Rust".
Rust в Firefox чуть больше 5%, если кто-то не в курсе
DNS сервер cloudflare написан на rust (который 1.1.1.1 и самый быстрый). Но ретроградам вроде вас ничего не доказать.
И што, таки можно уже поставить себе на файлопомойку ваш этот растовый DNS? Нет? Ну так что вы тогда мне мозг мозолите?
> DNS сервер cloudflare написан на rust (который 1.1.1.1 и самый быстрый). Но
> ретроградам вроде вас ничего не доказать.чтобы доказать нужны доказательства, а не спекуляции!
то, что в проекте 1.1.1.1 используется trustdns либа, это лишь утверждение одного человека, кода никто не видел. а ещё по его утверждению там используются приложения на Go и nginx, так что вообще не рядом.
Самый быстрый 127.0.0.1. Все остальное - жалкое подобие правой руки.
> пока ни одного проекта серьёзного не сделали (чтобы только Rust, без
> unsafe, чтобы сам проект был со значительной кодовой базой и чтобы
> с тысячами пользователей).ripgrep, который is faster than $insert_your_grep_here, уже рекламируется огромной пользовательской базой из каждого утюга. Куча кода в нём и regex crate, unsafe-а мало, да и тот практически весь в C-интерфейсе для тех, кто хочет ржавые регексы использовать в других языках (ну, ок, ещё в месте совокупления rg и pcre для тех, кто без патологического бектрекинга жить не может, но можно легко скомпилироваться без него и получить pure rust). Ещё отмазы будут?
ok, спасибо добрый аноним, буду знать: проект есть (хотя про "огромную" звучит конечно как шутка - в лучше случае 1% от всех пользователей grep)на 100000 Rust евангелистов нашелся 1 проект, отлично. но консольная утилита, это не тот уровень, который позволит переписать Linux, даже не близко.
про отмазу не понял.
FYI: ripgrep пользует VS Code, и на винде тоже. Так что, опосредованно его юзает куда больше 1%.
> ripgrep, который is faster than $insert_your_grep_hereГде сравнения? Что за бред... Т.е. возможности те же и он быстрее? Не поверю. Что rust преобразуется в какой-то "особенный" машинный код, который не известен Си компилятору?
>> ripgrep, который is faster than $insert_your_grep_here
> Где сравнения?https://blog.burntsushi.net/ripgrep/
Не только сравнения, но и объяснения, почему так. Но ты читать, конечно, не будешь, многабукав.
Чудо, ты само-то читало то, что там написано?Оно быстрое - да. Но не потому, что rust такой волшебный, а потому, что они там нахакали либу regexp, сдобрив её simd-инструкциями вручную. Блин, может, поэтому у rust хреново с переносимостью :-)... Такие же точно правки можно сделать для libc regexp и напичкать x86-специфичными хаками. Будет очень быстро, но только на x86 работать. И нафига оно надо?
> Оно быстрое - да. Но не потому, что rust такой волшебныйА никто и не говорил, что он быстрый благодаря Rust. Ты сам успешно спутал в своей голове два разных вопроса («есть ли жизнь на Rust?» и «кто сказал, что ripgrep быстрый?»).
> потому, что они там нахакали либу regexp, сдобрив её simd-инструкциями вручную.
> напичкать x86-специфичными хакамиТо есть оптимизацию алгоритмов Бойера—Мура и Ахо—Корасика, unicode-aware конечные автоматы и использование mmap только там, где это выгодно, ты успешно пропустил. Говорил же, что многабукав.
Более того, тот же memchr в glibc уже давно напичкан SIMD-хаками под все мыслимые архитектуры. Что переносимости не мешает совершенно, как и не мешает rg использовать Ахо—Корасика там, где нет нужных инструкций.
Лучше бы вы над переносимостью PCRE JIT плакали, но вы и этого делать не будете, потому что вам переносимость только в комментах на опеннете нужна.
> А никто и не говорил, что он быстрый благодаря RustВот и разобрались.
Спасибо за ссылку. Занимательное чтиво. Авторам уважуха за проделанную работу.
> сишники никогда на Rust не перейдут (я вам как сишник говорю)Кстати, почему? Про плюсы слышал, что сишники их переусложнёнными считают, а код на них - неочевидным. С растом та же ерунда?
Одна из причин, потому что у Си есть куча компиляторов для очень экзотических архитектур, а у раста только те архитектуры, что поддерживает LLVM.
Потому что сишники - ретрограды. Они даже на C++ перейти не могут. В архитектуру и ООП они тоже не могут.А плюсовикам Rust не нужен без ООП (с наследованием и полиморфизмом, без них целый класс шаблонов проектирования невозможен (большая часть шаблонов проектирования не абстрактные вещи, а рецепты достичь чего-то при наличии определённых базовх фич в языке, в Rust этих фич нет), а замены нет, и код превращается в гoвнoкод). Строить суррогат ООП на Rust так же, если не более, гиморно, чем строить суррогат ООП из си.
Ты сам то пробовал что-то на Rust написать? Все там замечательно с ООП.Но, ты, конечно сможешь привести *конкретные* пример нереализуемых на Rust "шаблонов проектирования не абстрактных вещи". Или нет?
Абстракные фабрики фабрик абстракных фабрик там не особо получаются.
Это вот очень распространенное такое заблуждение про "Rust без unsafe". Не должен он быть без unsafe, да и зачем он был бы такой кому-то нужен. Unsafe блоки - это не для того чтоб их не было, это для того что б их аккуратно огородить и тщательно контролировать. Так же как и side effects в Haskell, например.С unsafe в Rust проблемы совершенно другие - в первую очередь, с тем что оно очень плохо стандартизировано. У определенного вида итераторов в С++, например, понятно какие гарантии чего, а в unsafe Rust все очень ad hoc в этом смысле.
С unsafe у раста все хорошо.
Есть https://doc.rust-lang.org/nomicon/index.html
Другое дело что оно не всем надо (там прям в первых двух абзацах это написано).
Можно начинать!
https://github.com/lizhuohua/linux-kernel-module-rust
> могут быть эксплуатируемы при подключении к компьютеру специально подготовленных USB-устройствинтересно, КАК они собираются запатчить ядро чтобы защититься от юсб устройств? при каждом подключении любого девайса выводить окно "обнаружена хрень, которая прикидывается клавиатурой, кивните в камеру, если согласны что это клавиатура" ??
Только по честному выпиливать ошибки, другого пути нет. Никто не мешает залить в контроллер нормальной клавиатуры кастомную прошивку, так что кивнуть в камеру - не спасет. Просто фаззинг-тестирование нужно автоматизировать и делать на этапе принятия патчей и новых драйверов в ядро.
Как вы себе это представляете, и какова, по вашему мнению, будет скорость принятия патчей?
>Как вы себе это представляетеА я думал что уже даже дети знают про CI.
> скорость принятия патчей?Ну прибавь к операции merge время на выполнение тестов (hint: их можно запускать параллельно).
Можно жить и без тестов. Только вот тогда возникает другой вопрос какова будет *скорость починки и обнаружения 0-day* по сравнению с CI? И соотносим финансовый и репутационный ущерб от тех же 0-day с затратами на CI инфраструктуру?
Ну и какой репутационный ущерб нанесли Линуксу все те 0-day что в нем были, есть и будут? Вот вы после каждого CVE везде Линуксы заменяете на L4 или хотя бы на OpenBSD?
Фаззинг это рэндомное тестирование, которое ничего не гарантирует.
> Фаззинг это рэндомное тестирование, которое ничего не гарантирует.«ну не човчем»
Насколько знаю, современные фаззеры (тот же AFL) трассируют выполнение кода, выделяя условные ветвления и базовые блоки. А дальше по полученной информации входные данные строятся не совсем случайным образом, а исходя из максимизации покрытия путей в программе (т.е. 100500 раз ходить по одним и тем же путям, ни разу не посетив другие, никто не будет).
Не сказать, что эта задача просто (или хотя бы красиво) решается в общем случае, но результаты на реальном коде весьма впечатляют.
Ага, на "Hello world!"... А, иначе: вариантов - бесконечность, как у шахмат.
Без IOMMU не поможет ничего.
Для USB в IOMMU нет необходимости (по крайней мере, толку), кстати говоря. Подключенное устройство само не может инициировать какую-либо активность (и уж тем более обращение к памяти), только отвечать на запросы хоста (которые хост-контроллер переписывает ровно по тем адресам, которые ему выделил драйвер, так что IOMMU, настраиваемый ровно тем же драйвером, тут ничего не ограничит дополнительно). Т.е. напрямую полазить где не надо — невозможно, только скормить кривому драйверу такой ответ, от разбора которого у драйвера улетит кукушка.
Спасибо за прояснение.
Поблагодарте и за дезинформацию... ("забыты" дыры в контроллере)
поддерживаю первого отвечающего.
не от usb устройств нужно защищаться, а от некорректных ответов от них. если бы была валидная проверка на переполнение буферов, на то что мы прочитали столько байт, сколько запросили, на то что строка не содержит символ '\0', и т.д. не было бы такой проблемы - драйвер бы ругнулся в dmesg что при работе с устройством возникли проблемы и не было бы уязвимостей.
И эта проверка проверяла бы вообще все, строго согласно спецификации, и не содержала ошибок, и была бы написана на Coq вместо Си - тогда может быть.
...А, может и не быть. В 99% случаев даже скорей.
Да, например при подключении МФУ в определенный момент он может сказать, что он есть сканер. А у сканера точно могут быть кнопочки. И что каждый раз кивать в камеру?!!!
Зачем, МФУ за вас и кивнёт...
> Атака возможна при наличии физического доступа к оборудованию и может привести как минимум к краху ядраСкучно. При наличии физического доступа любой бухгалтер сумеет дёрнуть штепсель.
Скучно, если диск нешифрованный… а, он и так у всех нешифрованный. Ладно, тогда так:Если дёрнуть, то атакующий уже никогда не узнает, какую порнуху ты смотрел в приватных вкладках браузера.
Некоторая разница есть. Вилку из розетки можно выдернуть ~только в тот момент, когда за неё тянешь.А вот устроить DoS в наиболее подходящий момент с помощью заранее подкинутого копеечного устройства (которое может хоть годами работать и не выдавать своей второй натуры) — совсем другое дело.
В случае с розеткой сделать отложенный DoS, конечно, тоже возможно, но заметно сложнее и дороже. А если нужно не только DoS, а и потерю (или даже повреждение) данных, или вообще RCE — тут всё-таки USB даёт дополнительные возможности.
Так что не просто так изучают такие атаки, не просто так.
Удалить драйвера, да и дело с концом!
Потом вам прилетит обновление ядра и драйвера зальются заново. Только блэк-лист в modprobe.conf спасет великого комбинатора.
не спасет. они их той же modprobe подгрузит когда у него закончатся идеи по паеребросу файлов с устройства на устройство)))
USB вообще не нужон, пора на pci-e переферию делать
>USB вообще не нужон, пора на pci-e переферию делатьТак уже давно выпускают, в чем проблема купить -цена?
Или просто сказать умную вещь хотел?
Кстати насчёт ненужности юсб:в интерфейсе Thunderbolt 3-й версии используется разъём USB Type-C.
Добавлю ,согласно вики 4 версия юсб будет фактически Thunderbolt 3,права на это порт переданы консорциуму Usb Forum.
А что новый разъём не будет уметь тогда?
Угу чтобы любое дежице имело доступ ко всей памяти. Хороший план.
Этот план уже однажды успешно провернули под кодовым названием "FireWire/1394". "Backdoorbolt" всего лишь готовится заступить на смену.
>Угу чтобы любое дежице имело доступ ко всей памяти.Ну вообще-то в спецификациях заложено изоляция DMA посредством IOMI ,другое дело что на это дело производители опереционок и железа забили болт.
IOMI правка IOMMU.
#Корректор гугловский шибко умный
>IOMMUТак он есть далеко не у всех.
>>IOMMU
> Так он есть далеко не у всех.И мало того, что не у всех он есть, так его ещё и настроить (и не накосячить при этом) — то ещё развлечение. А при этом надо ещё и производительность не угробить: если прибить адреса буферов для DMA гвоздями, сильно усложнится реализация т.н. подхода zerocopy сразу в память приложений и из неё, а если постоянно перенастраивать — легко накосячить.
Идея монолитного ядра для универсальной ОС в 21 веке идиотизм.
где монолит?
https://www.youtube.com/watch?v=G5Kl7IsDano
Как видите GNU/Hurd не взлетел и совсем не развивается (или я ошибаюсь?)
Ты опять выходишь на связь, Таненбаум?
rtsx_usb когда-нибудь пофиксят? уже давным давно в ядре рабочий драйвер заменили нерабочим, и делают вид что так и надо
сразу после rio500это ж впопенсорс, тебе никто ничего не должен - в том числе и не ломать что работало.
О, шансы взломать телефон с занлючившим пинкодом повысились :)
> О, шансы взломать телефон с занлючившим пинкодом повысились :)Мысль интересная, конечно (особенно с т.з. получения рута на нынешних нездорово огороженных аппаратах). Но не у всякого телефона есть USB Host или полноценный OTG (да ещё и включённый по умолчанию), да и драйверы для внешних устройств почти никогда не кладут в прошивку. Так что упс.
Ну что, параноидальная тяга к смене нумерации ядер не дала Торвальдсу автоматической избавлялки от багов. Может быстрей надо номера версий менять? А вдруг ? Действительно, сколько там кода от этого Торвальдса ? Хрен да нехрена уже. Его вклад какой? Теперь то уже небось меньше процентика. Может у сообщества поинтересоваться мнением - что лучше номер по круче? или баги научиться находить? Или этот Линус царьком себя мнит, хочу новый номер ядру, хочу Крым, хочу Гренландию. Удачный хотелок Торвальдс!