URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 135461
[ Назад ]

Исходное сообщение
"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код в загружаемое ядро Linux"

Отправлено opennews , 30-Ноя-24 23:13 
Исследователи из компании ESET выявили новый буткит "Bootkitty", устанавливаемый  после взлома системы вместо загрузчика GRUB и применяемый для подстановки в ядро Linux вредоносных компонентов, которые затем позволяют атакующему скрыто контролировать систему и выполнять в ней свои действия. Утверждается, что это первый  UEFI-буткит, нацеленный на поражение систем Linux...

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


Содержание

Сообщения в этом обсуждении
"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 30-Ноя-24 23:13 
Shim и его последствия, которых пришлось подождать.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 30-Ноя-24 23:32 
100%. Вместо внятной документации по описанию работы secure boot и утилит по рулению ключами, например, люди получили черный ящик, который как-то работает. Производители железа вот прямо с этого места (как-то работает) умыли руки. Гора родила shim, чтобы хоть как-то прокыстылять положение дел, но сильно понятней, как устроен SB не стало, и тоже умыли руки.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Семен , 01-Дек-24 01:13 
SB как раз работает очень даже понятно, так же UEFI. Есть всем доступная и понятная документация и спецификация. Все ровно так же как в интернете работает SSL или TLS, есть корневой сертификат - центра доверия - сертификат Microsoft, им подписываются вендор сертификаты, у каждого производителя оборудования они так же могут быть свои и они вшиты в прошивку или в чип с защитой от стирания и перезаписи, таким образом все другие сертификаты подписанные этими сертификатами могут быть легко проверены по открытой подписи корневого сертификата. Но такие закрытые ключи никто не дает, но дают открытый. Таким образом все бинарники подписанные этими сертификатами проходят sb политику безопасности и легко проверяются, подпись и контрольные суммы не возможно подделать. Так же работает любая цифровая подпись https://www.gnupg.org/gph/en/manual/x135.html

Собственно некоторые вендоры позволяют ставить самоподписанные сертификаты, которые хранятся в TPM, но их можно установить только через бинарник подписанный корневым сертификатом. Как я знаю загрузчик просто передает управления shim, который производит дальнейшную проверку SB, потому что собственно сама прошика не знает как проверить подписи у разных типов файлов, и какие там смещения в файлах, а дальше он передает управление grub и ядру подписанными самоподписанными сертификатами или вендор ключами, теперь они становятся центрами доверия и ядро может проверять свои модули, вроде как RedHat все же дали в какой-то момент свой вендор ключ. Отсюда лучше иметь SB чем его не иметь, вы так пишете будь-то при MBR не было буткитов, было и не мало, и установить их было намного проще. Проблема заключается в другом, что в современном компьютере при включении запускается с десяток чипов-устройств, у которых свои прошики, которые напоминают операционную систему и имеют свободный доступ к системным шинам, отсюда там могут быть и бекдоры и уйзвимости, которые можно использовать. И это кстати не байки для параноиков, это реальность(посмотрите видео от инженеров по устройству компьютеров), что почти каждое устройство имеет свою микро операционную систему и свободный доступ к подключенным шинам.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 07:32 
Всё настолько прозрачно и понятно, что до сих пор
https://github.com/rhboot/shim
http://www.rodsbooks.com/refind/secureboot.html
https://github.com/lcp/mokutil

Через тот же mokutil пришлось добавлять непонятный мне ключ, чтобы тот же shim работал. Вопрос в другом, что мешает зловредам подписываться теми же сертом что и shim?

>вы так пишете будь-то при MBR не было буткитов, было и не мало, и установить их было намного проще.

Конечно всё было. Претензия в том, что первый компьютер с материнской платой uefi+sb появился где-то в 2015, но до сих пор нет нормальной инструкции, как сгенерировать свои ключи, подписать ядро/модули, граб, залить в TPM и получить нормально загружающуюся систему.
Всё сводится к тому, что загрузи PreLoader, заэнролль ключи - и не e b мозги себе и другим людям. Дутая сесурность какая-то.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 01-Дек-24 11:06 
> Вопрос в другом, что мешает зловредам подписываться теми же сертом что и shim?

то что у их авторов нет закрытого ключа microsoft, которым подписан shim, неожиданно, правда?

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

> до сих пор нет нормальной инструкции, как сгенерировать свои ключи, подписать ядро/модули, граб,
> залить в TPM и получить нормально загружающуюся систему.

значит тебе и не надо этим заниматься.

За тебя все сделали редхат с убунточкой. Пользуйся на здоровье.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 13:57 
Полагаться на безопасТность от Micro$oft - такая себе безопасность.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 19:03 
> Полагаться на безопасТность от Micro$oft - такая себе безопасность.

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

По моему такая политика лучше всего описывается фразой "двойные стандарты".


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Семен , 03-Дек-24 13:14 
Так это же бред. Чтобы отзывать скомпроментированный сертификат не нужно отзывать корневой, надо просто обновить список отозванных сертификатов. Поэтому не вижу логику в том, что винда не будет грузится и отозвать вендор сертификат, который никак не связан с Microsoft, у венды загрузчик подписан другим сертификатом. На моей материнке к примеру есть список отозванных сертификатов, и там даже есть какие-то реальные сертификаты.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 04-Дек-24 18:06 
> Так это же бред. Чтобы отзывать скомпроментированный сертификат не нужно отзывать корневой,
> надо просто обновить список отозванных сертификатов. Поэтому не вижу логику в

проблема что им понаподписывали... (чего - MS так толком и не призналась)
Т.е. да, отозвать можно, винда-то (оооочень предусмотрительно - мож знали чо? ;) подписана другим. Но (помимо неудачников с линуксами не единственноверной последней переподписанной версии, что тоже в общем-то не айс, согласись - обновил ты прошивки вперед обновления шима и привет - твой rhel8 не rhel, нет загрузки, нет увизгвимостей, и как чинить непонятно) им еще чего-то понаподписывали, что не хотят сломать.

В общем-то и шима бы за глаза хватило. Представляешь сколько визгу бы было - "проклятая M$$$$ сломала нам всем загрузку!"


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 05-Дек-24 07:33 
> В общем-то и шима бы за глаза хватило.

