URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 124248
[ Назад ]
Исходное сообщение
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на уровне ядра Linux"
Отправлено opennews , 14-Май-21 12:59 
Выявлены две новые уязвимости в подсистеме eBPF, позволяющей запускать обработчики внутри ядра Linux в специальной виртуальной машине с JIT. Обе уязвимость дают возможность выполнить свой код с правами ядра, вне изолированной виртуальной машины eBPF. Информацию о проблемах опубликовала команда Zero Day Initiative, проводящая соревнования Pwn2Own, в ходе которых в этом году были продемонстрированы три атаки на Ubuntu Linux, в которых использовались ранее неизвестные уязвимости (связаны ли уявзимости в eBPF с данными атаками не сообщается)...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=55150

Содержание
Сообщения в этом обсуждении
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 14-Май-21 12:59 
Никогда же ж не было и вот, ОПЯТЬ!
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Анто769ним , 15-Май-21 11:05 
Теоремы Гёделя о неполноте не оставляют никакой надежды на покой.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Ананоним , 15-Май-21 15:31 
Да не опять, детка, а постоянно!
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 17-Май-21 16:46 
Нах JIT и все ПО которое его использует!
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Леголас , 14-Май-21 13:01 
для Винды-то поди аналогично
https://opennet.ru/55127-ebpf
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:38 
Ну если код коммуниздили, а это наверняка так, то естесственно.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено hindoohindoo , 14-Май-21 16:37 
только мелкомягкие не будут исправлять как всегда
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено lufog , 14-Май-21 19:22 
Исходные тексты eBPF для Windows открыты под лицензией MIT. Если бы хоть намек был что код коммуниздили уже бы такая вонь поднялась.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 13:01 
Кто бы мог подумать: JIT и вдруг перфорация!
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 14-Май-21 13:08 
ну вон в isotp нет джит, а перфорация первосортная, никакого CAP_SYS_ADMIN (помните, я намекал дурачкам, почему это - дурная и никуда негодная "безопастность" в отличие от правильными руками написанной просто suid root программы?) не надо чтоб стать рутом.

Оно, понятно, нафиг ненужно и можно было в нормальных ядрах просто не включать - но где вы видели дистрибутивы с нормальными ядрами, не считая васянских локалхостовых? Если ручка есть, за нее непременно ж надо дернуть!


"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 13:21 
Оно больше не отключается в ядре емнип, уже давно.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 14-Май-21 14:02 
да ладно? Это ж детали совершенно ненужного can-bus, я немного охренею если у меня в сервере такой заведется. (а дальше включит передачку и уедет на автопилоте, что-ли? Сервер!)

Хотя, конечно, где умные холодильники, там и серверы с автомобильным шасси в комплекте будут :-(

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено InuYasha , 15-Май-21 15:05 
а ты думал - зачем серверам по 6 турбин на 15000об/мин? :)))))
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 13:47 
Кто бы мог подумать: язык C из 70-х годов прошлого века и вдруг перфорация!
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:00 
Твой святой Раст тоже не защищает от уязвимостей. От уязвимости могут защитить только прямые руки.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 14-Май-21 14:04 
Ну ты гонишь! Прекрасно защищает от уязвимостей - НИ ОДНОЙ уязвимости в растокоде ведра еще не обнаружено!
Нет кода - нет и уязвимостей. От уязвимостей в CoC.md никому особого вреда и нет.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Урри , 14-Май-21 14:03 
Подумать только, топор из железного века и вдруг ногу отрубил.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:19 
Что характерно лазером из 21 века можно сделать тоже самое.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноньимъ , 15-Май-21 09:33 
У большинства доступа к таким вещам нет. А у тех у кого есть 20кратная проверка всего от ануса до школьных друзей жены и прочная цепочка командования.

Лазером в 21 веке можно глаза себе и случайным свидетелям выжечь, это да.

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

