В конце мая 2020 года команда специалистов по информационной безопасности из США и Швейцарии опубликовала в открытом доступе свое исследование, в ходе которого они смогли обнаружить 26 уязвимостей в наборе драйверов USB, используемом операционными системами Linux, macOS, Windows и FreeBSD. В настоящее время часть уязвимостей закрыто разработчиками ОС.
Исследователь Матиас Пейер (Mathias Payer) из группы разработчиков HexHive совместно с экспертом по ИБ Хуэй Пэн (Hui Peng) из университета Пердью, проводили тестирование при помощи ранее созданного ими инструмента — USBFuzz. Фактически, они использовали технику фаззинга для отправки по USB некорректных, неправильных или просто случайных данных.
Перечень ОС, на которых проверялся USBFuzz: Linux (ядра v4.14.81, v4.15,v4.16, v4.17, v4.18.19, v4.19, v4.19.1, v4.19.2 и v4.20-rc2), FreeBSD 12, MacOS 10.15 Catalina, Windows 8 и Windows 10. В каждой из ОС были установлены самые последние доступные обновления, включая патчи для безопасности.
В результате тестирования были обнаружены:
- одна уязвимость в FreeBSD;
- три уязвимости в macOS, причем две из них вызывали перезагрузку ОС, а одна смогла заставить систему зависнуть;
- четыре уязвимости в Windows, которые приводили к появлению BSOD (синего экрана смерти);
- восемнадцать уязвимостей было обнаружено в USB-стеке Linux. Причем одиннадцать из них уже пропатчены, а для остальных также будут выпущены заплатки.
Пейер и Пэн планируют рассказать о своих исследованиях на конференции по виртуальной безопасности Usenix Security Symposium, которая должна пройти в августе 2020 года.
Примечательно, что разработчики также обещают выложить на GitHub репозиторий с кодом USBFuzz. В настоящее время страница с этим проектом еще недоступна.
Ранее в ноябре 2017 году ИБ-специалист Google Андрей Коновалов применил к USB-стеку ядра Linux инструмент syzkaller и фаззинг. Тогда он смог обнаружить 79 различных багов. Причем их можно эксплуатировать только при помощи вредоносного USB-устройства, то есть злоумышленнику нужен физический доступ к уязвимому ПК. Также обнаружилось, что большинство найденных им уязвимостей это простые DoS-баги, которые провоцируют «зависание» или перезагрузку. Однако, некоторые из обнаруженных Коноваловым уязвимостей все же позволяли злоумышленнику выполнить произвольный код в контексте ядра Linux.
AndreyDmitriev
По поводу BSOD в Win10 и USB имею сказать следующее. Мы поставляем промышленные системы, в составе которых есть устройства, подключённые по USB и отнесённые от компьютера на 10-15 метров. Там летят некритичные данные. Соответственно используются активные удлинители, но всё это стоит, скажем, на литейном заводе, где вокруг источники помех, да и в составе самих систем несколько мощных сервомоторов. С прекращением поддержки Win7 мы начали поставлять это дело на Win10 (собственно и заказчики это требуют) и вот столько BSOD я не видел уже давно.
На одной пусконаладке когда это случалось несколько раз на дню, я обратил внимание, что BSOD возникает в основном в момент старта или останова серв.
Меня это так достало, что я взял осциллограф, подоткнул его к D+/D- и выяснил, что там прилетают хорошие такие помехи, которые, судя по всему, выносят мозги драйверу и он роняет всю систему (причём в отчётах об ошибках был нуль полезной информации — там то по памяти, то по пререрыванию, то по ядру ошибки). Решили проблему заменив дешёвые удлинители на дорогущие с опто развязкой (там, фактически USB over IP), ну и «землю» разведя чуть иначе. Железо это мы давно используем и Win7 на нём была «стрессоустойчива», а десятка — в этом смысле не так стабильна.
a_freeman
Ужасно, винда и USB, плюс в составе системы мощные сервомоторы… а когда заказчика располовинит кто будет виноват, разработчики стандарта USB или Майкрософт?
AndreyDmitriev
Я ждал этого комментария. ;). На самом деле когда заказчика располовинит, будет отвечать прежде всего инженер, спроектировавший цепи безопасности (и в этой области проколоться тяжело, потому что есть промышленные стандарты, которым просто нужно следовать). Вообще эта тема выходит за рамки простого комментария, но если вкратце, то вы будете сильно удивлены количеству «винды» в цехах промышленных предприятий. Я работаю в довольно большой американской корпорации в Германии и занимаюсь этим уже почти четверть века. В конце девяностых мы ставили системы с OS-9. Это была юникс-подобная система жёсткого реального времени, которую «положить» было практически невозможно, причём SCADA мы делали под Linux Red Hat, но сами заказчики стали просить решения на Windows, в основном, потому что найти инженера, знающего OS-9/Linux чуть сложнее, чем Windows. Мы переехали на Windows 2000, ну и затем XP, семёрка и вот теперь десятка. Там всё чуть сложнее, чем в «бытовых» или «офисных» условиях. Как правило заказчики критичных систем, задействованных в производстве машин, на которых вы ездите, или смолётов, на которых вы летаете, имеют свои образы систем, специальным образом подготовленные, со всеми там секьюрными патчами и т.д., кроме того некоторые требуют раскатывания систем на строго определённых промышленных ПК, которые несколько отличаются от офисных. Все цепи, ошибка которых приведёт к «располовиниванию» заказчика на зависят от ПК — сейчас используются ПЛК с «безопасными» (их ещё «жёлтыми» называют) модулями (а раньше весь шкаф был забит модулями PILZ/PNOZ), и они там сдублированы, даже провода на кнопки останова постонно проверяются на обрыв и т.д. А под Windows крутится SCADA, либо машинное зрение, и если винда улетит в BSOD, то в данном случае ничего страшного не случится (ну кроме того, что система встанет). Все системы которые мы ставим, работают 24/7, я в командировах видел аптаймы по нескольку месяцев. Ну а USB — мы используем в промышленности кое-какое медицинское оборудование, и там много чего управляется по USB (раньше было RS232). Это — головная боль, конечно, но такова уж реальность, ибо разработка железяки с другой шиной просто нерентабельна (про полевые шины, применямые в промышленности я в курсе, разумеется)
А да, несколько лет на выставке в Ганновере KUKA поставила пару сидений на робота и катала всех желающих. Так вот там WinXP, на которую поставлен VxWorks:
a_freeman
Такое описание звучит гораздо лучше! С креслом на манипуляторе KUKA для меня самого возник интересный этический вопрос: а чему вообще доверять(winXP, Linux, *RTOS).
Приходит мысль, что соответствие автомобильным стандартам безопасности это единственное, что могло бы убедить меня в безопасности такой системы и внутреннем одобрении на тест-драйв :)
Abyss777
На восьмерке был баг. При вытаскивании флешки отформатированной в udf случался BSOD в 100% случаев. Потом пофиксили вроде.
usrsse2
Ну это скорее в драйвере файловой системы баг, а не в USB
Abyss777
Ну при вытаскавании CD/DVD с такой же фс такого не происходило. Да и на семерке не проявлялось.
usrsse2
CD/DVD разрешает вытащить ОС, т. е. сначала файловая система отмонтируется. А флешка извлекается неожиданно для системы.
Хм, это идея – можно было бы сделать USB-порт, который штифтами через дырочки блокирует извлечение флешки до тех пор, пока ОС не разрешит.
Abyss777
А если скрепочкой диск вытащить :) Но я так если честно не пробовал
StSav012
Несколько лет назад у меня китайский спектроанализатор ронял ядро тогдашней Ubuntu через пару секунд после подключения по USB. Я так на него обиделся, что раздумал проверять более новые ядра. А потом и необходимости не стало.