shim - зло, делающие невозможным реализацию цепочки Integrity.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 00:03 
> Конечно всё было. Претензия в том, что первый компьютер с материнской платой
> uefi+sb появился где-то в 2015, но до сих пор нет нормальной
> инструкции, как сгенерировать свои ключи, подписать ядро/модули, граб, залить в TPM
> и получить нормально загружающуюся систему.

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

> Всё сводится к тому, что загрузи PreLoader, заэнролль ключи - и не
> e b мозги себе и другим людям. Дутая сесурность какая-то.

Бгг, уважаемый, какая сикурность может быть в недобиосах, в которых вкорячивают форму для отправки мыла разработчикам этой блоатвари, прямо с модными GUI?! xD


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 07:56 
Все разъяснил:

https://www.opennet.dev/openforum/vsluhforumID3/134399.html#80

https://www.linux.org.ru/forum/security/17682542?cid=17683360

Продублирую!


Ещё раз напомню 3 базовых аксиомы Integrity:

1. Все перед запуском должно верифицироваться по цифровой подписи с использованием публичного ключа.

2. Использование чужих публичных ключей для верификации системы неприемлемо.

3. Наличие секретных ключей в рабочей системе недопустимо.


Теорема о ключах Integrity.

Систему Integrity возможно реализовать на компьютере конечного пользователя или в конечном административном домене только в случае создания всех ключей используемых для Integrity на компьютере конечного пользователя или в конечном административном домене.

То есть полная верификация системы в процессе загрузки возможна только в случае когда все ключи: Intel Boot Guard, Secure Boot, GRUB, Linux IMA/EVM - создаёт конечный пользователь (администратор) системы.


Доказательство:

1. Ключи IMA/EVM. Пользователь (админ) установил GNU/Linux на свою машину. После установки ВСЕГДА необходимо настроить систему GNU/Linux иэизменив файлы настроек в /etc/. После из мнения файлов в /etc/ их необходимо заново переподписать, а значит конечному пользователю необходимо иметь приватные ключи IMA/EVM для создания новой подписи. Следовательно ключи IMA/EVM должны создаваться на компе конечного пользователя.

2. Ключи GRUB. Свои созданные ключи IMA/EVM пользователь вынужден добавить в ядро Linux и/или initrd в зависимости от конкретной реализации IMA/EVM в конечной системе. А значит ядро Linux и initrd будут ВСЕГДА изменены конечным пользователем в процессе установки. Также в процессе установки системы будет изменён конечным пользователем файл /boot/grub/grub.cfg. Изменённые ядра, initrd, файл настроек загрузчика необходимо подписать приватным ключом GRUB в процессе установки, а значит конечному пользователю необходимо иметь приватные ключи GRUB для создания новых подписей. Следовательно ключи GRUB должны создаваться на компе конечного пользователя.

3. Ключи Secure Boot. Свои созданные ключи GRUB пользователь вынужден добавить в начальный загрузчик GRUB - core.img. А значит core.img будет ВСЕГДА изменён конечным пользователем системы в процессе установки. Измененный core.img необходимо подписать приватным ключом Secure Boot в процессе установки, а значит конечному пользователю необходимо иметь приватные ключи Secure Boot для создания новой подписи. Следовательно ключи Secure Boot должны создаваться на компе конечного пользователя.

4. Ключ Intel Boot Guard. Свои созданные ключи Secure Boot пользователь вынужден добавить в UEFI. А значит общее содержание UEFI ВСЕГДА будет изменено конечным пользователем во время установки системы. Измененные части UEFI необходимо подписать приватным ключом Intel Boot Guard в процессе установки, а значит конечному пользователю необходимо иметь приватный ключ Intel Boot Guard для создания новых подписей. Следовательно ключ Intel Boot Guard должен создаваться на компе конечного пользователя.


ДОКУМЕНТАЦИЯ ПО НАСТРОЙКЕ INTEGRITI.

Linux IMA/EVM.

https://sourceforge.net/p/linux-ima/wiki/Home/

https://ima-doc.readthedocs.io/en/latest/index.html

https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture

https://wiki.gentoo.org/wiki/Extended_Verification_Module

Лично мне пришлось чуть править файл: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... По умолчанию реализована классическая политика TCB. Она для GNU/Linux не подходит. Много изменяемых файлов в TMP, LOG, … пишутся под пользователем root. Это надо разрешить правилами. А все что мапится в память для исполнения - проверять. В системах с initrd надо позаботится о XATTR атрибутах с подписями или подкорректировать для его запуска правила.

GRUB2.

https://www.gnu.org/software/grub/manual/grub/grub.html#Usin...

UEFI Secure Boot

Матплата должна поддерживать удаление всех чужих ключей Secure Boot и добавление своего публичного ключа Secure Boot. А ещё лучше поддерживать libreboot, coreboot.

https://habr.com/en/post/273497

https://www.linux.org.ru/forum/admin/15742224?cid=15742698

Intel Boot Guard

Если матплату и проц покупать раздельно, то пользователь будет иметь возможность единожды прописать ключ Intel Boot Guard в спец область ROM где-то в IntelME. Отключить Intel Boot Guard или изменить его ключ физически будет невозможным. Это безоткатная операция. По этому терять ключ Intel Boot Guard нельзя. Информации о том как закрытый, проприетарный IntelME проверяет целостность UEFI и ключей Secure Boot почти нет.

https://github.com/corna/me_cleaner/wiki/Intel-Boot-Guard

Никаких технических проблем для поддержки по умолчанию Integrity в Linux IMA/EVM и GRUB2 - во всех дистрибутивах GNU/Linux не существует! Надо просто чуть подправить инсталлер каждого дистрибутива.

Поддержка Secure Boot и Boot Guard зависит от производителя железа. Возможна опциональная поддержка для конкретного железа.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 07:33 
>И это кстати не байки для параноиков, это реальность(посмотрите видео от инженеров по устройству компьютеров), что почти каждое устройство имеет свою микро операционную систему и свободный доступ к подключенным шинам.