Топором нужно рубить лес или людей. Но для этих целей в 21 веке есть спец сверхэффективные комбайны.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 17-Май-21 16:52 
ПО с JIT это первое что надо выкинуть, а после systemd с dbus.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Анонисмус , 14-Май-21 13:15 
Тащите больше всякого хлама в ведро.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 13:19 
Стоит уже начинать новости как "очередные уязвимости в подсистеме ebpf", лол.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 13:41 
В формате еженедельной рубрики.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 13:45 
>Атакующий может воспользоваться данной ошибкой для чтения и записи данных вне границ выделенного буфера.
>размер выделенной области памяти может оказаться меньше фактического размера

Ну как там на Сишечке любимой, нормально писать? Сколько дыр/сек?

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Нонаним , 14-Май-21 13:50 
Напишите adobe flash на "не-сишечке", чтобы оно стало самым безопасным в мире.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 14-Май-21 14:09 
Пишуть! Но пока...
chore: Bump wgpu from 0.8.0 to 0.8.1
@dependabot
@Herschel
dependabot authored and Herschel committed 4 days ago
chore: Bump enum-map from 1.0.0 to 1.1.0
@dependabot
@Herschel
dependabot authored and Herschel committed 4 days ago
chore: Bump syn from 1.0.71 to 1.0.72
@dependabot
@Herschel
dependabot authored and Herschel committed 4 days ago

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

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 23:01 
Напиши на сишечке так чтобы видео проигрывалось
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 17-Май-21 16:45 
> Напиши на сишечке так чтобы видео проигрывалось

дык, адоба двадцать лет назад уже написала, проигрывалось. Довольно таки в крупных масштабах, например, Ютуб называлось, слышал?

Но оно не использовало usafe, поэтому было небебебезопастно! И вообще немодная устаревшая фигня - даже не могло стырить у тебя ключи ssh при попытке просто посмотреть исходник редактором.

Поэтому адобу его запритили-запритили использовать. Вот, жрем чодали. Так себе местная кухня.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 23:33 
а что не так-то?
вкалывают роботы) версии пакетов подымают автоматом… сишечке такое и не снилось - там либо всё написать самому, либо помучаться и подключить внешнюю библиотечку, тоже на си, но вот без авто-обновлений
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 17-Май-21 16:42 
> а что не так-то?
> вкалывают роботы)

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

> версии пакетов подымают автоматом… сишечке такое и не снилось

естественно. Там не принято автоматом тащить в рот только что из под хвоста упавшее, там, не поверишь, некоторые _бэкпортированием_ критичных изменений занимаются, представляешь? У них вообще нет девиза "новое - значит лучшее!"
Чтоб не чинить без конца за роботом поломанное очередным безумным обновлением, и да, если ты пороешься в истории, такое в этом проекте не раз уже было, и даже специально пришлось пореже обновляться, не успевают человекоподобные "роботы" переписывать код в соответствии с последними веяниями прогресса.

> там либо всё написать самому, либо помучаться и подключить внешнюю библиотечку,
> тоже на си, но вот без авто-обновлений

к счастью, да. Некоторые библиотечки как написаны в 1994м году, так по сей день и работают. Хотя наверное даже уже не соберутся новым-модным-C2999 компилятором.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено bi brother , 14-Май-21 13:59 
Помнится, при аналогичной дыре в мазилле без си, здешние фанбои пели и танцевали что это никакая не дыра)) Может и здесь не дыра, а?)
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:03 
А теперь попробуй объяснить причем тут сишечка?
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 13:52 
Прикладывать Раст к дырам 5 раз в день до полного выздоровления.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 13:56 
Я приложил раст к своей дыре, и теперь она печёт. Что делать?
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:01 
Теперь самое главное доказать всем окружающим что у вас на самом деле ничего не печёт/течёт а у них у самих печёт/течёт.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноньимъ , 15-Май-21 09:35 
Вымыть жаваскрипт мылом без фреймворков и смазать питоном.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 15:24 
Ржавая дыра, все равно дыра
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Kuromi , 14-Май-21 22:34 
В свое время раны нанесенные РЖАВЫМ оружием были самыми страшными т.к. практически гарантировали заражение. Так что...
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноньимъ , 15-Май-21 09:36 
Не ржавым, а вымазанным сами знаете чем.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:12 
Почему если Си такой простой, быстрый и удобный как швейцарские часы, в нем опять оказалось переполнение буфера?
Такое впечатление что код для ядра пишут необразованные растомакаки не умеющие убирать за собой выделенную память, которые не способны отследить выход за границы переменных и буфера. Кто их вообще допустил до написания кода ядра?
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:17 
Если Раст такой сложный и якобы безопасный почему на нем еще не написали ядро?
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:32 
Потому что растобои пишут не на расте, а про раст.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Анто Нимно , 14-Май-21 19:27 
Потому что язык проца - ассемблер. А Сишечка всего лишь syntax sugar for the language. И как-то тогда stupid to write using другой язык.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено пох.. , 14-Май-21 21:24 
> Потому что язык проца - ассемблер. А Сишечка всего лишь syntax sugar for the language.

