Архив метки: Kernel

А вот помните, когда был кейс со зловредным кодом в node-ipc, удаляющим содержимое файлов на хостах с российскими и белорусскими IP-адресами, многие говорили (да и я тоже), что нужно как-то заранее отслеживать буйных политизированных деятелей опенсурса, которые могут что-то подобное в свои проекты засунуть?

А вот помните, когда был кейс со зловредным кодом в node-ipc, удаляющим содержимое файлов на хостах с российскими и белорусскими IP-адресами, многие говорили (да и я тоже), что нужно как-то заранее отслеживать буйных политизированных деятелей опенсурса, которые могут что-то подобное в свои проекты засунуть?

А вот помните, когда был кейс со зловредным кодом в node-ipc, удаляющим содержимое файлов на хостах с российскими и белорусскими IP-адресами, многие говорили (да и я тоже), что нужно как-то заранее отслеживать буйных политизированных деятелей опенсурса, которые могут что-то подобное в свои проекты засунуть? И, соответственно, их проекты стараться обходить стороной.

Как вчера выяснилось, главный по разработке ядра, используемого чуть менее чем во всех отечественных ОС, позиционирует себя расовым гекльберрифинном, борцом с "агрессией" и, видимо, большим знатоком зимней войны. И вот чего теперь? На такого буйного опенсурсера реакция вендоров отечественных ОС-ей и ИБ регуляторов будет? 🤔

Ознакомился с драмой про удаление 11 российских разработчиков из списка мейнтейнеров стабильной ветки ядра Linux

Ознакомился с драмой про удаление 11 российских разработчиков из списка мейнтейнеров стабильной ветки ядра Linux

Ознакомился с драмой про удаление 11 российских разработчиков из списка мейнтейнеров стабильной ветки ядра Linux. Поглядел оригинальный тред, темы с обсуждением на Хабре и на OpenNet.

Так-то ничего нового, уже после скандала с Baikal Electronics было понятно, что нормально контрибьютить в ядро Linux российским организациям (да и просто специалистам с российским бэкграундом) не дадут.

Могу только повторить:

"Предсказуемо. Опенсурс-опенсурсом, а Linux Foundation это конкретная американская организация. Как и банящий разработчиков GitHub это Microsoft. Понятно каким регуляциям они подчиняются.

Поэтому ядро Linux должно быть своё. Например, от ИСП РАН. И репозитории должны быть свои. И дистрибутивы Linux. Это породит дополнительную фрагментацию и несовместимость, но это выглядит как неизбежные издержки."

И от термина "Linux" тоже неплохо бы уйти в перспективе. 🤷‍♂️

На прогибы Торвальдса сотоварищи смотреть, конечно, тошновато, но другого я от just4fun-щика и не ожидал.

Прожектор по ИБ, выпуск №4 (24.09.2023)

Прожектор по ИБ, выпуск №4 (24.09.2023). Записали вчера очередной эпизод, состав тот же:

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

0:35 Как зашёл прошлый эпизод
2:08 Лев и Максим делятся впечатлениями от Kazan Digital Week
7:06 На какие мероприятия по ИБ мы ходим
11:06 Приостановка сертификата ФСТЭК на Dr.Web Enterprise Security Suite
19:04 Cisco покупает Splunk
25:59 Про RCE уязвимость BDU:2023-05857 в модулe landing CMS "1С-Битрикс: Управление сайтом".
30:02 Новые подробности инцидента с FDM и скрипт для детекта
32:21 Занятные моменты детектирования Linux уязвимостей на примере CVE-2022-1012, RPM-based дистрибутивы и импортозамещение
44:02 Прощание от Mr. X

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux. Есть уязвимость ядра Linux CVE-2022-1012. Вопрос: вы можете продетектировать эту уязвимость в CentOS/RedHat 7?