Intel ME - внутри работает MINIX3.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 14:04 
У-у-у, как страшно! Выключи компьютер из розетки, и не подходи к нему больше!

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Neon , 02-Дек-24 00:28 
Ну, а палестинцев пейджеры взрывались. Никогда не стоит брать пейджеры и мобилы в руки

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Финнишпруф , 02-Дек-24 10:59 
Твоя клавиатура. 3.. 2.. 1..

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Семен , 03-Дек-24 17:33 
Не только пейджеры. А уже есть инциденты в РФ, вроде этим летом началось что Keysight и Rohde & Schwarz массово заблокировали осциллографы, векторные анализаторы и другое измерительное оборудование. При этом вместе с оборудованием в РФ еще случайным образом было заблокировано оборудование в совершенно разных странах. И для разблокировки просят копии документов от их официального поставщика в их стране. Притом разблокировать они не торопятся, и там бюрократия, у людей прошли месяцы с момента подачи документов и разблокировки, и встала работа. На западе вообще паранойя, в первые дни СВО они начали блокировать инженерное ПО якобы по причине, что оно может использоваться для производства оружия. У меня так лицензию на честно купленный матлаб заблокировали.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 04-Дек-24 09:16 
В 2012 году, до 2014 и до 2022 годов, удаленно, были заблокированы газовые турбины на магистральных газопроводах Газпрома. Турбины были произведены в Австралии.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 04-Дек-24 18:10 
> Не только пейджеры. А уже есть инциденты в РФ, вроде этим летом

наверное, случилось что-то?


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 04-Дек-24 19:14 
>> Не только пейджеры. А уже есть инциденты в РФ, вроде этим летом
> наверное, случилось что-то?

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


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 05-Дек-24 07:44 
>> Keysight и Rohde & Schwarz массово заблокировали осциллографы, векторные анализаторы и другое измерительное оборудование
>>  У меня так лицензию на честно купленный матлаб заблокировали.
> наверное, случилось что-то?

Интересно как происходит отключение. В выше перечисленных случаях наверно через бекдор активируемый через Интернет, или через штатные средства обновления прошивок. Надо вести черный список производителей и прошивок их устройств.

В случае отключения газоперекачивающих турбин Газпрома в 2012 году у этих турбин подключения к Интернету не было, их выключали через спутник.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Семен , 05-Дек-24 17:14 
Не редко все приборы объединены в локальную сеть, и рулятся через софт - больше экран, удобнее, можно математическим анализом сигналов заниматься, программировать и т.д. Есть для этого стандарт LXI - LAN eXtensions for Instrumentation. Собственно у кого в локалке не был порезан интернет те попали, прибор запросил обновление прошивки и сразу прилетела блокировка устройства. Сейчас даже вручную без регистрации и проверки доков не скачать обновления. На eevblog про это писали, там официальные представители просто проигнорили людей с разных стран, чьи устройства по ошибке блокнули, никакой помощи с разблокировкой не было, там даже их потролили официальные представители Siglent и Rigol, что покупайте лучше наши устройства и мы не подчиняемся экспортному контролю США, не блокируем устройства и не запрещаем анонимное скачивание прошивок. Все эти Keysight и Rohde & Schwarz живут в основном за счет госконтрактов, и кучу денег все пилят в карманы в себе, поэтому вынуждены прогибаться под законы, иначе миллиардные штрафы, потеря контрактов. Они только на поставках в учебные заведения и т.д. больше зарабатывают, чем от продаж приборов в мире, отсюда за простую программную опцию могут закатить конский ценник и им плевать на конкурентов, а потом могут сторговаться и якобы предоставив дисконт на госконтракт. Приборы эти конечно одни из лучших в мире, но бюрократии и коррупции там овер дофига.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено keydon , 01-Дек-24 17:47 
> есть корневой сертификат - центра доверия - сертификат Microsoft

Что может пойти не так?

> Собственно некоторые вендоры позволяют ставить самоподписанные сертификаты

А некоторые не позволяют. Чувствуешь отличие от браузеров? И если с браузерами это была бы проблема "не могу зайти на сайт", то с UEFI "не могу поставить систему".

> которые хранятся в TPM

Чёрный проприетарный ящик который уже как миниум в 2ух редакциях оказался полным корытом. Что может пойти не так?

> Отсюда лучше иметь SB чем его не иметь

Иногда табличка "осторожно возможен камнепад" помогает лучше чем наличие жёлтой касочки


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Семен , 01-Дек-24 19:59 
> Что может пойти не так?

Ничего, если все работает. Отозвать сертификат можно только обновлением прошивки.
> Чувствуешь отличие от браузеров?

Да. Браузер может тебе поставить свои левые корневые сертификаты в системе, и организовать подмену сайтов, и украсть чувствительные данные. Так же дистрибутивы все поставляют свой список доверенных корневых сертификатов.
> Чёрный проприетарный ящик

Собственно нет, есть спецификация, вы можете реализовать tpm программно или использовать готовую микросхему, на большом количестве материнских плат можно вставить свой tpm модуль, и распиновка известная, берешь микроконтроллер или fpga и пилишь, если паранойя зудит в одном месте. Признайтесь честно, не читали? Плюс те же чипы проверяются на разные виды атак и сертифицировать их тоже не просто. Могут быть бэкдоры для товарища майора, никто не отрицает, но это в теории, на практике были единичные случаи взлома чипов от серьезных контор, и атаки эти обычно сложно реализуемы, в остальном это хорошее средство криптографической защиты. От терморектального криптоанализа от товарища майора ничего не спасет и даже бэкдор не нужен...

> Иногда табличка "осторожно возможен камнепад" помогает лучше чем наличие жёлтой касочки

Да, но некоторые опеннетчики судя по комментам предпочитают все же защиту в виде шапочки из фольги.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено keydon , 02-Дек-24 05:10 
> Ничего, если все работает. Отозвать сертификат можно только обновлением прошивки.

Зато подписать может и сам майкрософт и скорее всего любое правительство под чей юрисдикцией он находится (а находится он во многих странах, естно отказаться нельзя).

> Да. Браузер может тебе поставить свои левые корневые сертификаты в системе, и
> организовать подмену сайтов, и украсть чувствительные данные. Так же дистрибутивы все
> поставляют свой список доверенных корневых сертификатов.

Но не каждая мать (прошивка матери) позволяет добавить твои сертификаты. Зато каждый из популярных браузеров позволяет.