проблема только в том, что она sugar для language процессора pdp11/70

за sizeof(char) вместо byte, в которых она всё меряет, хочется убивать, убивать, убивать.
То есть вот отдельно за char, который давно уже что угодно, только не символ, потому что символы в него давным-давно не помещаются, и еще разок за sizeof и порождения сотоны которые приходится использовать когда надо таки адресовать куски памяти, помещающиеся в регистр.

Причем БЫЛ byte, и был выкинут потому что "кто бы мог подумать, что юникс проживет так долго".

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено anon2 , 15-Май-21 20:11 
С божественен.
В языке минимальная адресуемая ячейка памяти - char, соответственно и размеры объектов в char’ах.
Зачем вам размеры в байтах, если из языка можно адресовать не менее char’а?
char - по определению может хранить любой символ из basic character set, только и всего. Для хранения, скажем любого unicode символа, не подходит - используйте тип нужного размера.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено lockywolf , 16-Май-21 18:09 
Нет такого типа, который может хранить произвольный юникодный символ. Упс.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 17-Май-21 16:51 
> Нет такого типа, который может хранить произвольный юникодный символ. Упс.

uint32 чем, к примеру, не подходит? Ну или реализацие-специфичный wchar_t Кроме вот того самого, что это не настоящие типы и любое его применение по назначению требует массу вредных костылей.

utf, если ты его вместо юникода имел в виду, как раз очередной костыль чтобы сохранить благословенный святым Ритчи char.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено lockywolf , 18-Май-21 14:49 
>> Нет такого типа, который может хранить произвольный юникодный символ. Упс.
> uint32 чем, к примеру, не подходит? Ну или реализацие-специфичный wchar_t Кроме вот
> того самого, что это не настоящие типы и любое его применение
> по назначению требует массу вредных костылей.
> utf, если ты его вместо юникода имел в виду, как раз очередной
> костыль чтобы сохранить благословенный святым Ритчи char.

Не любой юникодный символ влезет в 32 бита, ни даже в любую структуру данных фиксированного размера. Какая конкретно мультибайтная кодировка используется, будет влиять на 99% текста, но на оставшийся 1% всегда найдётся какой-нибудь гад, который сгенерит цветную мохнатую последовательность, которая формально при этом всё равно будет "один символ".

Ну, то есть, конечно, вы можете выкрутиться, если ваш wchar_t -- это void*, но даже в таком случае конкатенация не будет работать.

Ya-to sam, voobsche govorya, hotel by, chtoby za predelami 7 bit nichego bylo ne nuzhno.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 18-Май-21 18:44 
> Не любой юникодный символ влезет в 32 бита

любой символ _unicode32_ занимает _ровно_ 32бита. Почувствуйте разницу с костыльным угребищем utf.

wchar_t это unicode16 - впрочем, он намеренно сделан _t, чтобы разработчики не закладывались на его размер. Сегодня 16, завтра в новой версии windows - запросто окажется 32.
Гарантируется только что в _данной_системе_ один символ занимает один wchar_t. _Всегда_, даже если он из ascii набора. А вот uint32 гарантированно 32 бита. Это _разные_ сущности, и по хорошему- именно так бы и быть в нормальном низкоуровневом языке с самого начала, а не костылингом создавать.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено lockywolf , 18-Май-21 19:04 
> любой символ _unicode32_ занимает _ровно_ 32бита. Почувствуйте разницу с костыльным угребищем
> utf.

