LINUX.ORG.RU

Удаленная уязвимость в драйвере wi-fi адаптеров Realtek

 ,


0

1

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

Уже опубликован эксплоит, вызывающий удалённый крах ядра Линукс. Во многих дистрибутивах проблема пока остаётся нерешенной.

>>> Подробности



Проверено: a1batross ()
Последнее исправление: Pinkbyte (всего исправлений: 2)

Удаленная

Ну если удалённая, то чё о ней писать. Ах-ха-ха

kostyarin_ ★★
()

Хоть бы написали, что проблема относится к драйверу вайфай.

drivers/net/wireless/realtek/rtlwifi/ps.c

На серверах можно выдохнуть...

AVL2 ★★★★★
()

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

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

Я умею читать, поэтому и сказал, что вы бы хоть добавили, что новость про rtlwifi.

С таким же успехом можно было просто ссылку вбросить и разбирайтесь как хотите, ага

annerleen ★★★★☆
()

Уже опубликован эксплоит, вызывающий удалённый крах ядра Линукс.

Даже если бы этот драйвер был на Rust, то runtime bound checker запаниковал и привёл бы к такому же краху (насколько я понимаю).

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

Зависит. Во первых мог бы быть unwind, который бы кто-то поймал и не уронил хотя бы все ядро. Это как exception, только такой, которым не рекомендуется пользоваться.

А во вторых в Rust принято не пользоваться API которые или работают, или падают в таких ситуациях. Я думаю там бы в типах закодили корректность через какой-то Result/Option.

let x:Option<u8> = vec.get(2);
vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

2019й год, сколько можно.

Всемирный кризис же. Корпорации тоже хотят кушать.

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

Это как exception, только такой, которым не рекомендуется пользоваться.

Если это не распространяется на случай использования Rust при написании ОС, то, может, и ОК. (Ну и как с исключениями вобщее, нужно было бы решать вопрос, кому ловить и что с этим делать.) Но если нет, то вряд ли использование сомнительных практик будет разрешено.

А во вторых в Rust принято не пользоваться API которые...

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

gag ★★★★★
()

Решето-решётушко.

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

Просто есть ещё вопрос эффективности. Проверять один раз эффективнее всего. А в Rust такой get будет делать проверку каждый раз. Допустимо ли так делать в данном случае, я не знаю. Вполне может так случиться что в самом горячем коде будут отключать проверки.

Нужно код смотреть, иногда в типах можно закодировать много гарантий чтобы потом не делать проверок в рантайме

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

Ждём no-panic на уровне языка, тогда такое будет невозможно.

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

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

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

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

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

Теоретически доступ и проверка могут работать параллельно, да

Конечно! Жаль только, что все подобные места в ядре последние почти 2 года переписывали для принудительного отключения этой оптимизации. Т.к. оказалось, что процессоры некорректно её реализуют на аппаратном уровне (spectre). К счастью, опционально её можно включить снова, но на серверах этого делать не будут.

gag ★★★★★
()

Удаленная уязвимость в драйвере Realtek

Для звуковушки, я надеюсь? Посвистел в микрофон - и вуаля, рут готов!

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

2019й год, сколько можно.

вопросы туда

Copyright(c) 2009-2012 Realtek Corporation

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

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers...

устанавливаются параметры PCIe (Max Read Request Size) без проверки поддерживает ли такие парамметры хост - только на основании возможностей их железа, на RC мобильных процессоров MRRS в несколько раз меньше чем у их EP. Таких багов большинство - проблема не в языке на котором написано, это вообще фигня не стоящая обсуждения.

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

А в Rust такой get будет делать проверку каждый раз

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

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

Причем чаще всего речь идет о итерации. А значит проверка не один раз, а два раза, если делать доступ по индексу. Обычный код итерации по массиву на С в цикле все равно проверяет граничное условие выхода из цикла. Если в Rust использовать итератор, то будет тоже самое - только одна проверка, так как известно что за итератором лежит правильный адрес

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

Для звуковушки, я надеюсь? Посвистел в микрофон - и вуаля, рут

Неожиданно воплотилась пословица: не свисти, денег не будет)

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