> Собственно нет, есть спецификация, вы можете реализовать tpm программно или использовать
> готовую микросхему, на большом количестве материнских плат можно вставить свой tpm
> модуль, и распиновка известная, берешь микроконтроллер или fpga и пилишь, если
> паранойя зудит в одном месте. Признайтесь честно, не читали?

Смысла в этом вижу мало (как и в целом в очередном слое аппаратной защиты), но ок - не черный, но все еще проприетарный ящик.

> Плюс те
> же чипы проверяются на разные виды атак и сертифицировать их тоже
> не просто.

Про предыдущие версии говорилось то же самое.

> Могут быть бэкдоры для товарища майора, никто не отрицает,
> но это в теории, на практике были единичные случаи взлома чипов
> от серьезных контор, и атаки эти обычно сложно реализуемы, в остальном
> это хорошее средство криптографической защиты. От терморектального криптоанализа от товарища
> майора ничего не спасет и даже бэкдор не нужен...

В контексте майкрософта и кучи контор с театром безопасности несомненно штука нужная. В контексте опен сурса вредная.

> Да, но некоторые опеннетчики судя по комментам предпочитают все же защиту в
> виде шапочки из фольги.

В контексте камнепада не отличается от касочки.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 23:58 
> SB как раз работает очень даже понятно, так же UEFI. Есть всем
> доступная и понятная документация и спецификация.

На которую примерно лишь все кладут болт и каждый суслик аграном делает по-своему, отчего реальные реализации UEFI настолько кривы и костыльны, как бох на душу положит, что разработчики Debian об этом прямо официально в каждом установщике предупреждают, что это сраный и убогий е#%ный стыд и так быть не должно, мы сделали с нашей системой непотребства, чтобы оно всё равно работало, но имейте в виду, что вы пользуетесь зашкварными прошивками, который шкварит Debian и само понятие логично построенных систем.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 30-Ноя-24 23:14 
И таких подстав ещё цать. Открытый исходный код... Присылайте ваши пулл-реквесты!

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 30-Ноя-24 23:24 
https://www.microsoft.com/ru-ru/security/

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Bottle , 01-Дек-24 01:55 
Вообще, проблема безопасности системная, начиная с железа.
Пока не решат проблему на аппаратном уровне, править программные ошибки смысла мало.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 17:18 
На том же железе, но с Legacy BIOS, таких проблем почему-то не было.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 14:54 
Т.к. хомяк в то время ещё не выбрал Вебню. Теперь выходит, вебню надо отсаживать в абсолютную изоляцию. Одновременно вебня хочет верификацию, чтобы быть уверенной в контроле.

Типовая корпоративно-бизнесовая возня.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 02-Дек-24 16:02 
ловите попаданца!

В _нашем_ мире буткитов для "legacy bios" "почему-то" было и есть мильен с тыщами, их уже даже по названиям никто не запоминает.

А вот для uefi, обратите внимание - пока нашли целый аж один.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Oe , 30-Ноя-24 23:35 
Переполнение в декодере bmp ахахахаха, там код "декодера" две с половиной строки, даж на ламповом компьютере запустится.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Семен , 01-Дек-24 01:18 
Кстати да, формат нереально простой, как они так могли обосраться. Может специально был бекдор? Мне что-то верится с трудом, что в коде в пару сотен строк, в которым пару десятков строк нужны для декодирования можно так ошибиться и не заметить переполнение.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 02:47 
> как они так могли обосраться

Ты не поверишь, взяв опенсорсную либу. Думали там тысячи глаз, но не знали, что все шоколадные. А других бесплатных кодеров у нас для вас нет.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 07:03 
Ты не поверишь, но у MS тоже был баг в декодере BMP в IE. И никакого опенсорса, кстати.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 10:05 
> Может специально был бекдор?

Торвальдса в содружестве с Microsoft проверьте.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 04:32 
В BMP как минимум есть RLE, а с ним уже обосраться можно запросто с переполнением.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Oe , 30-Ноя-24 23:41 
А чо в конце 2024 адреса функций всё еще не рандомизируются при каждой компиляции и двадцать лет лежат по статичным адресам?
'затем скрывает себя в списке модулей ядра'
А чо модуль ядра может сам себя скрыть? У вас все равно 99% тормозов в  юзерспейсе, неужели нельзя модули в контейнерах запускать? Ах, обратная совместимость, нельзя ломать.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Aliech , 01-Дек-24 00:00 
Дорогой Анон, а просвети как, как это модуль ядра запустить в контейнере? Каком контейнере?

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 00:07 
Создаёшь докер в докере. Пишешь код модуля, для наглядности используй javascript, да и нода тоже пригодится, инструмент ведь универсальный. А потом запускаешь. Понял?

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 00:48 
Это такое издевательство?

Запускать части ядра в контейнерах?

Кого вы хотите им проклясть?


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 03:05 
Какой бред.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 03:57 
Ты тоже помогай, без тебя не справятся.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено gleb , 01-Дек-24 09:46 
> Создаёшь докер в докере.

то есть, приглашаешь потенциального взломщика похакать ещё и хостовую систему?

ну, ок.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 16:58 
Из докера есть возможность вылезти. Есть даже статьи об этом в интернете

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено sysrise , 01-Дек-24 00:57 
Видимо 20 футовом ;)

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Oe , 01-Дек-24 01:33 
Берешь и запускаешь. Не запускается, значит переписываешь ядро и модуль пока не начнет запускаться.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 01:44 
>А чо модуль ядра может сам себя скрыть?

А то как же! Ядерный код же!
>У вас все равно 99% тормозов в  юзерспейсе, неужели нельзя модули в контейнерах запускать?

Молодёжь переизобретает микроядро же!
>Ах, обратная совместимость, нельзя ломать.

Это последсвия потери идей миникса же! Таненбаум предупреждал же!


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено мяв , 01-Дек-24 01:54 
и да, все равно массовое заражение будет для атакующего болью - в федоре, вон, уже на uki перешли и MOK выкинули
зы. про выкидывание не уверена, но если не выкинули - странно.. тогда переход смысла лишается.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено cat666 , 01-Дек-24 10:54 
Ну и как это осложнит заражение системы, если все средства для формирования uki и его подписи есть на целевой системе? Всё тоже самое только другим модным словом называется.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 01-Дек-24 11:08 
внезапно, uki тоже надо чем-то подписать. microsoft за вас это делать не собирается.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено мяв , 01-Дек-24 01:59 
>Библиотека injector.so перехватывает некоторые операции SELinux и функцию init_module