Это чушь. Во-первых, нет никаких unicode32, есть utf32.

Во-вторых, нет понятия "символ Unicode", есть понятие Unicode Codepoint.

Который не равен символу, не равен одному значению utf16 (гуглите суррогатные пары), и, что ещё хуже может быть в будущем не равен одному значению utf32. (Хотя пока равен)

Но что ещё хуже, кодпойнты сами по себе не являются осмысленными адресуемыми элементами. Разбитие пополам одного символа (который может быть представлен хоть массивом в 512 байт в случае "мохнатых символов") может дать два, один, или ни одного осмысленного символа.

Больше того, разбитие не пополам, а как-то иначе тоже может дать какие-то валидные символы, или не дать.

Это всё абсолютно не зависит от конкретного байтового представления кодпойнтов. Юникод сделан, задизайнен, принципиально так, что его можно обрабатывать _только_ сначала и до конца, последовательно, и за О(N). Всё.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 19-Май-21 16:45 
У тебя утф головного мозга.

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

В нормальных операционных системах к тому времени давно применяли кодировки с _фиксированным_ размером символа. Лет этак восемь. Ничего общего с utf у них нет, никакие символы пополам там не делятся.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено lockywolf , 20-Май-21 15:18 
> У тебя утф головного мозга.
> utf любого сорта НЕ ЯВЛЯЕТСЯ единственно верным и единственно возможным стандартом кодировки
> юникода.
> Собственно, до впиндюривания этого ненужного мусора в веб ради экономии ненужных байтов
> на фоне мегабайтов хлама, единственным его использованием было в линуксах. Где
> просто ниасилили ничего другого.
> В нормальных операционных системах к тому времени давно применяли кодировки с _фиксированным_
> размером символа. Лет этак восемь. Ничего общего с utf у них
> нет, никакие символы пополам там не делятся.

Ну и как называется эта магическая кодировка, в которой один символ один тип?

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:43 
Потому что ядро написать памятебезопасно - не языком ворочать, и не пальцами по клаве, а мозгами. На расте труднее программировать, чем на си, ибо на си у тебя будет уязвимость, но и будет рабочая программа, а на расте если компилятор не сможет доказать, что программа памяте- и потокобезопасна, то ты проследуешь перепроектировать. И плевать компилятору, что **тебе кажется**, что она безопасна.

Ядро своё нормальное с минимальными требованиями к современным ядрам по поддержке всего ЗООПАРКА де-факто полузакрытых (некоторые документы есть в инете, но не все, а что есть - с надписями Confidential, Copyright, Trade Secret, ну вы поняли, а остальные частично отреверсены) проприетарных отвратительно документированных под-NDAшных стандартов и даже на сишке написать - нетривиальная задача на годы работы для крупной команды. А на расте - сложнее раз в 10.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Анонус , 14-Май-21 15:24 
https://www.redox-os.org/
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Жинон , 14-Май-21 15:32 
Ресдох, не?
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 17:20 
Эта шутка уже не смешная.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:34 
Потому что Си - это диагноз. Адекватные сишники давно уже переехали на  C++. Вот у них всё в порядке, и UB компилятором детектируется и еррорится, и умные указатели где надо используются, и в коде архитектура есть, а не говнокод, как ортодоксальные сишники любят.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено B , 14-Май-21 14:54 
>> UB компилятором детектируется и еррорится,

Давно откинулся?

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Michael Shigorin , 14-Май-21 18:31 
Не силён в наркоманском сленге, но это скорее по той части случай.

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

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено InuYasha , 15-Май-21 15:09 
Кстати, хорошая идея для проведения исследования: найти самый крупный проект, в котором никогда не было ни одной ошибки. Ну или минимум ошибок. Это реальнее :)
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 18-Май-21 01:15 
> Кстати, хорошая идея для проведения исследования: найти самый крупный проект, в котором
> никогда не было ни одной ошибки. Ну или минимум ошибок. Это
> реальнее :)