Уловка в том, что VM-вендоры, как правило, детектируют уязвимости на основе бюллетеней безопасности Linux-вендоров. Т.е. они могут продетектировать только те уязвимости, для которых уже есть фиксы и понимание какие версии пакетов уязвимы. А для этой уязвимости RedHat пишут, что да, она аффектит дистриб, но они не будут исправлять её в CentOS/RedHat 7. Можно было бы предположить, что 7ая версия, наверное, уже EOL. Но нет, для 7ой версии EOL наступит только в июле 2024 года.

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

1. Присутствует в ещё поддерживаемой версии ОС.
2. Не может быть исправлена установкой обновления от Linux-вендора.
3. Не может быть продетектирована, если только VM-вендор специально не озаботился детектом "Will not fix" уязвимостей.

Патчи от Baikal Electronics отказались принимать в ядро Linux из-за санкций

Патчи от Baikal Electronics отказались принимать в ядро Linux из-за санкций

Патчи от Baikal Electronics отказались принимать в ядро Linux из-за санкций. Baikal Electronics проектирует процессоры и системы на кристалле с архитектурой MIPS и ARM. Компания находится под санкциями США, ЕС и ряда других стран.

"Нам некомфортно принимать патчи от вашей организации или относящиеся к hardware произведенному вашей организацией.

Пожалуйста, приостановите networking contributions до дальнейшего уведомления."

В предложенных патчах для сетевого драйвера stmmac была реализована поддержка GMAC и X-GMAC SoC Baikal, предложены общие исправления для упрощения кода драйвера.

Предсказуемо. Опенсурс-опенсурсом, а Linux Foundation это конкретная американская организация. Как и банящий разработчиков GitHub это Microsoft. Понятно каким регуляциям они подчиняются.

Поэтому ядро Linux должно быть своё. Например, от ИСП РАН. И репозитории должны быть свои. И дистрибутивы Linux. Это породит дополнительную фрагментацию и несовместимость, но это выглядит как неизбежные издержки.

В полку Linux уязвимостей позволяющих поднять привилегии до root-а прибыло

В полку Linux уязвимостей позволяющих поднять привилегии до root-а прибыло. Встречаем DirtyCred (CVE-2021-4154 - февральская, есть PoC; CVE-2022-2588 - свежая, пока нет PoC-а). 8 лет уязвимость никто не замечал. Или замечали и использовали, но помалкивали. Естественно NVD как обычно тормозит и там нового идентификатора пока нет, но он во всю используется в бюллетенях безопасности.

Судя по описанию это уязвимость ядра, похожая на мартовскую Dirty Pipe (CVE-2022-0847), только круче, т.к. работает стабильнее:

"The novel exploitation method, according to the researchers, pushes the dirty pipe to the next level, making it more general as well as potent in a manner that could work on any version of the affected kernel."

И контейнеризация не спасает:

"Second, while it is like the dirty pipe that could bypass all the kernel protections, our exploitation method could even demonstrate the ability to escape the container actively that Dirty Pipe is not capable of."

Ну и так-то уязвимости позволяющие получить в Linux root-а появляются достаточно регулярно. Из громких можно ещё вспомнить Dirty Cow (CVE-2016-5195 - обалдеть 😱, 6 лет назад, помню как вчера как тестил) и Qualys-овские PwnKit (CVE-2021-4034) и Sequoia (CVE-2021-33909).

А что делать? Имхо, патчить. Лучше в рамках регулярного процесса, а не в пожарном режиме. Но если регулярного патчинга Linux-ов нет, то лучше разово обновиться, махая этой уязвимостью (или даже более старыми с публичными эксплоитами) как флагом. После разового упражнения будет видно какие есть проблемы с внедрением регулярного процесса, а где-то возможно получится его внедрить с наскока.

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

Но, имхо, оценка эксплуатабельности, харденинг и внедрение СЗИ для Linux-ов это конечно все замечательно, но основное это патчинг и прежде всего нужно разобраться именно с ним.