каким образом буткит собрался что-то в /boot вытанцовывать с включенным selinux перед перезагрузкой - тоже не совсем ясно.
редхатовская политика левым процессам не дает в boot_t писать.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Семен , 01-Дек-24 03:18 
Все гениальное просто: setenforce 0
Во всех redhat подобных дистрибутивах можно отключить selinux, запрет на изменения прописываются в конфиге ядра при сборке, думаю они не отключают эту функцию, на случай траблшутинга и запуска релайбла у малограмотных юзеров. 99% пользователей не знают, как им пользоваться и как разрабатывать свои политики, если их софт чудесным образом не запускается. Вы не поверите, но в очень большом количество туторов для редхат, центоса, и федоры первым делом отключают selinux. Классический пример, на котором 99% пользователей затыкаются, что при создании директории вебсервера и запуска вебсервера, вебсервер ваш шлет на 3 буквы из-за selinux и люди не могут прописать нужные контексты.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 01-Дек-24 11:17 
autorelabel все равно ж при перезагрузке делается. Совершенно непонятно, зачем ради возможности его запустить вручную у полуграмотных пользователей делать отключаемым enforce mode. Но оно таки да с самого начала.

(обратите вон внимание на *bsd - securelevel двигается только в одну сторону, вверх. Из 1 сделать ноль без перезагрузки нельзя никак. И если загрузчик тоже настроен ставить его в 1 - без перехвата управления снова никак.)

> Классический пример, на котором 99% пользователей затыкаются, что при создании директории
> вебсервера и запуска вебсервера, вебсервер ваш шлет на 3 буквы из-за selinux и люди не могут
> прописать нужные контексты.

потому что хрен знает, какие там нужны. Увы. Разумеется если у тебя не локалхост с единственной статической страничкой (да, был http_transition но кажется в новых модных уже сплыл)

  


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено мяв , 01-Дек-24 13:53 
>потому что хрен знает, какие там нужны.

ps -eZ | grep myService

>обратите вон внимание на *bsd - securelevel двигается только в одну сторону, вверх.

tomoyo и емнип, AA, тоже могут изменения политики в рантайме запрещать.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 01-Дек-24 16:30 
ну я же сразу обозначил что речь не о твоем локалхосте.

Не так просто там все правильно настроить. Если софт не свой и не хеловрот - то можно считать нереальным. Поэтому если есть transition mode и соответствующий переключатель - лучше им воспользоваться. targeted selinux никогда не задумывался для защиты твоих приложений, это универсальное решение, прикрывающее _штатные_ системные. Причем вот ровно те до которых дошли руки - на то и targeted. В частности про которые заранее хорошо известно, куда они лезут и что им там надо.

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


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено мяв , 02-Дек-24 00:24 
>то можно считать нереальным.

не нужно проецировать .. это несколько команд.
>куда они лезут и что им там надо.

в случае с 99% приложений, Вы это предугадать не сможете.
условно, пользователь конфиг к себе в хомяк засунет. или какой-то drop-in.
> прикрывающее _штатные_ системные

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

>Впрочем, старожилы еще помнят десять лет неработавший tftp

старожилы за 10 лет случайно auditd  илм хотя бы audit2allow не осилили?


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 03-Дек-24 12:22 
> не нужно проецировать .. это несколько команд.

повторяю, твой опыт локалхоста нужен примерно никому. Он у тебя торчит примерно из каждой строчки.
По "myService" уже было все понятно.

>>куда они лезут и что им там надо.
> в случае с 99% приложений, Вы это предугадать не сможете.

опыт локалхоста

> старожилы за 10 лет случайно auditd  илм хотя бы audit2allow не осилили?

опыт локалхоста


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено мяв , 04-Дек-24 01:54 
>повторяю

Вы, кроме матры про локалхост, не сказали ничего.
>По "myService" уже было все понятно.

специально для Вас ..

>вебсервера и запуска вебсервера, вебсервер ваш шлет на 3 буквы из-за selinux и люди не могут прописать нужные контексты.
>>потому что хрен знает, какие там нужны
>>>чтобы посмотреть, какие контексты "нужные" - ps -eZ | grep "webServerName", после чего ставите тот, под которым работает сервис.
>опыт локалхоста!!

Вам на "не-локалхостах" ps собрали без libselinux? или Вы не догадались, что myService = processName?
Вы пока что показываете только отсутствие матчасти, не говоря уже об опыте.


>>>куда они лезут и что им там надо.
>>в случае с 99% приложений, Вы это предугадать не сможете.
>опыт локалхоста

отсутствие попытки подумать перед ответом?


>опыт локалхоста

~~отсутствие попытки подумать перед ответом х2?~~
штатный инструмент, опысываемый в документации rh, selinux и за который спрашиыают на rhcsa.
и первая комманда оттуда же :)


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 04-Дек-24 12:17 
> Вам на "не-локалхостах" ps собрали без libselinux?

тебе на нелокалхосте когда-нибудь придет понимание что там нет никакого отдельно взятого и понятног тебе "myService". А что есть - подрастешь, узнаешь.

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

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

На локалхосте (да и то с хеловротом) - тебе этих познаний кое-как хватит. Ну может и на rhcsa сдашь, это уровень именно среднего десятиклассника, кое-как осилившего прочитать пересказ манов.

По дороге к rhce тебя ждет много, много интересных открытий.  Но особенно - после, когда ты попытаешься эту науку применить к работе.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено мяв , 04-Дек-24 12:32 
ответ на комментарий выше.
нах, man auditd.
это Ваше подобие тех. аргумента рубит на корню.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 04-Дек-24 18:58 
> нах, man auditd.

ну почему, почему местные недоучки прочитавшией аж целый man auditd думают что хоть что-то умеют и лезут с ценным мнением которого никто не спрашивал?