сейчас тебе опять TeXовый мусор притащат. Даром что тот, "настоящий" - нигде не работает, а сам по себе еще и в современных условиях феерически бесполезен.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено InuYasha , 18-Май-21 11:50 
Привет от соседа, написавшего диссер в техе.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено нах.. , 18-Май-21 14:26 
> Привет от соседа, написавшего диссер в техе.

а у меня сосед в присядку др-чить умеет, и чего?

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 15:48 
Чисто статистически, 100% утечек памяти случается на плюсах, а не на си. Если они так хороши, то чё ж текут так?
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 17:21 
Потому что тебе никто не запрещает вместо умных указателей использовать тупые?
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 21:59 
А я, кстати, давно мечтаю о С++ без обратной совместимости с C. Чтобы за попытки использовать сишные строки или прикапывание указателей куда-нибудь компилятор бил по рукам.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноньимъ , 15-Май-21 09:39 
C# же есть.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 11:10 
Мы внимательно смотрим на обработку argv и использование внешних библиотек без «прикалывания указателей».
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено InuYasha , 15-Май-21 15:12 
А я всегда говорил - надо переписывать linux на ActiveX с полным самоописанием типов данных %)
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Жинон , 14-Май-21 16:01 
Удачи тебе на Haiku
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Michael Shigorin , 14-Май-21 18:30 
> Почему если Си такой простой, быстрый и удобный как швейцарские часы,
> в нем опять оказалось переполнение буфера?

Вы хоть заметили, что перепутали инструмент с объектом?

> Кто их вообще допустил до написания кода ядра?

Вас точно стоит допускать до написания комментариев?

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 07:40 
Даже в безопасной Джаве, где нет указателей, есть NPE. То же самое, приводящее к исключению, есть в "супербезопасном" Хаскеле - fromJust. Короче, теоретически нельзя создать синтаксис+семантику (то есть язык), который бы защитил тебя от тебя. Для этого используются верификаторы, пруверы, чекеры и тесты конечно, а это совсем другая песня
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:35 
Ваще нормально публиковать уязвимости до исправления их в ядре и заявлять про какие-то убогие заплатки для конкретных дистров. Всем пофиг что там в мухоморном дистре запилено. Пусть сами жрут мухоморы.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 14:47 
Пришли иксперты и наверное не зная что это для разгончика начинают какую то ерунду молоть , ну так используйте соответствующее ядро
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено FractAL , 14-Май-21 15:15 
Очередная закладка. А сколько на черном рынке ходит?
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 15:25 
Думаю не меньше 9000
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 15:23 
Патчи из Миннесоты
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Анон Анонов , 14-Май-21 15:28 
Ошибки на самом деле детские. Такие легко допустить, когда в голове держишь всю систему. Тогда можно и про проверки INT32 забыть, и про размер памяти. Скорее всего проверка на OOM есть, про то, что размер может быть меньше тупо забыли.

Тут, я думаю, никакой раст не поможет. Только внимательность и тесты.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноньимъ , 15-Май-21 09:41 
Розги только помогут.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Онаним , 14-Май-21 18:31 
Опять ядро проeBPFали.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 21:23 
Я наверное параноик, но мне кажется, что всё это чудо пилят бывшие коллеги Сноудена - не могут люди, которые пилят ядро быть на столько некомпетентными и криворукими, чтобы так косячить...
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено пох.. , 14-Май-21 21:25 
Ну где же твое ведро, пряморукий ты наш?

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 14-Май-21 22:15 
Читай внимательней - там о том, что эти косяки не от криворукости, а злой умысел.
P.S. Твой высер очень важен для нас - пиши ИСЧО!
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено ИмяХ , 14-Май-21 22:31 
Опенсорс это безопасно, говорили они, миллионы глаз не пропустят ошибку. А по факту оперсорс это просто рай для вирусописателей - даже никакого реверс-инжиниринга проводить не надо, просто читай ченджлоги и юзай вот-вот исправленные уязвимости. Ведь хомячки думают что опенсорс это ещё и свобода - хочешь обновляйся, хочешь - нет и большинство выбирают вариант не обновлять, а то вдруг опять что-то поломается.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 01:38 
Всё так, всё так.