У тебя тоже опыта кроме локалхоста ноль, я правильно угадал.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 19:06 
> (обратите вон внимание на *bsd - securelevel двигается только в одну сторону,
> вверх. Из 1 сделать ноль без перезагрузки нельзя никак. И если
> загрузчик тоже настроен ставить его в 1 - без перехвата управления
> снова никак.)

Lockdown так же работает. Как и например загрузки модулей. Правда, даже так - более 9000 способов как попробовать нечто этакое все же останется.

Прикинь - у твоих замшелых жителей башни слоновой кости нет монополии на эту идею.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 02-Дек-24 19:38 
вот и имеете мильен способов, все в теории, "как попробовать нечто". На деле ничего не работает и сразу все ломается.

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


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 04-Дек-24 00:06 
> вот и имеете мильен способов, все в теории, "как попробовать нечто". На
> деле ничего не работает и сразу все ломается.


[    0.850860] Kernel is locked down from Kernel configuration; see man kernel_lockdown.7

Да вроде работает себе. При том одно дело если тебе это другие вкатили, и другое если это я сам от атакующих. А теория без практики - ну вот не, такие сказки вон тем теоретикам с FFS и BSD скармливай.

И загрузка модулей зарубается в два счета. Местами и зарублено.

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

С другой стороны чем попсовее решение - тем его быстрее снесет атакующий. Тем более что кто фрю всерьез на прочность пробовал? Соня какая-то? Так они поди в приватном порядке и зафиксили все что крякеры DRMа нашли, а вот что они заапстримят сие - совсем не факт.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 02:43 
Сделали бы защищённое хранилище для загрузчиков и доступ к нему по одноразовому коду, показывать код на отдельном экране - вспотеешь загрузчик подменять вредоносами. А сейчас какой-то недосекурибут который кроме тивоизации ничего не даёт.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 03:14 
Уже же есть такое - вынос загрузчика на флеш.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 03:29 
> вынос загрузчика на флеш

непрактично как все прочие внешние накопители


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 16:55 
Как это вас защитит от буткита? Вынуть флешку из компьютера? Оригинально, только от всех буткитов не защитит.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 22:59 
Впрочем, я тут подумал - идея с флешкой, если для 3.5 дюйма слота в целом неплохая идея - нажимаешь кнопочку, флешка вставлена, нажимаешь ещё раз - вынута. И тем не менее - не очень удобно, да и подмену бута можно заметить не сразу. Привыкнешь - можно не заметить подмену что оно бутается без флешки, кнопку по привычке можно включать или не выключать.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 03:54 
> Впрочем, я тут подумал - идея с флешкой, если для 3.5 дюйма
> слота в целом неплохая идея - нажимаешь кнопочку, флешка вставлена, нажимаешь
> ещё раз - вынута. И тем не менее - не очень
> удобно, да и подмену бута можно заметить не сразу. Привыкнешь -
> можно не заметить подмену что оно бутается без флешки, кнопку по
> привычке можно включать или не выключать.

Есть флешки с переключателем ReadOnly, как и полноразмерные SD карты, между прочим. К тому же на SD можно выставить перманентный readonly пульнув в нее соотв команды.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 03-Дек-24 02:11 
> К тому же на SD можно выставить перманентный readonly пульнув в нее соотв команды.

Да там переключатель есть сбоку. А кому это нужно? Где-то на заводах?


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 04-Дек-24 00:12 
> Да там переключатель есть сбоку. А кому это нужно? Где-то на заводах?

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

А вот командой - оно таки насовсем делается RO и потом ЭТО по простому никак не откатывается, одноразовая операция. Ничем не хуже eFUSE - с той разницей что если приперло то при физическом доступе все же можно такую media и заменить. А в eFUSE - ну, вы будете менять весь проц или одноплатник. Немного более крупный и дорогой юнит на замену.

NB у перманентного readonly нет undo, в этом случае если вам не нравится то что записано на SD, repalace SD card and press any key. Зато и атакующий не сможет левак записать, а бут на этой штуке может - проверять скажем подпись ядра/рамдиска, и если публичный ключ там в конфиг бутлоадера впихан - и это readonly - ну, упс, атакующему в этом месте будет весьма неудобно.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 09:57 
>кроме тивоизации

так в этом и была задача изготовления инновации. Остальное — мусор для тиктокеров и квадробберов, возомнивших себя хозяевами своих устройств.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 01-Дек-24 11:11 
ты не хочешь оплачивать отдельный экран. Может еще и отдельную клавиатуру для ввода кодов тебе? Посмотри цены на карточные терминалы и расстройся.

А потом окажется что код писали лудшие специалисты из под Бангалора, и при нажатии какой-нибудь кнопки надолго - контроль ввода кодов отключается из-за переполнения кольцевого буфера (привет, grub)


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 13:14 
> Посмотри цены на карточные терминалы и расстройся.

ахаха - 100 руб в розницу, отдельная клавиатура нафик не нужна

https://aliexpress.ru/item/1005005335436970.html

кроме паролей можно и другую инфу выводить - заряд акума, температуру и тд


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 14:48 
> ахаха - 100 руб в розницу, отдельная клавиатура нафик не нужна
> https://aliexpress.ru/item/1005005335436970.html

И? Дальше-то что? Взаимодействие с этой дорогущей (тут производители железок все еще берут 8и и 16 битную мк-рухлядь вместо STM32, икслючительно потому что стоит 4, а не 24 цента) фиговиной кто обеспечивать будет?
А совету директоров объяснять, зачем недополученую прибыль на крень спустили?


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 01-Дек-24 16:21 
> Взаимодействие с этой дорогущей (тут производители железок все еще берут 8и и 16 битную
> мк-рухлядь вместо STM32, икслючительно потому что стоит 4, а не 24 цента) фиговиной кто
> обеспечивать будет?

драйвер уэфи написать для нее (ну правда заодно i2c - вряд ли в уэфи есть штатный) можно - вопрос чем он поможет и от чего.

Я, как обычно, недооценил интеллектуальный уровень местной публики, он сугубо отрицательный.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 23:21 
> Я, как обычно, недооценил интеллектуальный уровень местной публики, он сугубо отрицательный.