Впрочем, Линус привлекает в основном маргиналов, а миру пофигу на Linux.

В Android'е жутко запатченный форк ядра есть, но Google и это выбросить хочет.

// b.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 02:26 
Да вот не надо, в исходниках дырку найти не проще чем в бинарях (а то и сложнее). Насчёт остального, линукс слишком попсовый уже лет 20 как, когда-то это было интересно маргиналам. Сегодня у каждого ребёнка стоит кали, большинству же просто без разницы в чём браузер пускать.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено макпыф , 16-Май-21 17:04 
> миллионы глаз не пропустят ошибку

Если бы пропустили то данной новости бы не было и о уязвимости некто не узнал бы

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено ИмяХ , 16-Май-21 20:57 
Прочитай новость внимательно. Уязвимость обнаружила группа проффесиональных хакеров, а не сообщество хомячков.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено макпыф , 16-Май-21 22:42 
причем тут это, я ничего про новичков не говорил. Исходя из вашего сообщения - все уязвимости просмотрели, не увидели и милионы глаз не помогли. Но их то нашли и исправили )

а кто, когда и где - про это я ни чего писал.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Kuromi , 14-Май-21 22:32 
Шо, опять? Ведь говорили же что так и будет когда они тащили это в ядро...
Хорошо, конечно, что хоть патчат.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено онанимус , 15-Май-21 00:12 
как отключить eBPF? :)
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено onanim , 15-Май-21 14:24 
bash-4.2# grep BPF_JIT /boot/config-`uname -r`
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_JIT=y
CONFIG_HAVE_EBPF_JIT=y


пересобрать ядро с CONFIG_BPF_JIT_ALWAYS_ON=y, прописать net.core.bpf_jit_enable=0 в sysctl.conf

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено onanim , 15-Май-21 14:25 
> пересобрать ядро с CONFIG_BPF_JIT_ALWAYS_ON=y,

ой, CONFIG_BPF_JIT_ALWAYS_ON=n, конечно же.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 21:54 
Это bpf jit, у нас тут ebpf_jit

>CONFIG_BPF=y
># CONFIG_BPF_SYSCALL is not set
>CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
># CONFIG_NETFILTER_XT_MATCH_BPF is not set
># CONFIG_BPFILTER is not set
># CONFIG_BPF_JIT is not set
>CONFIG_HAVE_EBPF_JIT=y

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 01:34 
Ubuntu 20.04 LTS (Focal Fossa)     Not vulnerable
(code not present)
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 05:06 
Не знаю.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Брат Анон , 18-Май-21 09:35 
Я знаю Ubuntu 20.04 LTS. Kernel 5.4-73... УПСЬ!!! А оно описанным уязвимостям не подвержено по определению. Там нет JIT в ядре))

Мораль сей басни такова: прежде чем всякое такое себе ставить -- подумай головой.

"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено псевдонимус , 15-Май-21 05:00 
Кто бы мог подумать, что в виртуалке с жит будут уязвимости?! Это просто случайность, правильно бывшая опенсоляра хочет это внедрить!;-)
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 09:20 
Всё из–за complexity.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 13:12 
It's because of сложность.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 18:04 
Это вам не какой то майкрософт
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Брат Анон , 18-Май-21 09:37 
Ошибка выжившего. В Линуксе уже этого нет и мы об этом знаем. Есть ли такое у МС (и тем более исправлено ли оно) -- мы этого никогда не узнаем. Или узнаем, но может оказаться слишком поздно.
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Аноним , 15-Май-21 18:10 
А как насчет проверить весь код этих писателей?
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено макпыф , 16-Май-21 22:43 
всмысле ebpf или ядра ?
"Уязвимости в подсистеме eBPF, позволяющие выполнить код на у..."
Отправлено Брат Анон , 18-Май-21 09:39 
> А как насчет проверить весь код этих писателей?

Если готов отвалить 10 лярдов дохлыв енотов на модульное и интеграционное тестирование -- то я за. А если ты не готов отвалить 10 лярдов дохлых енотов -- зачем задавать такие вопросы?