Так круто же. Integer underflow -> эвона какой IQ ломовой. Вот это я понимаю - задним умом крепок!


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 17:01 
> тут производители железок все еще берут 8и и 16 битную мк-рухлядь

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


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 18:08 
>> Сделали бы защищённое хранилище для загрузчиков и доступ к нему по одноразовому коду, показывать код на отдельном экране
> где тут и каких железок,

На счетах, очевидно же ...

> вы наркоты объелись тут все чтоли

Просто ты, походу, тот еще "стратег", умеющий лишь в раздачу невнятных указаний в комментах "как надо бы правильно, я точно знаю!".
Куда ты свой "отдельный экран" пихать-то собрался, а? (Гусары молчать!)



"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 14:07 
Одноразовый код по SMS :)

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 01-Дек-24 16:20 
так это - просто экран. Ни от чего не защитит и ничему не поможет.
Чем отличается вывод в него от вывода на основной рабочий и нахрен лазить куда-то под стол к корпусу чтобы посмотреть температуру - у местных кулибиных недоучек можно не спрашивать.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 16:59 
> Чем отличается вывод в него от вывода на основной рабочий

на сервере основного вообще нет

> и нахрен лазить куда-то под стол

у меня ноутбук на столе


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 17:09 
> так это - просто экран. Ни от чего не защитит и ничему не поможет

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


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 16:52 
Хакеры найдут ту же возможность это использовать. Вы ещё смс по телефону предложите. Вы понимаете же что это не программная проблема вообще, то о чем вы говорите, а архитектурная, причем архитектура процессора должна это поддерживать? Т.е. ну допустим даже пароль вы будете вводить, который установите в биосе (если оно ещё биос не перепишет) или даже кнопочку будете нажимать при установке ОС и доступе к защищённой (и ограниченной, а также зарезервированной соответственно) области памяти. Конечно это усложнит задачу хакерам, тем не менее возникает множество вопросов касательно других вещей. Ну вот вы загрузчик перепишете, а сама ОС в незащищённой памяти? Ну хакеры будут там буткит делать. Вместо ОС загрузите буткит, если он не имеет возможности проверить подлинность системы. Ну или кто-то скачает буткит и потом "техподдержка" попросит пользователя нажать нужные кнопочки с паролем. И все это ваше дорогое решение с защищённой областью памяти станет не актуальным.
Не проще ли попросить товарища майора сделать доверенный источник ПО? Ах, ну да - вы его не любите. Ну а они вообще и нужны для обеспечения безопасности. А неизвестный Вася из-за бугра вам никакой законной гарантии не даст - они никак не отвечают за это.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Геймер , 01-Дек-24 10:49 
На моём подкроватном сервачке на Orange Pi LTS нет никакого Secure Boot и EFI. Bootkitty мимо кассы. Сплю на своей кровати спокойно.

Das ist U-Boot с декларативным DTS - простой юниксвейный загрузчик. EFI secure boot - пример решения безопасТности за счёт хитроумно выделанной  гайки, на которую всё равно найдётся такой же хитроумно выделанный Bootkitty. То, что Secure Boot - корпоративная шняга в интересах одной корпорации, было ясно ещё с началом свистоплясок с подписыванием и переподписованием ключами Microsoft.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 01-Дек-24 11:12 
конечно спишь спокойно - играешься-то ты на венде. А это у тебя - для примерно ничего.

Что помешает в "простом юниксвейном загрузчике" подменить строчку с путем к vmlinux - науке неизвестно.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Геймер , 01-Дек-24 11:23 
Плаустатион для игорей альтернатива виндовс. Во многом даже плаустатион тоже юниксвей - делает только игры, но делает это хорошо.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено name , 01-Дек-24 11:14 
Не говорите ему про TrustZone.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено нах. , 01-Дек-24 11:18 
это аналог tpm, а не secure boot.

Без uefi не работает, а тем на orange и не пахнет.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 23:29 
> это аналог tpm, а не secure boot.

Ни того ни другого на самом деле.

> Без uefi не работает, а тем на orange и не пахнет.

Вообще-то без ARM Trusted Firmware залитого в него. Как ни странно - для оранжей на allwinner и rockchip оно не только есть в сорцах, u-boot'ом не только можно его загрузить, но - и - черт побери, фирма ARM взяла реализации ATF для этой парочки в официальную репу.

Ну что, TianoCore и прочее uefi, вот как надо то было на самом деле... и вот так это МОЙ "secure monitor" который вполне можно пропатчить при желании.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Геймер , 01-Дек-24 17:53 
Таки да. Windows 11 похожа на Windows 3.11, которая крутилась поверх системной DOS, предоставляя прикладной оконный интерфейс. Windows 11 крутится поверх системной Trust OS, предоставляя прикладной оконный интерфейс. Можно сказать, вощвращение к своим истокам.

А мы на Риск 5 перейдём.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено мяв , 01-Дек-24 13:35 
"хитроумно выделенный Botkitty" нашелся на платформы с ключами от MS.
у всех, кто на серьезе SB использует, они свои.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 13:38 
> на Orange Pi LTS нет никакого Secure Boot

есть, просто отключен по умолчнию а инфу как пользоваться производитель не дает бесплатно

> Das ist U-Boot с декларативным DTS - простой юниксвейный загрузчик.

и в чём сложность подменить его вредоносом ?


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 03:43 
>> Das ist U-Boot с декларативным DTS - простой юниксвейный загрузчик.
> и в чём сложность подменить его вредоносом ?

При желании это зарубить можно его в readonly флеху или карту памяти загнать. Но правда тогда его и апдейтить будет - упс. Да, SD карты можно делать наглухо readonly если у вас MMC HCI через который команды пулять можно. А у SPI флех есть хардварный пин WP#.

И вот так можно сделать...
1) Вот именно открытое фирмваре.
2) С вот именно СВОИМ root of trust. Т.е. если бут проверяет подпись ядра или чего там - окей но на ридонли флехе/карте его же не перезапишут. Так что можно, вот, подпись проверить. Именно своего ключа как "главного".

И это все - без всяких заскоков интела и амд, когда самый крутой и привилегированый ключ (ME/PSP) они внаглую вшили сразу с фабы - зарезервировав права реального хозяина лично себе. А остальным - фуфло декоративное.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 08-Дек-24 10:44 
> На моём подкроватном сервачке на Orange Pi LTS нет никакого Secure Boot и EFI.

https://docs.u-boot.org/en/latest/develop/uefi/uefi.html
> (UEFI) [1] has become the default for booting on AArch64 and x86 systems.

Ну как бы он есть, но у тебя конкретно может и отключён. Тут хз уже... По дефолту, кстати, включён на AllWinner (если в menuconfig для u-boot сильно не ковыряться).


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено devl547 , 01-Дек-24 11:21 
Ну всё, ждём зашития вендорлокнутых ядер прямо в материнку производителем, чтоб никто не смог ничего стороннего установить.
Всё ради вашей безопасности и фоток с котиками!

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Мечтаю о маке но я нищий и безработный , 01-Дек-24 17:12 
Материнки производятся исключительно под одну конкретную.ос, имя которой всем известно. Ровно как и их драйверы и таблицы acpi. Ну а то что оно работает хоть как-то под этими вашими ядрами, то это заслуга тех, кто написал гору костылей, чтобы оно заработало.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 01-Дек-24 11:44 
Как и ожидалось, создавать ос, которая будет запускать тебе ос - плохая идея.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено xsignal , 01-Дек-24 14:32 
Так UEFI для этого и создавался...

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Ivan_83 , 02-Дек-24 02:00 
Опять нытьё обделённых что они в опасносте.
Ну таки да. Раз денег на ещё одну-две флешки жалко и на аппаратный переключатель защиты записи, то так и будет фигня творится.

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

Ну и просто по приколу скажу что считать/записать биос не проблема при наличии программатора и доступа к железу.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 15:15 
Да. Теми же словами: программатор-то и был на месте аппаратного переключателя защиты, когда "денег на ещё одну-две флешки жалко и на аппаратный переключатель защиты записи".

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

И именно они приносят инновации в реальность.

А экономика решает в их пользу.

Занятно: и для проприетарности и для опенсорса нужен высокий уровень образования. Вероятно, это две неотъемлемые части одного. Опенсорс даёт обмен знаниями между исследователями, рождая инновации, проприетарные поднимают эти знания, доводят инновацию до хомячков. И уже только после этого - выйгрышь.

Опенсорсу нужно своё железо.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 18:04 
> Занятно: и для проприетарности и для опенсорса нужен высокий уровень образования.

Сложный вопрос - с одной стороны у нас есть куча веб-камак ʼкурсы JS за две неделиʼ, а с другой - 100500 васяноподелий в стиле ʼя нажал кнопку форк и поменял обоиʼ.

> Вероятно, это две неотъемлемые части одного.

Возможно. Хотя проприетарь появилась гораздо раньше и показала свою жизнеспособность.

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

Звучит как фантазии)
Проприетаре, патентам, закрытым сообществам (типа муранских стеклодувов, где разглашение секретов каралось смертью) тысячи лет.
И именно они привели цивилизацию к прогрессу. А опенсорс это так, пена на поверхности истории.

Более того опенсорс появился в университетах, где исследователи (на зарплате от универа) делились безвозмездно друг с другом знаниями, не ограничивая области применения.
Но потом случилась катастрофа и бородатый коммуняка решил экспроприировать понятие свободы.

Он решил поставить пользователей выше чем создателей - так родился GPL-рак.
К счастью, люди стали умнее, и в последние годы комми-лицензии становятся все менее популярными.
Но ущерб был нанесен - для многих "открытое == бесплатное".

> Опенсорсу нужно своё железо.

Но для того чтобы его разработать нужны мозги и ресурсы.
А Сообщество™ это зачастую просто сборище нищуков-неудачников.
Достаточно кол-во ресурсов найдется только у корпораций и правительств. Которые будут не рады подарить конкурентам халяву.
Особенно учитывая последние события в мире.


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 18:08 
> Опенсорс даёт обмен знаниями между исследователями, рождая инновации

Ахаха, пощади, человек-анекдот!
Опенсорс рождает неюзабельные вырвиглазные поделия, на которые ни один нормальный человек тратить время не будет. Хотя может это были не роды, а выкидышь, тогда это многое объсняет.

Ну и еще копирует нормальную проприетарь.
Изредка получается, но чаще всего результат - жалкая пародия на оригинал.
Гимп, Гном и либрофис передают привет.

> проприетарные поднимают эти знания, доводят инновацию до хомячков.

Угу, именно поэтому уже 30 лет пытаются сделать юзабельный десктопный линукс, и всё никак)))

> И уже только после этого - выйгрышь.

Выйгрышь в войне с андройдами?


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 03-Дек-24 02:07 
>> Ну таки да. Раз денег на ещё одну-две флешки жалко и на аппаратный переключатель защиты записи, то так и будет фигня творится.

Не безопасно! Не практично! Поработает данный подход некоторое время, потом флешку вынимать не будут, чтобы время зря не терять.

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

И тем не менее некоторый слой защиты есть. Тут интересна другая проблема - как получить доступ к информации если будет руткит? Не загружаться? Отключить сеть?

>> Ну и просто по приколу скажу что считать/записать биос не проблема при наличии программатора и доступа к железу.

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


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Соль земли , 02-Дек-24 09:50 
Кто-то изучил загрузку Linux.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 10:03 
Вот блин. Я как раз пытаюсь избавиться от EFI, но Grub-coreboot на прошитый chromebook устанавливаться не хочет. sudo grub-install --target=i386-coreboot не работает. Может есть у кого опыт подобного? В интернете информации ноль.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 14:04 
Сhromebook, i386 : нестыковочка?

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 13:48 
В бутките обнаружен буткит. Ничего удивительного.

"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Аноним , 02-Дек-24 19:12 
> В бутките обнаружен буткит. Ничего удивительного.

И главное какой честный буткит
/opt/rootkit
/opt/rootkit_loader.ko
/opt/injector.so
/opt/dropper.ko

Красиво так по полочкам разложили, честно написали - "я руткит, не какая-то чукотская фигня".


"Выявлен UEFI-буткит Bootkitty, подставляющий вредоносный код..."
Отправлено Кирилл , 02-Дек-24 21:35 
UEFI Secure Boot решит все проблемы с буткитами говорили они...