Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В 806 моделях материнских плат выявлен тестовый ключ, позволяющий обойти UEFI Secure Boot"	+/–
Сообщение от opennews (??), 26-Июл-24, 12:51
Исследователи безопасности из компании Binarly выявили возможность обхода режима верифицированной загрузки UEFI Secure Boot на более чем 800 моделях материнских плат,  выпущенных компаниями Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo и  Supermicro. Проблема получила кодовое имя PKfail и связана с использованием в прошивках  не заслуживающего доверия ключа платформы (PK, Platform Key), сгенерированного компанией AMI (American Megatrends International) и поставляемого в качестве тестового примера. Наиболее старые прошивки, в которых использовался тестовый ключ, выпущены в 2012 году, а самые новые датированы июнем 2024 года. По данным исследователей проблеме подвержены более 10% всех проверенных прошивок... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61610
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 26-Июл-24, 12:51	+19 +/–
> производители не обратили внимание на предупреждение ну один не обратил внимание, ну два, но восемь сразу?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #14, #39, #81, #112, #183, #209

2. Сообщение от Аноним (2), 26-Июл-24, 12:52	+19 +/–
Секурно, что ещё сказать. Не то что BIOS.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #16, #25, #118, #226

3. Сообщение от Аноним (3), 26-Июл-24, 12:53	+7 +/–
Шо то, шо это, вот это таких два...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #26

4. Сообщение от Аноним (4), 26-Июл-24, 12:54	+45 +/–
У всех time to market горит, всем не до этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #164

5. Сообщение от Аноним (5), 26-Июл-24, 12:54	+/–
Театр безопасности. Реальная защита - зашифрованный корень и проверка с livecd хешсумм grub и boot при каждой загрузке.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #35, #57, #101, #113, #150

6. Сообщение от Аноним (6), 26-Июл-24, 13:02	+2 +/–
Хорошо бы название театра и фамилию Карабаса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #12, #19

8. Сообщение от Аноним (8), 26-Июл-24, 13:06	+9 +/–
Это же все для пользователей линуха, что бы не отключать SecureBoot и подписывать что сам насобирал себе =)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #114

9. Сообщение от vlad1.96 (ok), 26-Июл-24, 13:09	+8 +/–
В этой новости отражена вся заинтересованность многих производителей мат. плат в качественной прошивке. Это интересует ни пользователей, ни производителей.
Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от morphe (?), 26-Июл-24, 13:09	+2 +/–
Потому что от стандартных ключей SecureBoot никакого смысла нет, шифрование диска с tpm2 оно чаще всего не защищает, потому что зависимость PCR регистров от ядра системы и прочего делать неудобно и опасно, а со стандартными ключами никто не мешает загрузить любую другую систему. PlatformKey нужно выпускать свой, и загрузчик/ядро/прочее подписывать им, тогда и появляется реальная польза от SecureBoot.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #115

11. Сообщение от Аноним (11), 26-Июл-24, 13:09	+5 +/–
Отключил его сам. Какие подводные? Кто-то прошелестят ко мне в конуру и установит винду?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #256

12. Сообщение от vlad1.96 (ok), 26-Июл-24, 13:10	+3 +/–
Лично я фанат японского театра теней Букаккэ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

13. Сообщение от Bottle (?), 26-Июл-24, 13:15	+2 +/–
Интересно, эти ключи брутфорсом подбирались или АНБ намекнуло производителям?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #89

14. Сообщение от iCat (ok), 26-Июл-24, 13:16	+6 +/–
>> производители не обратили внимание на предупреждение >ну один не обратил внимание, ну два, но восемь сразу? А что тут такого? Это же всё - солидные коммерческие предприятия. А у нынешних коммерсантов девиз: "Ерак, ерак, и - в продакшен!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #56, #160

15. Сообщение от Аноним (15), 26-Июл-24, 13:17	+6 +/–
Секурбут это бэкдор для блатных - есть хоть кто-то, кто сомневался? Существует исключительно в падлостроительных целях как явно, так и подводнокаменно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #90

16. Сообщение от ryoken (ok), 26-Июл-24, 13:19	+1 +/–
Эхх, где же OpenFirmware...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #20

17. Сообщение от Ахз (?), 26-Июл-24, 13:21	+/–
Зато теперь можно клепать болгеносы, гордо заявляя о поддержке uefi sb, даже для самого себя.
Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от мяв (?), 26-Июл-24, 13:26	+7 +/–
100% машин идет с ключем МС, которым они подписывают все, что под руку попадет. потому, для "обхода UEFI Secure Boot" достаточно поставить пакет shim-signed, или как он в репах вашего дистрибутива называется, перенести один файлик на флешку и преспокойно грузить все, что душе угодно на любом компьютере с включеным sb. хотите безопасности - убирайте дофлтные ключи, вместе с shim'ом, ставьте свои, и настройте загрузку либо через UKI, либо efi-stub ядра. это парочка команд. только вот, при этом сценарии и никакие дефолтные ключи AMI не страшны, так что, мне совершенно не ясно, что так удивило автора новости. если кому интересно, про shim и нерабочий secure boot из каробки: https://habr.com/ru/post/446072/ гайд по настройке secure boot(на английском): https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #45, #48, #145

19. Сообщение от nox. (?), 26-Июл-24, 13:33	+3 +/–
Придумала Intel. А попыталась залочить на себя Microsoft. В последнем случае, как и все ее инициативы, один вред, а пользы нуль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

20. Сообщение от НяшМяш (ok), 26-Июл-24, 13:34	–2 +/–
https://support.system76.com/articles/open-firmware-systems/ Тут, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #27

21. Сообщение от nox. (?), 26-Июл-24, 13:35	+/–
Выразился бы точнее - для пользователей не-Windows.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #66

22. Сообщение от тоже Аноним (ok), 26-Июл-24, 13:36	–2 +/–
Истинно говорю вам: чем хуже, тем лучше. Ибо зло неизбежно пожрет самое себя.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

23. Сообщение от nox. (?), 26-Июл-24, 13:38	–2 +/–
Ну зачем такие сложности? Вынул жесткий диск. Скопировал, что надо. Вернул назад. Если запаролен, ломается на ура что в Windows, что в Linux.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #29, #46, #111

24. Сообщение от nox. (?), 26-Июл-24, 13:41	–1 +/–
Не в этом дело. Заметил первый раз, когда с Netware на Windows NT переходил. У эти ребят 30 лет делается все наоборот и вопреки здравому смыслу, но продать удалось же. Вот такой критерий - всё делать наоборот как доказательство, что продать можно всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #32

25. Сообщение от Аноним (25), 26-Июл-24, 13:42	+/–
AMI BIOS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #40

26. Сообщение от Аноним (26), 26-Июл-24, 13:46	+6 +/–
Ах, господа, первая сущность равно как и вторая мне одинаково постылы и столь решительно безрадостны, что скорее...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

27. Сообщение от ryoken (ok), 26-Июл-24, 13:48	+1 +/–
> https://support.system76.com/articles/open-firmware-systems/ > Тут, например. Батенька, вы бы сходили сами и прочли что там у них накорябано :).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

29. Сообщение от мяв (?), 26-Июл-24, 13:51	+/–
сломать условный luks легче, чем выполнить cp в терминале? ну, кому как. особенно, в случае современных систем, где 100 лет в обед, как argon2id с tpm и пароль спокойно может быть и дампом из /dev/urandom
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

30. Сообщение от Neon (??), 26-Июл-24, 13:57	+5 +/–
Вся эта фигня, UEFI Secure Boot - один сплошной маразм, палки в колеса для альтернативных ОС в угоду M$
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #124

32. Сообщение от kusb reg (ok), 26-Июл-24, 14:07	+/–
А чем Netware лучше и что именно вы заметили? Это интересно...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #33

33. Сообщение от nox. (?), 26-Июл-24, 14:25	+/–
Кто сказал, что она лучше? В ней (версия 3.12) управление пользователями и ресурсами организовано противоположно Windows NT. И представляется это менее удобным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #65

34. Сообщение от Аноним (34), 26-Июл-24, 14:25	+3 +/–
Ну вы что, это же SecureBoot! Вместо того чтобы при установке операционной системы добавить публичный ключ её автора как единственный доверенный, давайте все и сразу доверять нескольким ключам третьей доверенной стороны. И пускай эта сторона подписывает сертификаты любому желающему юридическому лицу, прошедшему через немного бюрократии и заплатившему символическую сумму. Затем каждое из этих лиц будет выпускать свои загрузчики, которым будет доверять все компьютеры с SecureBoot. А потом в некоторых (большинстве) из этих загрузчиков, в том числе выпускаемых той самой доверенной стороной будут находить уязвимости, позволяющие запускать произвольный код. А затем, давайте введем базу данных отозванных загрузчиков, которая будет обновляться через процесс, подобный обновлению UEFI, чтобы на каждом компьютере всегда была самая свежая версия. Всё это кратенько опишем в стандарте на 2800 страниц юридического текста и реализуем этот стандарт под щедрым слоем NDA и IP -- для облегчения аудита. В добавок обеспечим передачу ключей с TPM по незащищенной шине LPC -- чтобы злоумышленник с физическим доступом к компьютеру ни в коем случае не мог использовать микроконтроллер за 4$ в качестве логического анализатора для получения ключей от диска. А, и той самой доверенной третьей стороной конечно же сделаем Microsoft. Вот тогда точно все будет безопасно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41

35. Сообщение от onanim (?), 26-Июл-24, 14:26	+/–
это не реальная защита, потому что Secure Boot происходит до проверки хэшсумм grub и boot
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #43

37. Сообщение от onanim (?), 26-Июл-24, 14:27    Скрыто ботом-модератором	+3 +/–
господи, сколько же админов локалхостов в комментах не имеют ни малейшего понятия, что такое Secure Boot и как им пользоваться.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38, #59

38. Сообщение от тоже Аноним (ok), 26-Июл-24, 14:37	+/–
Вчера впервые увидел Windows 11. Полчаса с помощью гугля убеждал ноутбук, что мне не уcpалось регистрироваться в Майкрософт. В гробу я видал этим еще и пользоваться...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #42, #49, #146

39. Сообщение от Аноним (-), 26-Июл-24, 14:51	+9 +/–
>> производители не обратили внимание на предупреждение > ну один не обратил внимание, ну два, но восемь сразу? А ты их BIOS'ы вообще видел? Там такая продукция раджей что они работают по принципу "как-то сбилдилось, вроде не очень глючит, идем продавать!" Де факто вон то - жесткая индусятина. В хучшем ее виде. Таком что даже DLink на этом фоне может показаться не такой уж плохой. Достаточно посмотреть что например Linux пищет про таблицы ACPI при загрузке. Там баг на баге и багом погоняет. И если кто думал что это только в ACPI так - ага, щас. Индусский кот - так уж по всей площади.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #243

40. Сообщение от Аноним (-), 26-Июл-24, 14:53	+3 +/–
> AMI BIOS Давние тралициию AMI_SW же. Ну, это их ответ AWARD_SW такой был :). Так то удобно. Если с правильной стороны монитора, конечно. Я как-то так по приколу заметил что админы пароль поставили. Ну по приколу - вырубил кеш у проца да сменил пароль, чтобы им не скучно было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #172

41. Сообщение от Аноним (-), 26-Июл-24, 14:56	+1 +/–
> слоем NDA и IP -- для облегчения аудита. В добавок обеспечим > передачу ключей с TPM по незащищенной шине LPC -- ТАм давно уже SPI и I2C в почете, если вы так то не заметили. И кстати шифрование шины для TPM таки сделали. ...но вообше, если злыдень вам МК на шину развешивает - у вас, таки, нефиговые проблемы в системе. И ниакой секурьут вас уже таки - не спасет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #54

42. Сообщение от Аноним (42), 26-Июл-24, 15:00	+1 +/–
Полчаса? У меня для вас плохие новости. Возможно, лучше вам всё же зарегистрироваться да пользоваться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

43. Сообщение от Аноним (5), 26-Июл-24, 15:00	+/–
Перечитайте ещё раз моё сообщение. Вставляем флешку с livecd, проверяем хешсуммы. Если верные - вынимаем флешку, загружаемся в установленнуо ос. Всё, загрузка верифицирована. А в самой системе защита обеспечивается прямыми руками (не устанавливать из васянских сборок) и apparmor с selinux.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #86, #205

44. Сообщение от Kuromi (ok), 26-Июл-24, 15:00	+1 +/–
Ха-ха, а я всегда говорил, что Secure Boot это Тивоизация + иллюзия безопасности для интересующихся юзеров. Никакие спецслужбы он останавливать не должен, для них всегда есть отдельный вход.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #239

45. Сообщение от Аноним (5), 26-Июл-24, 15:02	+1 +/–
К сожалению, не каждый производитель позволяет устанавливать свои ключи. Часто ограничивают до ключей MS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #55, #102

46. Сообщение от Kuromi (ok), 26-Июл-24, 15:04	+/–
И как вы будете ломать LUKS  у которого ключи в TPM модуле, например? Разве что вас зовут Барак Байден, тогда вопросов нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #78, #92

48. Сообщение от iusearchbtw (?), 26-Июл-24, 15:23	–1 +/–
А еще проще не полагаться на tpm модуль, который можно снять паяльным феном, и просто хранить загрузчик и необходимое на флешке, спасибо uefi, и заверять уже после загрузки системы. Флешку носим с собой и вынимаем когда заканчиваем работу. Все безопасное просто, а следить за ключами и всегда подписывать ядра на лицо оверинжинеринг и когда нибудь это выйдет боком, плюс неизвестно какие баги находят для обхода secure boot в проприетарных прошивках плат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #58, #63

49. Сообщение от ryoken (ok), 26-Июл-24, 15:24	+/–
Прошу прощения за оффтоп :) На самом деле дел минут на 15-20. Первым делом в биос сетапе рубим сетевые интерфейсы (шланг с вафлей или только вафлю, по железу, у нормальных ноутов это есть). Вторым делом при запуске сего поделие монстрософта жмём SHIFT-F10 и пишем OOBE/BYPASSNRO (прям вот капсом без пробелов). апапарат ребутается и можно уже дальше в процессе создать админа локалхоста :). Кстати, всех причастных - поздравлямс!!! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #51

51. Сообщение от тоже Аноним (ok), 26-Июл-24, 15:29	+1 +/–
Ну естественно, я все это с бубном отплясал, поставил сотруднику на этот ноут рабочие программы, отдал и забыл, как страшный сон. Но кто-то же имеет этот зонд за свои же деньги...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #52

52. Сообщение от ryoken (ok), 26-Июл-24, 15:33	+/–
> Ну естественно, я все это с бубном отплясал, поставил сотруднику на этот > ноут рабочие программы, отдал и забыл, как страшный сон. Но кто-то > же имеет этот зонд за свои же деньги... 1. 95% не в курсе, что это зонд :) 2. Есть вероятность, что некоторые получают физическое удовольствие при использовании "сервисов Microsoft" :D.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #70

54. Сообщение от Аноним (34), 26-Июл-24, 15:49	+/–
> ТАм давно уже SPI и I2C в почете, если вы так то не заметили. И кстати шифрование шины для TPM таки сделали. На последнем железе он интегрирован прямо в процессор. Но сам факт что такие дырявые системы с незащищенной шиной продавались и продаются как "Secure"Boot, говорит многое об этом театре безопасности. Как они интересно до установки защишенного канала между процессором и TPM производят обмен ключами? Вряд ли конечно, но не удивлюсь если в плейнтексте при каждом включении. > ...но вообше, если злыдень вам МК на шину развешивает - у вас, таки, нефиговые проблемы в системе. И ниакой секурьут вас уже таки - не спасет. Так весь смысл SecureBoot в защите от физических атак. Он сам по себе должен защищать от незаметной для владельца подмены загрузчика. А в связке с TPM должны защищать от добычи данных с украденного устройства. Со вторым сценарием как раз таки и не справляется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #117, #139, #170

55. Сообщение от мяв (?), 26-Июл-24, 16:10	+2 +/–
эм.. кто? эти переменные, согласно спеке, нельзя помечать как ro. intel boot guard и то смотрит только в {PK,KEK,db,dbx}-Default, не трогая PK, KEK, db и dbx. если просто нет пункта в граф. интерфейсе, то, во-первых, есть keytool.efi, по-моему, он даже в одном пакете с shim в дебиане, во-вторых, возможно, плохо искали. я например первый раз делала через keytool, а потом, когда ключи запорола, узнала про комбинацию, включающую расширенный режим в uefi, где и было соответствующее меню.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

56. Сообщение от Аноним (56), 26-Июл-24, 16:12	–12 +/–
Этот "девиз" - у всех кто сейчас что-то полезное делает. Времена "проэктирования" где 5 лет могли переливать из пустого в порожнее прошли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #99, #110, #193

57. Сообщение от Аноним (56), 26-Июл-24, 16:13	+4 +/–
> Театр безопасности. Реальная защита - зашифрованный корень и проверка с livecd хешсумм grub и boot при каждой загрузке. Это уже цирк безопасности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

58. Сообщение от Аноним (56), 26-Июл-24, 16:15	+/–
После загрузки у тебя уже загружен код который раздостно заверит тебе всё что угодно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #60

59. Сообщение от Аноним (56), 26-Июл-24, 16:17	+/–
> господи, сколько же админов локалхостов в комментах не имеют ни малейшего понятия, что такое Secure Boot и как им пользоваться. А это говорит о secure boot, а не местной аудитории. Есть много вещей посложнее с которыми ни у кго проблем нет, а тут мутная дырявая технология - разбираться в ней уважающий себя администратор не обязан, такое можно полностью игнорировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #123

60. Сообщение от Аноним (-), 26-Июл-24, 16:22	+/–
Также как и с tpm модулем, только в случае с флэшкой до неё труднее добраться. А tpm  модули, кстати, некоторые можно прочитать не снимая с платы, просто подобравшись специальной прищепкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #64

62. Сообщение от Аноним (65), 26-Июл-24, 16:27	+2 +/–
> Закрытая часть тестового ключа AMI, необходимая для создания цифровых подписей, оказалась доступна публично после утечки информации у одного из производителей оборудования, сотрудник которого по ошибке разместил в публичном репозитории на GitHub код, содержащий данный ключ. Закрытый ключ был размещён в зашифрованном файле, при шифровании которого использовался простой 4-символьный пароль, который удалось легко подобрать методом перебора. так где скачать-то? друг просил...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #71, #262

63. Сообщение от мяв (?), 26-Июл-24, 16:32	+/–
раз - уже давно tpm встраивают в процессоры, так что, вероятно, замаятесь снимать. два - зачем? Вы из него ключи вытаскивать собрались? если так, то закалебетесь вытаскивать из чипа с актуальной прошивкой. касаемо флешек.. ну, Вы серьезно? так часто слышала этот тезис, если его можно так назвать, и не понимала, верит ли вообще сам человек в собственные слова. что до "оверинжениринга", мне не ясно, что Вы имеете в виду. это ужа давно делает автоматика. я генератор uki трогаю только в том случае, когда мне надо параметры ядра, например, поменять. как может выйти боком исполнение пост-инсталл скрипта, поставляемого дистрибутивом, мне тоже не понятно. ровно, как и про жуков. найдете - тогда поговорим. так-то, и в алгоритмах шифрования находят уязвимости, это неизбежно. сейчас есть все средства для верификации кода, исполняемого прошивкой и ограничения "изнутри", созданные именно для смягчения ситуаций с багами. много Вы багом видали за последнее время, не связанных с сетевой загрузкой, или косяком конкретного производителя?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #76, #128

64. Сообщение от мяв (?), 26-Июл-24, 16:34	+/–
нет, товарищ, в случае с tpm модулем, если он зафиксирует изменение прошивки, или базы данных sb, он вас лесом пошлет. надеюсь, Вы не тролль
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #82

65. Сообщение от Аноним (65), 26-Июл-24, 16:35	+/–
> В ней (версия 3.12) управление пользователями и ресурсами организовано противоположно Windows NT простите, я нетварь не видел, но как подобные вещи вообще можно сделать по-разному?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #224

66. Сообщение от Аноним (66), 26-Июл-24, 16:40	+2 +/–
Нет, он всё правильно написал. Все остальные ОС на реальном железе не работают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #94

67. Сообщение от Аноним (67), 26-Июл-24, 16:46	+/–
>не обратили внимание на предупреждение Сами, или их настоятельно попросили?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #73

70. Сообщение от kusb reg (ok), 26-Июл-24, 16:49	–1 +/–
Я мазохист, но даже как мазохистскую практику я бы предпочёл использовать это в виртуалке. И не понятно где там стоп-слово.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #85

71. Сообщение от мяв (?), 26-Июл-24, 16:54	+/–
можешь скачать shim-signed из реп своего дистрибутива и, блягодаря поитике подписывания загрузчиков майкрософта, грузить им, шо угодно, на любых девайсах, т.к. на 99% машин в db есть ключ МС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

73. Сообщение от мяв (?), 26-Июл-24, 16:55	+/–
зачем просить "не замечать", когда можно попросить ключ..?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

76. Сообщение от Аноним (76), 26-Июл-24, 17:01	+/–
Переусложнённая система. Обязательно что-нибудь выйдет боком. Почитайте теории сложности и надёжности. В популярном изложении "законы Мерфи".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #77

77. Сообщение от мяв (?), 26-Июл-24, 17:07	+/–
в случае с флешкой - она у Вас из кормана выпадет. а "что-нибудь" и, тем более, "почитайте", пожалуйста, оставьте себе. я почему-то вместо того чтобы просто сказать "народ, учите матчасть", вам тут что-то обьяснить пытаюсь. придумаете хотя бы какой-то суенарий - тогда и напишите. а это скукота какая-то выходит и аргументация уровня кофейной гущи
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #83, #121

78. Сообщение от анон (?), 26-Июл-24, 17:23	+/–
Гаечным ключем и пустырником.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #97

79. Сообщение от Аноним (79), 26-Июл-24, 17:32	+/–
Кучно пошло. В Phoenix бэкдор в коде, у AMI бэкдор в корнях.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #136

80. Сообщение от Аноним (80), 26-Июл-24, 17:37	+1 +/–
https://www.linux.org.ru/forum/security/17682542?cid=17685158 Ещё раз напомню 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 должен создаваться на компе конечного пользователя. 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 Security Boot и подпись загрузчика Windows (комментарий) 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 зависит от производителя железа. Возможна опциональная поддержка для конкретного железа.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #138

81. Сообщение от Аноним (81), 26-Июл-24, 17:51	+/–
Bios кто делал? Зачем произодителю плат туда лезть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

82. Сообщение от Аноним (82), 26-Июл-24, 17:59	–3 +/–
Сразу видно человека, который про такие атаки только в интернете читал. На хабре можете почитать статьи как разревёрсить сигналв с модуля tpm и прочитать регистры. Знающие люди чтобы не усложнять и без того сложные схемы действительно ходят с флешкой со всем необходимым и максимально разграничивают незашифрованные и зашифрованные данные, и ничего не хранят в третьем компоненте системы. Благодаря этому всегда можно просто вытащить диск и бутнуться с другого компьютера, только идентификаторы от железа могут остаться в новой машинке, но это другая история. Если вы думаете что модуль tpm какой то магический и из него сложнее вытащить данные по сравнению с незашифрованным разделом на ссд, вы сильно заблуждаетесь. Просто не люблю дурачков, которые оправдывают схему с tpm, не зная поднаготной реальных атак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #93

83. Сообщение от Аноним (-), 26-Июл-24, 18:03	+/–
Чел, что мешает мне с такими аргументами потерять ноутбук?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #134

85. Сообщение от Аноним (85), 26-Июл-24, 18:22	+1 +/–
alt+f4 же (;
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

86. Сообщение от _ (??), 26-Июл-24, 18:22	+1 +/–
Думаешь тебе в Сиэтл (или где там вы хоститесь?) командировки светят а?, вставляльщик лайвсидей? :) Так нет же - образ того лавсидя ваши девопсы точно так же на гитхаб положат :) Чтоб по сети монтировать и чекать :) Нонешнее оЙтЕ - бессмысленное и беспощадное, да :))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #162

89. Сообщение от _ (??), 26-Июл-24, 18:27	+/–
>Интересно, эти ключи брутфорсом подбирались 4 символа бро - мои часы наверное секунд аж 30 бы подбирали пароль ... Serious Security(C)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #100, #263

90. Сообщение от Аноним (90), 26-Июл-24, 18:30	+/–
Тут постоянно проскакивают люди из мира розовых пони которые уверены что это просто ошибки. Даже не верят что IME это зонд. Таких уже на вылечить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #95

92. Сообщение от Аноним (92), 26-Июл-24, 18:36	+/–
> И как вы будете ломать LUKS  у которого ключи в TPM модуле, например? Терморектальный криптоанализ пока никто не отменял...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #127, #129

93. Сообщение от мяв (?), 26-Июл-24, 18:39	+/–
Вы б, господин "знающий людь" поменьше языком работали и давали больше фактов! :) Влибо факты давайте, либо не скатывайтесь в бросание сами знаетея, чем и "дурачков" Вы, судя по всему, мой тезис про tpm в процессорах проигнорировали. что ж, ткну еще раз - это работает(или работало? углубляться даже лень, ибо меня не касается) только с отдельными чипами. из процессора Вы, опять же, ничего не нанюхаете. ну и, да, забавно видеть "человека, который читал тотолько в интернете" и через пару слов - "посмотрите на хабре" еще более потешно, что Ваш второй комментарий скрыл модератор. Зы. почти все(если не все, но зарекаться сейчас не буду) косяки в процессорных tpm'ах фиксятся обновлением прошивки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #98

94. Сообщение от Аноним (94), 26-Июл-24, 18:39	+/–
И Фантом?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

95. Сообщение от Аноним (94), 26-Июл-24, 18:41    Скрыто ботом-модератором	+/–
А революцию социалистическую если?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

97. Сообщение от Аноним (94), 26-Июл-24, 18:50	+/–
Ключом. Извините ) https://youtu.be/tLsef4HaXOk
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

98. Сообщение от Аноним (98), 26-Июл-24, 18:54	+/–
По хабру кстати неплохая статья реально была, там чел не ломал секьюр бут вроде а просто пытался загрзузить систему лол, показательно куда эта схема с секьюр бутом и оправдывающими это адептами микрософта могут идти
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #131

99. Сообщение от нах. (?), 26-Июл-24, 19:00	+9 +/–
поэтому нате вам закрытый ключ от всего - на шитхаб, с паролем 1234 (и тот в соседнем файлике записан) спринт же ж не может ждать. Время тяпляперов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #242, #264

100. Сообщение от нах. (?), 26-Июл-24, 19:02	–1 +/–
"если выглядишь вкусно - не гуляй вечером в парке!" отрежут же часы вместе с рукой, и сам будешь виноват.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

101. Сообщение от mos87 (ok), 26-Июл-24, 19:03	+/–
от кого защищаться собрался онон?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #227

102. Сообщение от нах. (?), 26-Июл-24, 19:05	+/–
Мне что-то подсказывает, что у это...их производителей (namely apple) НЕТ того левого ключа microsoft которым та (предсумотрительно) подписала shim. А винду корпорация-зла, не будь дура, ни разу не этим же ключом подписывает. Так что ваша дисяточка там загрузится без проблем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #130

103. Сообщение от mma (?), 26-Июл-24, 19:10	+/–
Любителям секурности. Грузитесь с внешнего ключа(flash, tpc, etc), там же и ключь к ФС. Загрузились, убрали ваш ключ куданибудь, бинго. Во времена финансовой свободы так обычно и делали те кому есть что прятать от аудиторов в погонах)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #207

105. Сообщение от Витюшка (?), 26-Июл-24, 19:28	+1 +/–
Какой смысл после этого (и сотни других) примера про безопасность и тратить миллионы человеко-часов на переписывание кода? Вот это - и есть настоящее современное IT.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #107

107. Сообщение от Аноним (90), 26-Июл-24, 20:01	+1 +/–
Так никто ничего и не переписывает все только языками чешут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

109. Сообщение от Аноним (109), 26-Июл-24, 20:05	+1 +/–
> Проблема получила кодовое имя PKfail Почему же сразу "проблема"? Не проблема, а фича! )
Ответить | Правка | Наверх | Cообщить модератору

110. Сообщение от penetrator (?), 26-Июл-24, 20:06	+3 +/–
те кто 5 лет гнали такой порожняк, сейчас гонят таймтумаркет, т.е. для твоего контингента ничего изменилось, упорно делаете вид, что работаете, а пипл не владеющий профильными знаниями хавает это все (не все конечно) есть производители, кто всегда делал по-другому, хотя конечно конкурировать с девляперами и прочим "ширпотребом" сложнее, потому что пользователь сам же их поощряеет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

111. Сообщение от penetrator (?), 26-Июл-24, 20:11	+/–
откуда информация? т.е. ты сможешь расшифровать LUKS диск с KDF argon AES-XTS? можно больше подробностей?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

112. Сообщение от Хрю (?), 26-Июл-24, 20:16	+16 +/–
Да никому этот UEFI Secure Boot не usralsa, вот и всё. Чтоб действительно оно как-то секурно работало, там надо проделать тонну вообще не очевидных действий. И не единожды - технология совершенно не жизне способна - маркетинговое гонево не более.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

113. Сообщение от qwe (??), 26-Июл-24, 20:45	+/–
А еще не забывай пересчитать хэши после каждого обновления grub и boot.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

114. Сообщение от Аноним (114), 26-Июл-24, 21:43	+/–
Чтобы подписывать самосбор, никакие ключи не нужны, кроме тех, которые сгенерируешь сам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

115. Сообщение от Аноним (114), 26-Июл-24, 21:47	+/–
>  а со стандартными ключами никто не мешает загрузить любую другую систему Это не так. При загрузке "любой другой системы" (пусть хоть другой винды c LiveCD) у тебя диск не расшифруется автоматически, и тебе понадобится какой-то запасной вариант (при условии, что владелец машины его предусмотрел, например, настроил авторасшифровку при обычной загрузке и расшифровку с паролем при "необычной" загрузке).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

117. Сообщение от glad_valakas (-), 26-Июл-24, 22:17	+1 +/–
> Так весь смысл SecureBoot в защите от физических атак. нет смысла. против физических атак только физическая защита: охранники, СКУДы, замки + ключи, железные двери, бумажные журналы доступа. и видеонаблюдение разумеется. ps: есть такое суперзащищенное электронное голосование, на котором всегда выберут кого надо. чем-то напоминает SecureBoot, не правда ли ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

118. Сообщение от Аноним (118), 26-Июл-24, 22:45	+/–
ох.. универсальный пароль AWARD Bios все помнят ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #143

120. Сообщение от fazi (ok), 26-Июл-24, 23:09	+/–
Последняя мама Z790 AORUS. Прилично бабок цена. Вывод как на скрине. Блин за что я деньги платил ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #122, #126, #137, #142

121. Сообщение от Аноним (121), 26-Июл-24, 23:09	–3 +/–
Эээ.. Некоторым и самые прямые аргументы будут "совершенно бездоказательны" и "скучны". Свежий пример: плата от Asrock на чипсете от Intel. EFI загрузчик на флешке увидела примерно попытки с 15-й. Установленная Fedora запускалась нормально 2 недели. Затем EFI на ровном месте потерял её запись, обнаружилось при тёплом рестарте. Если указатель на загрузчик просто "испарился", где гарантии, что так же не "испарятся" ключи или пароли на сам EFI? В какой-то момент понадобится что-то срочно сделать, а человек вместо этого должен будет раскирпичивать устройство... С DOS-овым загрузчиком и GRUB2 вообще никаких проблем. Потому что он "простой как 3 копейки". Да секур проблема есть, с EFI попытка зачтена, причём как неудачная. Нужно идти дальше и рассматривать более другие решения. Посмотрите, не читайте, хотя бы по диагонали доку на Clover - это одна из реализаций EFI от сообщества под MIT-подобной лицензией - сколько там параметров в настройках, и коментарии к ним. Да, проделана титаническая работа. Однако, тем не менее, очень многие параметры вообще ни на что не влияют. И да, я пытался заменить глюченый закрытый EFI от Asrock открытым Clover. Но последний так и не запустился ни в одном из описаных вариантов установки (ну, кроме .exe инсталятора, который просто не на чем запускать). Занавес.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #135

122. Сообщение от penetrator (?), 27-Июл-24, 00:17	+2 +/–
ты платил за понты а что платили владельцы HP, Intel, Supermicro - вопрос всякое дно уровня Dell и Acer вопросов нет, но серверные мамки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

123. Сообщение от onanim (?), 27-Июл-24, 00:42	+1 +/–
>> господи, сколько же админов локалхостов в комментах не имеют ни малейшего понятия, что такое Secure Boot и как им пользоваться. > А это говорит о secure boot, а не местной аудитории. Есть много > вещей посложнее с которыми ни у кго проблем нет, а тут > мутная дырявая технология - разбираться в ней уважающий себя администратор не > обязан, такое можно полностью игнорировать. это как раз говорит об "уважающих себя" админах, не осиливших мануал по Secure Boot на 2 листа а4 крупным шрифтом или пол листа мелким
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

124. Сообщение от Аноним (124), 27-Июл-24, 01:54	+/–
Так UEFI сделали в Microsoft. Там из полезного разве что старт сразу в 64-битность. Остальное так шум для маркетинга про безопастность
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

125. Сообщение от Аноним (126), 27-Июл-24, 02:25	–1 +/–
"производители не обратили внимание" - читай "ФБР рекомендовало не обращать внимание на какой-то там тестовый ключ".
Ответить | Правка | Наверх | Cообщить модератору

126. Сообщение от Аноним (126), 27-Июл-24, 02:27	–1 +/–
> Блин за что я деньги платил ? Не обижайся, просто "налог на тупость". НЕЛЬЗЯ сейчас приобретать никакие мамки!! ЖДАТЬ. Пусть г____ноеды-мануфакчуреры едят собственное дерьмо. Что мы хотим: мамки от $100 до $300. Полная секурность, включая полную блокировну Intel IME.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #140

127. Сообщение от Kuromi (ok), 27-Июл-24, 03:03	+/–
>> И как вы будете ломать LUKS  у которого ключи в TPM модуле, например? > Терморектальный криптоанализ пока никто не отменял... Ну до пустим вы выкрали диск (а может быть даже его образ, побайтовый) и даже нашли чела который знает пароль\PIN к TPM модулю, но самого модуля у вас нет, или он был обнулен, потому что насколько я помню нельзя так просто переставить съемный с одной материнки на другую. Что дальше? Ключ-то был в TPM. Как ни крути оказывается что вам уже нужен весь "программно-аппаратный комплекс".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #132, #158

128. Сообщение от Kuromi (ok), 27-Июл-24, 03:08	+/–
> раз - уже давно tpm встраивают в процессоры, так что, вероятно, замаятесь > снимать. два - зачем? Вы из него ключи вытаскивать собрались? если > так, то закалебетесь вытаскивать из чипа с актуальной прошивкой. Идея встроить TPM  в процессор одновременно прекрасна и ужасна. С одной стороны это и правда секурно, с другой стороны выстрелить себе в ногу и потерять ключики в TPM модули оказывается невероятно легко. Обновление прошивки у некоторых производителей - сброс TPM, замена материнки - сброс TPM и так далее. Образ диска украденный через мировой эфир и правда становится бесполезен, но может стоит хранить ключики на чем-то чуть менее встроенном?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #133

129. Сообщение от мяв (?), 27-Июл-24, 05:53	+/–
ну и сравните его с выполнением cp в терминале 1 раз
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #159

130. Сообщение от мяв (?), 27-Июл-24, 05:55	+/–
у них и возможность грузить что то кроме macos без костылей нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #141

131. Сообщение от мяв (?), 27-Июл-24, 06:01	+/–
ну, факты будут? ссылки? что-то? если есть - давайте, почитаю. из того, что знаю - перепрошивка платы, что фиксится iBG'ом и описанное в первоначальном сообщении. + проблемы, специфичные для некоторых производителей. не представляю уж, что Вам там такого написали, но что точно знаю - это куда могут идти товарищи, кричащие про "адептов майкрософта" в контексте sb, особенно, под сообщением с призывом зашить свои ключи, лол.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

132. Сообщение от мяв (?), 27-Июл-24, 06:05	+/–
еще большее веселье наинается когда у пользователя запоминаемая часть в голове, а незапоминаемая - в tpm. у меня так, по крайней мере
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #168

133. Сообщение от мяв (?), 27-Июл-24, 06:22	+/–
иначе никак, собственно. бэкапы ключей из tpm делаются в пару команд и никто не мешает залить их на флешку и хранить дома. в конце концов, может и диск из строя выйти, это цена хранения данных в цифровом виде. продукцию этих самых "некоторых производителей" можно и не покупать, лол. "некоторые производители" могут Вам и устройство бракованное дать, что с того-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #161, #169

134. Сообщение от мяв (?), 27-Июл-24, 06:24	+/–
сказал человек с аргументом "что-то выйдет боком", лол?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

135. Сообщение от мяв (?), 27-Июл-24, 06:29	+/–
во-первых, Вам стоит на на опеннете об этом писать, а производителю с требованием возврата средств. во-вторых, я всех деталей не знаю, может вообще Вы сами себе что-то накрутили. у меня, например, послы вытаскивания батарейки с платы, и пароль, и ключи остались на месте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #206

136. Сообщение от мяв (?), 27-Июл-24, 06:37	+/–
Вы что-то кроме заголовка читаете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

137. Сообщение от мяв (?), 27-Июл-24, 06:41	+/–
secure boot и так нигде не работает из каробки из за подписанного майкрософтом shim и того факта, что их ключ везде в db/KEK суют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #181

138. Сообщение от мяв (?), 27-Июл-24, 06:50	+/–
на кой вообще в цепи гроб, в котором уязвимость, позволяющая обойти верификацию - "обычный понедельник" ? что по ima, в линуксе по дефолту запрещен ввод кастомных политик в ранатйме, следовательно, остается 2 варианта из дефолтных: верифицировать всю фс, включая временные файлы с логами или верефицировать только исполняемые файлы. так что, мне не ясно, что там автор про верификацию /etc затирает. 3й ненужен, ибо он был добавлен еще до появления sb. по поводу iBG... автор там какого чая напился? свои ключи зашить можно было в полтора устройства из "бракованных" партий. по дефолту там кореновй ключ интела в пзу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #144, #147, #186

139. Сообщение от мяв (?), 27-Июл-24, 06:54	+/–
>весь смысл SecureBoot в защите от  физических атак та ты шо? от физ. атак защищают технологии, вроде intel boot guard. а sb сбивается перепрошивкой платы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

140. Сообщение от Аноним (140), 27-Июл-24, 07:29	+2 +/–
>Что мы хотим: мамки от $100 до $300. Полная секурность, включая полную блокировну Intel IME Да ты я смотрю большой оптимист.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

141. Сообщение от нах. (?), 27-Июл-24, 08:47	+/–
> у них и возможность грузить что то кроме macos без костылей нет интеловские - прекрасно умеют грузить вендупоганую.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #151

142. Сообщение от Аноним (142), 27-Июл-24, 09:11	+/–
Ты купил плату от Gigabyte и ожидал, что у нее будет беспроблемный биос? Этот производитель всегда славился наплевательским подходом в разработке bios для своих продуктов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #228

143. Сообщение от Артём (?), 27-Июл-24, 09:24	+/–
AWARDSW :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #213

144. Сообщение от Аноним (144), 27-Июл-24, 09:30	+/–
1. У меня старый GRUB2 до "обновлений безопасности" верифицирует все при загрузке и ЭКСПЛУАТИРУЕМЫХ уязвимостей не имеет. 2. Все зависит от настроек IMA. Есть возможность вводить политику IMA в рантайме единожды. При этом политика обязательно должна быть подписана ключом с ядерного кэйринга. Есть возможность вообще запретить изменения политики IMA в рантайме. 3. Изучите внимательно документацию по настройке политик IMA. Я сумел настроить IMA чтобы он верифицировал файлы пользователя root в /etc и не верифицировал изменяемые файлы пользователя root в /tmp, /var/log, ... это просто. Чуть сложнее обеспечить верификацию содержимого initrd в IMA, но если чуть помучатся это тоже реализуемо. Да я не использую дефолтную политику TCB поскольку она для дефолтного GNU/Linux не подходит. Надо всем в Linux чуть править политику IMA по умолчанию. 4. Использование GRUB2 в цепочке загрузки нужно в случае необходимости скрыть содержимое модулей GRUB, настроек, ядра и инитрд. Только GRUB2 умеет на сегодня проводить верифицированную загрузку с шифрованного раздела. Прошивки UEFI пока не умеют грузить ядра с шифрованных разделов. Кроме этого GRUB2 обеспечивает верификацию ядра и инитрд в системах без Secure Boot. 5. Ключ Intel Boot Guard можно добавить в область ROM в IntelME только когда процессор соеденен с материнской платой. Если купить материнку отдельно от процессора, то пользователь будет иметь возможность самостоятельно установить свой публичный ключ Intel Boot Guard в область ROM в IntelME. Это описано в документации Intel и надо знать всем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #154

145. Сообщение от нах. (?), 27-Июл-24, 09:33	–1 +/–
> потому, для "обхода UEFI Secure Boot" достаточно поставить пакет shim-signed, или как > он в репах вашего дистрибутива называется, перенести один файлик на флешку > и преспокойно грузить все, что душе угодно на любом компьютере с > включеным sb. и зачем такие сложности, если можно просто венду загрузить? secure boot защищает вовсе не от этого. > хотите безопасности - убирайте дофлтные ключи, вместе с shim'ом, ставьте свои, и это не совсем та безопасТность которой мы хотим. > если кому интересно, > про shim и нерабочий secure boot из каробки: https://habr.com/ru/post/446072/ занятная статейка, но 2019го года. С тех пор вроде слуцилась что-то, и вполне возможно что ключи шпион-капитана касперского везде давно заблокированы, а где еще не - достаточно разок загрузить венду поновее любимой многими тут XP, и станет заблокировано, без всякого уведомления щасливых юзеров. И заметим, оно не про неработающий, secure boot-то вполне работает. Оно про технологическое отверстие, заботливо оставленное фсбшным кротом международного масштаба. (интересно, кто ему подписал загрузчик уже после истории с кражей секретных документов, кто это такой добрый и небрезгливый) Отдельно прекрасно что афтырь распространяет свой кот с троянцем через Zeronet, чтобы не спалиться раньше времени. (стоит ли запускать его, оттуда скачаный - это вот сами подумайте)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #153

146. Сообщение от нах. (?), 27-Июл-24, 09:35	+/–
> Вчера впервые увидел Windows 11. админы локалхоста в тредике, как и было сказано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

147. Сообщение от Аноним (144), 27-Июл-24, 10:09	+/–
> по дефолту там кореновй ключ интела в пзу. 1. Купив проц и мамку раздельно пользователь будет иметь возможность добавить СВОЙ ЛИЧНЫЙ публичный ключ Intel Boot Guard в ROM область в IntelME, для верификации UEFI (LibreBOOT, CoreBOOT) и СВОИХ ЛИЧНЫХ ключей Secure Boot. Включенный единожды Intel Boot Guard отключит физически невозможно. 2. Если купили готовый ноут, то ИМЕННО производитель ноута прописывает СВОЙ ЛИЧНЫЙ публичный ключ Intel Boot Guard в ROM область в IntelME, для верификации  СВОЕЙ ноутбучной прошивки UEFI и ключа Микрософт для Secure Boot. Производитель ноутов при этом может безопасно обновлять свою прошивку UEFI, а компания Микрософт может безопасно обновлять неизменяемые в процессе работы бинари, библиотеки и структуры MS Windows. В этом случае в общем установка GNU/Linux возможна при отключённом Secure Boot. Возможность верификации загрузки системы с помощью GRUB и Linux IMA/EVM все равно необходимо использовать. 3. IntelME - закрытый бинарный блоб в котором теоретически могут находится ещё и ключи Intel, NSA, ... которые также могут использоваться для верификации инженерных прошивок и буткитов в UEFI. Здесь пользователь покупая проц Intel должен полностью доверять блобу IntelME.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #156, #165

150. Сообщение от Денис Попов (?), 27-Июл-24, 10:18	+2 +/–
Это уже было 30 лет назад под DOS. Называлось ADinf
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

151. Сообщение от мяв (?), 27-Июл-24, 10:56	+/–
оно уже и не поддерживается эплом
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #185

152. Сообщение от Tron is Whistling (?), 27-Июл-24, 10:57	+/–
Ну вот согласен с теми, кто говорит, что оно нафиг никому не в$ралось. Инженерные ключи, shim-загрузчики чего угодно, и т.п. Не прижилось. Всем пофиг. Театр безопастности.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #179

153. Сообщение от мяв (?), 27-Июл-24, 11:04	–1 +/–
>защищает не от этого именно от этого, от подмены загрузчика со стороны ОС, что можно прекрасно сделать, блягодаря shim. рассказы про "злой мс" и "вендорлок", если Вы об этом, оставьте себе. >что ключи шпион-капитана касперского везде давно заблокированы Вы статью читали? ключи майкрософта и их все устраивает. софт касперского, как работал, так и работает. > и станет заблокировано галлюцинировать не надо. ключи майкрософта и ими они подписывают собственные драйвера. >фсбшным кротом ясненько. не стоило отвечать, вероятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #198

154. Сообщение от мяв (?), 27-Июл-24, 11:19	+/–
1. поздравляю, завтра будет. не завтра - так послезавтра, или тогдач когда Ваше 6е чувство Вас подведет и Вы забудите о новой уязвимости. >старый тем более. значит уже есть. зачем тебе этот пережиток прошлого, когда у ядра есть  efi-stub, или вообще uki можно использовать? 2. ага. только вот не от "настроек", а от параметров сборки ядра. я это прочла именно из документации после того, как день убила на попытку это сделать. в дебиане и альпайне оно запрещено. или вообще по дефолту в линуксе, ибо в дебиановскрм треккере патчей ничего о намеренном включении сей фишки нет. 3. ну, я-то поправила, даже подписала. а при попытке загрузить - ошибка в klog, говорящая "низя". и не из за несоответствия подписи. зачем measured boot в нем в ключать - я без понятья. Вы ж сами про настройку sb выписывали. 4. зачем шифровать /boot, если у Вас sb включен, м? esp все так же расшифрован, это ничего не дает. и да, у Вас __система с sb__, на кой черт конкретно в вашем случае гроб? 4. а, Вы об этом? тогда ладно, но никто так задуряться не будет, особенно, если ноутбук(а вне контекста ноутбуков, мне вообще не ясно, на кой вся эта котовасия)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #163

156. Сообщение от мяв (?), 27-Июл-24, 11:25	+/–
1. Вы ж написали уже это 2. действительно. в памяти почему-то отложилось, что корень от интел
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #166

158. Сообщение от ProfessorNavigator (ok), 27-Июл-24, 12:12	+/–
> Ну до пустим вы выкрали диск Зачем мне чего-то красть?)) Если будет очень надо, я просто возьму владельца диска и вежливо спрошу, что на нём находится. Сам жёсткий диск мне для этого не нужен. Причём спрашивать сначала буду действительно вежливо - далеко не всегда нужно человека резать на куски, чтобы он рассказал всё, что знает. Обычно достаточно просто продемонстрировать, что ты можешь и готов это сделать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #167

159. Сообщение от ProfessorNavigator (ok), 27-Июл-24, 12:24	+/–
> ну и сравните его с выполнением cp в терминале 1 раз Ага, а потом ещё разбирать терабайты данных. Часть из которых может быть зашифрована независимо. Как и написал выше в другом комментарии - зачем? Я просто возьму того, кто знает, что мне нужно, и вежливо спрошу. Так будет гораздо быстрее и проще. Если вежливость не поможет, тогда к ней можно добавить демонстрацию чего-нибудь колюще-режущего. Далее по нарастающей, в зависимости от срочности и необходимости данной конкретной информации. Вам чисто для справки: чтобы получить от человека нужные сведения достаточно, чтобы у него были один глаз, одно работающее ухо и три пальца на рабочей руке. Но чаще всего до такого состояния не доходит. Поскольку либо человек расскажет всё гораздо раньше, либо информация получается каким-либо другим путём, без членовредительства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #180, #182

160. Сообщение от Бывалый Смузихлёб (ok), 27-Июл-24, 12:40	+1 +/–
Многие из производителей ноутов являются, по сути, брендами, заказывающими железо вплоть до полной разработки и изготовления плат на стороне. Обычно это одна из нескольких ОЕМ контор в ЮВА. Те, кто разрабатывал и делал лично( тот же самсунг ) в списках, по случайному совпадению, не оказался
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #203

161. Сообщение от Аноним (161), 27-Июл-24, 13:22	+/–
> в конце концов, может и диск из строя выйти, это цена хранения данных в цифровом виде. Именно в силу возможности выхода из строя вторичного носителя приходится делать бекапы, что нивелирует сам смысл хранения ключей в TPM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

162. Сообщение от Аноним (162), 27-Июл-24, 13:36	+/–
Думаешь, твои выдуманные проекции на других что-то значат в реальности?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

163. Сообщение от Аноним (164), 27-Июл-24, 13:36	+/–
1. > > старый > тем более. значит уже есть. Или наоборот, в старом не было, а в новых появились. 2. IMA включается при настройке ядра и ее ключи также. В дистрибутивах с бинарным ядром Linux поддержки IMA не бывает. В Gentoo пробовали ковырять IMA. 3. У меня в 2 этапа проходит установка и обновление. Сначала грузимся в режиме с отключенным apperise, в котором, IMA/EVM подписывает файлы,  а потом перезагружаюсь в рабочий режим apperise в котором IMA/EVM блокирует изменения и проводит проверки. Очень важно понять что это два совершенно разных режима и вам надо для них написать ДВЕ РАЗНЫЕ политики IMA. Одна политика IMA для установки и обновления создающая подписи и совсем другая политика IMA защищающая подписи от изменений, проводящая проверки и блокировки. И мне пришлось править дефолтную политику IMA в ядре Linux чтобы это реализовать. 4. /boot шифрую для скрытия ядра и инитрд, настроек GRUB. Мне надо простое универсальное решение, работающее везде с верификацией загрузки.  Не шифрованым в GRUB есть только core.img
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #189

164. Сообщение от Аноним (164), 27-Июл-24, 13:43	+8 +/–
Они хорошие и этот ключ оставили чтобы вы свой core.img от GRUB подписали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #233

165. Сообщение от Аноним (-), 27-Июл-24, 14:28	+/–
> 1. Купив проц и мамку раздельно пользователь будет иметь возможность добавить СВОЙ > ЛИЧНЫЙ публичный ключ Intel Boot Guard в ROM область в IntelME, Однако ему никогда не дадут прописать свой МАСТЕР ключ - который ME boot ROM использует для начальной верификации блоба ME. Поэтому вы будете жрать интеловский блоб. Без особой возможности его заменить. На side by side проце. А если вы решите что умная клава и не дадите этот блоб, тогда через полчаса ME boot ROM выклбчит комп по таймауту. Ибо нехрен. > для верификации UEFI (LibreBOOT, CoreBOOT) и СВОИХ ЛИЧНЫХ ключей Secure Boot. > Включенный единожды Intel Boot Guard отключит физически невозможно. Видишь ли, дорогой индеец, верховные божества зарезервировали самый крутой ключ - себе. А ты в _ИХ_ системе сможешь не более чем они тебе милостиво позволят. Как ты будешь верифицировать что там ME boot rom и его blob делает в конкретной железке и конкретной версии - это такой весьма отдельный вопрос. > верификации  СВОЕЙ ноутбучной прошивки UEFI и ключа Микрософт для Secure Boot. СВОЕ оно - только для компании Intel. Ну или AMD. А вы там - в гостях. Ибо самый мощный ключ, внезапно, не ваш. В этом смысле ARM бывают честнее - root ключ secureboot с фабы вообще не вписан бывает, кто пропишет - тот и system owner. Но в x86-64 owner уже прям с фабы жестко заколочен. > GNU/Linux возможна при отключённом Secure Boot. Возможность верификации загрузки системы > с помощью GRUB и Linux IMA/EVM все равно необходимо использовать. Чтобы выглядеть умным индейцем, правильно камлающим ритуалы? > 3. IntelME - закрытый бинарный блоб в котором теоретически могут находится ещё > и ключи Intel, NSA, ... Это закрытый бинарный блоб. Ему нафиг не упали ключи. Он крутится на отдельном процессорном ядре, side by side с вашей ОС, умеет DMA, и если вдруг захочет - может все отменеджить в хвост и в гриву. Сможет ли конкретная версия так, особенно после neutering - ну это такой интересный вопрос. Факт в том что совсем не запускать это - вы таки не сможете, под страхом вырубания компа через полчаса. Есть еще флаги для анб которые якобы-совсем, якобы-отключают. Но самое интересное что вы таки не сможете проверить что именно бутром ME конрктетной ревизии делал так по простому. Потому что x86 он вообще недоступен. Боги дивут в отдельном измерении. Оттуда они могут управлять смертными, но вот смертным их не видно. Это привилегии богов :).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #175, #192

166. Сообщение от Аноним (-), 27-Июл-24, 14:31	+/–
> 2. действительно. в памяти почему-то отложилось, что корень от интел Настоящий корень - ключ ME boot ROM - и правда от Intel. Он с самого начала с фабрики прописан в фьюзы, и индеец ни при каком раскладе не сможет свой, доверяемый софт в ME протолкать. И обречен жить с блобом в ME подписаным интелом. А бутгад - это типа 9 фуфлоколец гномам, так, вторичные ключи и вспомогаловка. Можно раздать индейцам для иллюзии контроля. Ведь имея доступ в ME - остальное уже не важно! Это самый привилегированый компонент системы. Настолько что x86 вообще его кишки не видит - а вот наоборот очень даже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #173, #188

167. Сообщение от Kuromi (ok), 27-Июл-24, 14:42	+/–
>> Ну до пустим вы выкрали диск > Зачем мне чего-то красть?)) Если будет очень надо, я просто возьму владельца > диска и вежливо спрошу, что на нём находится. Сам жёсткий диск > мне для этого не нужен. Причём спрашивать сначала буду действительно вежливо > - далеко не всегда нужно человека резать на куски, чтобы он > рассказал всё, что знает. Обычно достаточно просто продемонстрировать, что ты можешь > и готов это сделать. А на диске - снимки обратной стороны Луны, на которых видны вкрапления ледников (ну гипотетически) ну или что-то такое, может быть бухгалтерия Обамы. На допросе вы конечно скажете что там примерно содержится, но не карту же вы по памяти рисовать будете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #171

168. Сообщение от Kuromi (ok), 27-Июл-24, 14:45	+/–
> еще большее веселье наинается когда у пользователя запоминаемая часть в голове, а > незапоминаемая - в tpm. > у меня так, по крайней мере А это обычная история, "я зашифровал диск по туториалу", а теперь чет нихрена не работает, плиз хелп, резервных копий нет, ключи похерены. Смысл TPM же что вашь пароль к нему - это пароль к "аппаратной связке ключей". Вот только связка эта сама опорожняется порой. А вообще, если у вас LUKS то можно FIDO2 попробовать, в свежих версиях это работает, хотя и не без неудобств. А можно и в pkcs11 держать ключик, тоже работает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #178

169. Сообщение от Kuromi (ok), 27-Июл-24, 14:50	+1 +/–
> иначе никак, собственно. > бэкапы ключей из tpm делаются в пару команд и никто не мешает > залить их на флешку и хранить дома. > в конце концов, может и диск из строя выйти, это цена хранения > данных в цифровом виде. > продукцию этих самых "некоторых производителей" можно и не покупать, лол. "некоторые производители" > могут Вам и устройство бракованное дать, что с того-то? Вот только бекапы ключей вам надо где-то хранить, причем секурно, а "флешка с файликом" по умолчанию уже не так секурно. С условным LUKSом могут быть варианты, там все таки разные способы анлока есть, но тогда зачем возня с TPM?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #184

170. Сообщение от Аноним (-), 27-Июл-24, 14:55	+/–
> Так весь смысл SecureBoot в защите от физических атак. Не хочу вас расстраивать - но эта проблема не имеет эффеквтивного решения. Просто подумайте о том что например шина RAM доступна атакующему - и он может попытаться сбить чтение битика в нужный момент, радикально изменив смысл кода (например инвертнуть условие какой-нить проверки). Постоянно верифицировать код в рантайме вы не сможете - постоянно хешировать код, сверяя с хешами, что он не изменился - слишком дорогая операция в рантайм. А даже если - есть окно возможностей, пока проверки еще не заметили подмену, потому что это не мгновенно. И вот тут атакуюший всегда может взять свое. Это можно сделать относительно канительно, но полного решения эта проблема не имеет. Мелкие вещи типа МК и смарткарт в этом чуть лучше т.к. вся память внутри чипа и вот эти шины уже атакующему почти недоступны. Но даже так - варианты есть. > Он сам по себе должен защищать от незаметной для владельца подмены загрузчика. А в > связке с TPM должны защищать от добычи данных с украденного устройства. > Со вторым сценарием как раз таки и не справляется. В основном оно защищает от "софтварных" атак когда софт попытался нахрапом заменить загрузчик через баг. Если это именно физический доступ к системе - оно не удержится при серьезном настрое атакующего. Потому что можно например пройти все проверки хешей но потом все равно сбить код в памяти на иной, делающий что надо - цепочка secureboot как бы пройдена, но как бы толку от этого немного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

171. Сообщение от ProfessorNavigator (ok), 27-Июл-24, 15:10	+/–
> А на диске - снимки обратной стороны Луны, на которых видны вкрапления > ледников (ну гипотетически) ну или что-то такое, может быть бухгалтерия Обамы. > На допросе вы конечно скажете что там примерно содержится, но не > карту же вы по памяти рисовать будете? А зачем мне вся карта или вся бухгалтерия Обамы? Обычно требуется нечто вполне конкретное. Например места расположения условных баз или номера условных левых счетов и способы доступа к ним. Такое человек расскажет вам по памяти легко. Вы даже не представляете, что вы помните и что из вас при должной стимуляции можно достать. Как-то по работе потребовалось по дням восстановить в какие дни в прошлом месяце был дождь, а в какие нет. И в какое конкретно время. И, знаете, вчетвером головы почесали и таки вспомнили. Отвязались от значимых событий, которые каждый помнил, а дальше по ассоциациям всё восстановили. Да и с картой тоже возможны варианты. Вы удивитесь, но достаточно долго например на море картами особо не пользовались - они шли больше как вспомогательный материал, чтобы представлять общую картину. А главной ценностью были самописные лоции, где хранились сведения вида "после мыса N повернуть на север-северо-восток и так держать три дня, после чего появится побережье острова M, где можно набрать пресной воды и есть дичь для пропитания". И с рисованием карты целиком тоже возможны варианты - это я вам как профессиональный штурман говорю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #174

172. Сообщение от Аноним (172), 27-Июл-24, 15:19	+/–
Вот ты приколист конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

173. Сообщение от Аноним (173), 27-Июл-24, 15:21	+/–
> Настоящий корень - ключ ME boot ROM - и правда от Intel. Да скажем правду - секретный ключ от IntelME есть в майора с АНБ. > А бутгад - это типа 9 фуфлоколец гномам, так, вторичные ключи и вспомогаловка. Он ОЧЕНЬ много даёт пользователю компа: 1. Физически неизменяем, никакой Васян не сможет его изменить. 2. Проверка UEFI и Secure Boot с помощью вашего ключа становится не отключаемой. Никакой производитель не сможет сменить прошивки UEFI и добавить ключ Secure Boot от M$. 3. У нас нет выбора. В DNS за углом Эльбрусу без IntelME пока не продают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #194

174. Сообщение от Kuromi (ok), 27-Июл-24, 15:40	+/–
>[оверквотинг удален] > вчетвером головы почесали и таки вспомнили. Отвязались от значимых событий, которые > каждый помнил, а дальше по ассоциациям всё восстановили. > Да и с картой тоже возможны варианты. Вы удивитесь, но достаточно долго > например на море картами особо не пользовались - они шли больше > как вспомогательный материал, чтобы представлять общую картину. А главной ценностью были > самописные лоции, где хранились сведения вида "после мыса N повернуть на > север-северо-восток и так держать три дня, после чего появится побережье острова > M, где можно набрать пресной воды и есть дичь для пропитания". > И с рисованием карты целиком тоже возможны варианты - это я вам > как профессиональный штурман говорю. Ну вы уже, отчасти, придираетесь по мелочам. Да в каких-то случаях вам может быть нужна одна строчка из базы, или достаточно одного ориентира (что кстати совсем не вариант для условной точки в условном  Море Спокойствия, где зондирование показало что-то под поверхностью, ткнете пальцем - ошибетесь на многие сотни километров в лучшем случае). Может быть вам нужна ВСЯ база данных, в доказательных целях, скажем, может быть это исходный код нового ИИ и "ой, ну ты тот потеряли чутка" - не приемлемо. Залатаете код Скайнет абы как - он вас первого и взорвет, вот так ирония Может быть это последнее фото ненайденного шедевра да Винчи и лишь часть произведения вас не утраивает (Мона Лиза без лица, тут я уже утрирую, да). Вариантов, однако - достаточно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171 Ответы: #177

175. Сообщение от Аноним (173), 27-Июл-24, 15:52	+/–
> А если вы решите что умная клава и не дадите этот блоб, тогда через полчаса ME boot ROM выклбчит комп по таймауту. Ибо нехрен. > СВОЕ оно - только для компании Intel. Ну или AMD. А вы там - в гостях. Ибо самый мощный ключ, внезапно, не ваш. А что делать? Эльбрусу в DNS за углом пока не привезли. > В этом смысле ARM бывают честнее - root ключ secureboot с фабы вообще не вписан бывает, кто пропишет - тот и system owner. К ARM у меня другие вопросы по безопасности. Отсутствие инструкции NX. Как выделять память только для чтения в режиме исполнения и с запретом исполнения в режиме записи? А что там ковбои с IBM наделали? Как у них Secure Boot в сертифицированном FSF железе: https://www.raptorcs.com/ "Talos™ II drives the state of the art of secure computing forward. Talos™ II gives you — and only you — full control of your machine's security. Rest assured knowing that only your authorized software and firmware are running via POWER9's secure boot features. Don't trust us? Look at the secure boot sources yourself — and modify them as you wish. That's the power of Talos™ II" > > GNU/Linux возможна при отключённом Secure Boot. Возможность верификации загрузки системы с помощью GRUB и Linux IMA/EVM все равно необходимо использовать. > Чтобы выглядеть умным индейцем, правильно камлающим ритуалы? С детства уважаю всех индейцев. Даже лук и стрелы себе был сделал. Но к индейцам никак не отношусь. А верификацию в GRUB и Linux IMA/EVM необходимо делать чтобы всякий Васян не вставил буткит в модуль GRUB, или руткит в ядро, или всякую вирусную в бинари и либы. > Сможет ли конкретная версия так, особенно после neutering - ну это такой интересный вопрос У нас нет альтернатив. Максимум что можем это прописать свой ключ в Intel Boot Guard и аккуратно обрезать IntelME с опцией -s. Позировали 5 шведов зелени на завод в свои времена. Сегодня могли бы RISC-V без блоков клепать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #176, #195

176. Сообщение от Аноним (173), 27-Июл-24, 15:58	+/–
/Позировали 5 шведов/пожидничали 5 лярдов/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

177. Сообщение от ProfessorNavigator (ok), 27-Июл-24, 16:17	+/–
> Ну вы уже, отчасти, придираетесь по мелочам. Да нет, боюсь, что это именно ваш грех)) Впрочем, для полной объективности тут нужен сторонний арбитр. А про тот же ИИ - вам не нужен весь код. Нет, если получится достать, то хорошо конечно. Но в целом - принцип работы конкретного экземпляра можно описать в условных двадцати предложениях. Это я про аппаратную часть. И столько же нужно на описание структуры базы данных, которой данный конкретный экземпляр пользуется. А дальше воссоздать его - дело техники. Причём, тот, кто знает в деталях, как оно всё внутри устроено (я имею ввиду на других аналогичных примерах), может обойтись и меньшим. Специалисту зачастую достаточно пронаблюдать, как ведёт себя изделие на тех или иных примерах, и он вам с достаточно высокой точностью обрисует, как оно всё там внутри устроено. Физика процесса то одна и та же везде. Меняются лишь алгоритмы перебора базы данных, да и то - не принципиально. В целом же любое шифрование служит только одной цели - дать время минимизировать ущерб при случайной утечке данных. Потому что при целенаправленной утечке атакующий в большинстве случаев получает искомое. Ибо чётко знает, что конкретно ищет и как это можно получить. Да и методы прямой атаки редко используются. Если поискать статистику, то станет очевидным, что в большинстве случаев причина утечек - человеческий фактор. Причём вовсе без членовредительства, а лишь по банальной человеческой жадности. Небольшая сумма денег, и условная база клиентов банка уже у вас в кармане.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #238

178. Сообщение от мяв (?), 27-Июл-24, 16:18	+/–
я не про пин tpm'а, а про кусок пароля диска. полностью ему диск доверять как то страшно. и да, бэкапы есть, в том числе, ключей из tpm. что до аппаратных ключей.. в чем отличие, кроме того, что я их с большим шансом посею? фактически, они тоже ломаются и тоже могут выйти из строя, только вот tpm  у меня в ноуте уже был, а это еще покупать нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #190

179. Сообщение от нах. (?), 27-Июл-24, 16:19	+2 +/–
вообще-то оно РЕЗКО, на два порядка, усложнило написание примитивных бут-вирусов, доступных раньше каждому васяну. Причем если раньше васяны хотя бы в бутсектор не всегда попадали или не помещались, надо было хоть ассемблер знать, то сейчас, когда uefi исполнит любой PEшник... хоть на хрусте пиши, хоть на gwbasic. И сфейлилось в общем-то не технически а на человеческом факторе - обезьянки с воплями "шва60дки лишаютъ!" добились таки от MS что та понаподписывала совсем невменяемой чертовщины. Ну а нынешняя история - просто вишенкой на тортике.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #197, #211, #235

180. Сообщение от мяв (?), 27-Июл-24, 16:21	+/–
госпади, хотите - спросите. я лишь ткнула в то, что многие возможностями своей материнки пользуются не на полную, а некоторые вовсе живут в иллюзии, думая, что sb с ключами от мс - это гарантия защиты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #187

181. Сообщение от нах. (?), 27-Июл-24, 16:21	+/–
тебе ж вон там вадик на две страницы разжевал - что shim не позволяет без твоего явного участия исполнить что-то неподписанное. Во всяком случае - обычный, а не от ФСБ/AVP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137

182. Сообщение от мяв (?), 27-Июл-24, 16:23	+/–
ну и, на последок почитайте, что такое evil maid, сильно удивитесь. ps пользователь Вам сам пароль даст, ничего не подозревая и думая, что он в безопасности, раз у него секурбут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159

183. Сообщение от Аноним (183), 27-Июл-24, 16:25	+/–
Миллионы глаз смотрели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

184. Сообщение от мяв (?), 27-Июл-24, 16:27	+/–
диск с бэкапом я храню дома и пароль записан на бумажке такой, который я сама запомнить не в состоянии. для ноута такой не поставишь, ибо часто включаю/выключаю, придется бумажку с собой носить, либо полагаться на память.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #191, #208

185. Сообщение от нах. (?), 27-Июл-24, 16:28	+/–
с чего это вдруг? x86ые маки не сняты с поддержки, bootcamp где лежал там и лежит. А M1/M2 не поддерживаются..не эплом, в общем. Фиг знает за что корпорация на них так зла, что имея (почти) готовый код не хочет продать (с другой стороны - а что на нем запускать-то кроме калькулятора?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

186. Сообщение от Аноним (186), 27-Июл-24, 16:35	+/–
> на кой вообще в цепи гроб Редхат скоро от груба избавится. Всё будет в efi-файле.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #196, #217

187. Сообщение от ProfessorNavigator (ok), 27-Июл-24, 16:47	+/–
> госпади, хотите - спросите. > я лишь ткнула в то, что многие возможностями своей материнки пользуются не > на полную, а некоторые вовсе живут в иллюзии, думая, что sb > с ключами от мс - это гарантия защиты. Так и я в общем-то о том же)) Просто я вам пытаюсь донести, что гарантий вообще не существует. Если кому-то ну о-очень нужна информация, то он её получит. И для этого вовсе необязательно сильно заморачиваться с высокотехнологичными способами. Что тысячу лет назад, что сегодня всё завязано на человека. Поэтому опять же что тысячу лет назад, что сегодня самый простой и быстрый способ получения информации - "тряхнуть" её владельца. Правильный же подход к безопасности: 1) обеспечить своевременное обнаружение утечек данных 2) сосредоточиться больше не на методах защиты информации, а на разработке плана действий в случае, когда утечка уже произошла. И работа с людьми. Мотивировать правильно нужно сотрудников, тогда и утечек не будет. Но это уже совсем другая тема.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180

188. Сообщение от мяв (?), 27-Июл-24, 16:59	+/–
а, ну вот. в любом случае, неплохая защита. ни Вам, ни мне явно дело с анб иметь не придется. максимум - участковый дядя Гриша и условный отдел к, которым силенок и не хватит. особенно, учитывая, что интел из рф ушел, да настолько, что даже доки почитать не дает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

189. Сообщение от мяв (?), 27-Июл-24, 17:07	+/–
3. прикольно. возможно, будет попытка номер 2, но не на десктопе. ибо я как то решила, что оно мне не надо, т.к  уже iBG -> sb,tpm+пароль(не пин, а кусок пароля люкса) -> luks -> tomoyo linux(с политикой на всю систему) -> LKRG.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

190. Сообщение от Kuromi (ok), 27-Июл-24, 17:45	+/–
> я не про пин tpm'а, а про кусок пароля диска. полностью ему > диск доверять как то страшно. > и да, бэкапы есть, в том числе, ключей из tpm. > что до аппаратных ключей.. в чем отличие, кроме того, что я их > с большим шансом посею? фактически, они тоже ломаются и тоже могут > выйти из строя, только вот tpm  у меня в ноуте > уже был, а это еще покупать нужно. Ну если переломить пополам - сломается, а так задуман быть прочным. Можно ли потерять - конечно, с другой стороны - не впаян в ноутбук. Что до покупать нужно - на самом деле найти можно достаточно недорого, спасибо параллельному импорту и Авито (лол).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

191. Сообщение от Kuromi (ok), 27-Июл-24, 17:46	+/–
> диск с бэкапом я храню дома и пароль записан на бумажке такой, > который я сама запомнить не в состоянии. > для ноута такой не поставишь, ибо часто включаю/выключаю, придется бумажку с собой > носить, либо полагаться на память. Вскрыть дверь, унести диск с бумажкой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184

192. Сообщение от Аноним (192), 27-Июл-24, 18:33	+/–
> Видишь ли, дорогой индеец, верховные божества зарезервировали самый крутой ключ - себе. А ты в _ИХ_ системе сможешь не более чем они тебе милостиво позволят. Дорогой индеец здесь ты, потому что как индейцы предлагаешь сидеть и ничего не делать, под предлогом, что блоб IntelME выковырять полностью не удается. В любом дистрибутиве GNU/Linux можно значительно повысить безопасность настроив верификацию процесса загрузки в GRUB и Linux IMA/EVM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165

193. Сообщение от YetAnotherOnanym (ok), 27-Июл-24, 19:17	+/–
Когда загремишь в больничку и протестируешь на себе сделанную сейчас полезную продукцию - отпишись о впечатлениях. Если сможешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #237

194. Сообщение от Аноним (-), 27-Июл-24, 19:44	+/–
>> Настоящий корень - ключ ME boot ROM - и правда от Intel. > Да скажем правду - секретный ключ от IntelME есть в майора с АНБ. Как минимум он есть у "богов" из интеля. Кому и на каких условиях они это дают - и что еще им подписано - неизвестно. Это означает что сколь-нибудь доказуемой и ожидаемой безопасности с таким раскладом не видать. То-есть можно сформировать себе ложные ожидания. И потом залететь на это при случае. А вот именно гарантий - в этой схеме по нулям. Утечет эта пакость или что-то ей подписаное у интеля или кого там - и упс, вся схема бита. >> А бутгад - это типа 9 фуфлоколец гномам, так, вторичные ключи и вспомогаловка. > Он ОЧЕНЬ много даёт пользователю компа: > 1. Физически неизменяем, никакой Васян не сможет его изменить. У меча две стороны... 1) Легитимный пользователь его тоже не сможет потом перешить. Даже если про@#$л, или он оказался несекурный, или что там еще. 2) Если пользователь утратил приватную часть нужного ключа - он немного в з@днице. 3) Любые ошибки при программировании eFuse - фатальны. 4) Зачастую это уже прописано без пользователя, и вот совсем уж ой. > 2. Проверка UEFI и Secure Boot с помощью вашего ключа становится не > отключаемой. Никакой производитель не сможет сменить прошивки UEFI и добавить ключ > Secure Boot от M$. И это круто - потому что что? За вами бегала толпа производителей, пытаясь отжать самопальный комп и прописать в него свои ключи? Очень странная модель угроз, я бы сказал. С точки зрения пользователя это либо вестма рисковая в програмировании фича с 1 стороны (у вас же нет склада железа на убой для отладки/проверки?) - либо оно вообще уже прописано более массовыми, которые отладились, и оно против пользователя играет. > 3. У нас нет выбора. В DNS за углом Эльбрусу без IntelME пока не продают. 1) Я могу купить ARM какойнить с ванильными фьюзами. И там по крайней мере это реально топовая ауторити. Но это смотреть надо кто как секурбут делает, варианты разные бывают. 2) Есть способ лучше. Загрузчик - коему прописан некий ключ владельца - кладется на read only media. Ну там SPI флеха с WP#, SD карта которую в загнали в readonly, или что там уместно в энной системе. Актуально для систем чей бутром умет с таких носителей стартить (ARM/RISCV). Это гугл придумал - хотя идея очевидная. Если ну вот очень приперло - readonly загрузчика вот там все же можно физическими манипуляциями оверрайднуть. Но софт это сделать сам по себе не сможет - в чем смысл и состоит. Против вот именно физического доступа это фуфло не удержится. В здоровенном x86-64 более 9000 векторов атак. Включая весьма универсальные типа power/clock glitching или рантайм патчинга кода сбоем на шине например DRAM в нужный момент. Если уж доступ - физический.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #214

195. Сообщение от Аноним (195), 27-Июл-24, 20:03	+/–
> А что делать? Эльбрусу в DNS за углом пока не привезли. Это не является валидным аргументом в безопасности компьютерных систем. Да и даже если привезут - у них что, открытый системный уровень? Да там даже компилер проприетарный, поди проверь что он там нагенерил и почему. > К ARM у меня другие вопросы по безопасности. Отсутствие инструкции NX. А зачем для этого вообще какие-то инструкции? А, потому что у x86 урода изначально вообще не было запрета выполнения как категории? Ну так это его родовые костыли, странно другим в претензию это ставить :) А у ARMов и прочих более новых дизайнов - MMU сразу с правами R, W и X на страницы. И вот тут - если X не разрешен, вы и пролетаете с выполнением кода оттуда. > Как выделять память только для чтения в режиме исполнения и с запретом > исполнения в режиме записи? Правами страниц через MMU, внезапно. А вы что подумали? Такой набор правил в целом даже характерное название "W^X" получил. Нормально такое через MMU ессно делается. > А что там ковбои с IBM наделали? Я никогда не имел дел с этим железом. Но имею неплохое представление как сделать относительно мелкие "апликушные" ARM  вполне секурными. Кстати даже для TrustZone так то есть открытый ARM trusted firmware, в отличие от tianocore открытость менее фэйковая. >> Чтобы выглядеть умным индейцем, правильно камлающим ритуалы? > С детства уважаю всех индейцев. Даже лук и стрелы себе был сделал. > Но к индейцам никак не отношусь. Ну тогда присоединяйтесь к раздаче одеял "нашару". Хотя не, шара не в моде - клевые одеяла от доброго человека еще и оплатить теперь придется :) > А верификацию в GRUB и Linux IMA/EVM необходимо делать чтобы всякий Васян > не вставил буткит в модуль GRUB, или руткит в ядро, или всякую вирусную в бинари и либы. Тут скорее актуально "чтобы самоходное ПО от Васяна это не сделало". При такой постановке вопроса это еще понимаемо. А защита x86 гроба от физического доступа - ну, э, лол. От этого даже МК с всей памятью и системой в кристалле может не удержаться. И не то чтоб как-то сильно сложно ведь, примеры power или clock glitching можно найти у исследователей. Никакой ракетной науки. > У нас нет альтернатив. Максимум что можем это прописать свой ключ в > Intel Boot Guard и аккуратно обрезать IntelME с опцией -s. > Позировали 5 шведов зелени на завод в свои времена. Сегодня могли бы > RISC-V без блоков клепать. Не знаю что за шведы - а RISCV уже так то довольно много кто клепает. Да и ARM тоже. Вон там фороникс AWSовкие Graviton затестил - а они даже и EPYC местами делают. Ну а чего 128 ядерному монстру не? Правда, амазон вроде это только as service продает. Почти как Эльбрус :)) но есть нюансы. А в виде железок вроде не, "такая скотина нужна самому!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #215

196. Сообщение от Аноним (-), 27-Июл-24, 20:06	+2 +/–
>> на кой вообще в цепи гроб > Редхат скоро от груба избавится. Всё будет в efi-файле. А потом, когда у вас очередной кернель после апдейта не загрузится, Зоркий Глаз заметит что у сарая нет не только стены - но и подпорок для крыши, так что чего-то его немного этой крышей как раз и зашибло. Вот подстава то :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186 Ответы: #202

197. Сообщение от Аноним (-), 27-Июл-24, 20:10	+/–
> вообще-то оно РЕЗКО, на два порядка, усложнило написание примитивных бут-вирусов, доступных > раньше каждому васяну. А что - Васян настолько ленивый и тупой что shim взять не может? На самом деле просто все вдарились в зарабатывание бабок и оно перешло в вымогатели-винлокеры и прочие шифровальщики еще до всех этих потуг. Ибо зачем возиться с этой гадостью если проще потребовать перевод коинов воооон туда, а нето фиг вам а не ваши данные?! А какое-нибудь NSA с equation с этого цирка ржать будут аки кони, запатчив тебе какую-нить фирмвару накопителя, выдавать сектора с вырусом в четверг високосного года, и попробуй это отлови вообше. Жытаг адаптер ты себе уже купил? Не, менее радикально это вообще хрен заметишь, пожалуй :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #200

198. Сообщение от нах. (?), 27-Июл-24, 20:41	+/–
>>защищает не от этого > именно от этого, от подмены загрузчика со стороны ОС, что можно прекрасно > сделать, блягодаря shim. нет. Вы статью на хабре нашли, прочитали, но так и не поняли? Понадобился не шим, а собственный аналогов не имеющий загрузчик касперского, плюс очень нетривиальный хак к нему, далеко не уровня васяна писавшего бутвирусы, потому что даже этот загрузчик просто так ничего тебе не загрузит. >>что ключи шпион-капитана касперского везде давно заблокированы > Вы статью читали? ключи майкрософта и их все устраивает. софт касперского, как Статья устарела на восемь лет. >> и станет заблокировано > галлюцинировать не надо. ключи майкрософта и ими они подписывают собственные драйвера. квалификация эксперта (этогосайта). Нет, ЭТИМИ ключами microsoft ничего не подписывает кроме васянских шимов. У винды другой ключ. Внезапно, у MS их больше одного. Вот подписали ли они касперскому шим тем же самым или все же пожертвовали отдельный, который и заблокировать недолго - требует выяснения. А драйверы подписаны третьим (потому что его уже не secure boot а ядро винды проверяет) >>фсбшным кротом > ясненько. не стоило отвечать, вероятно. не стоило. Человек потерял огромный бизнес, даже не попытавшись отмазаться - но конечно не крот, никак не крот, это его враги подставили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #218

200. Сообщение от нах. (?), 27-Июл-24, 20:48	+/–
> А что - Васян настолько ленивый и тупой что shim взять не может? shim, внезапно, написан не настолько ленивыми и т-пыми как ты - и не загрузит автоматически  неподписанную васянову поделку, вот так сюрприз. В очередной раз - "квалификация"-c.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197

202. Сообщение от Аноним (202), 27-Июл-24, 20:56	–4 +/–
> А потом, когда у вас очередной кернель после апдейта не загрузится... Значит загрузишься со старого. Что как маленький. :) Я надеюсь, ты сейчас с грубом так делаешь, а не бежишь ось переставлять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

203. Сообщение от Электрон (?), 27-Июл-24, 21:40	+1 +/–
Для этих уже и аббревиатура своя есть: ODM. Суть: после них наклейку нанести и продать с наценкой. Часто с "тех. поддержкой" и сурьёзным маркетингом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

205. Сообщение от Электрон (?), 27-Июл-24, 21:48	–1 +/–
Перечитал еще раз ваше сообщение и понял, что вы не читали Reflections on Trusting Trust Кена Томпсона. Root of Trust идущая от железа - это именно научный подход к устранению этой проблемы (чтобы не придирались: применительно к безопасной загрузке). Простыми словами: evil maid создает зеркало с правильными/измененными файлами. Все хэши в первый раз сходятся. А при исполнении кода грузится другой сектор. Или проще. Прошитый непонятно куда вредоносный драйвер UEFI. Удачи в вычислениях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #222

206. Сообщение от Аноним (-), 27-Июл-24, 21:53	+1 +/–
> во-первых, Вам стоит на на опеннете об этом писать, а производителю с > требованием возврата средств. Тем не менее, железо иногда ломается. И если мамка/проц внезапно станут тыквой - у вас на этот случай был хитрый план как вообще данные с вашего веника вынимать? Или таки - пробурчать "не очень то и хотелось" и форматнуть заново?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135

207. Сообщение от Электрон (?), 27-Июл-24, 22:02	–1 +/–
evil maid для uefi или Intel ME потенциально отсылают по сети что угодно. Но для бытовых случаев хватит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

208. Сообщение от Аноним (-), 27-Июл-24, 22:02	+/–
> диск с бэкапом я храню дома и пароль записан на бумажке такой, > который я сама запомнить не в состоянии. Поэтому имеет смысл юзать пароли которые запомнить все же в состоянии. См пример про "correct battery staple horse" :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184

209. Сообщение от Аноним (209), 27-Июл-24, 22:03	+3 +/–
Думаете, этот "secure boot" хоть сколько-нибудь нужен производителям материнских плат? Думаете, этот самы "secure boot" зачем-то нужен пользователям этих материнских плат? Нет, вся эта хрень нужна только копирастам. Поэтому, разумеется, производитель материнской платы делает строгий минимум, необходимый, чтобы его материнка была помечена как "совместимая" и "поддерживающая" эту хрень. Соответственно, отсюда - минимальный объем тестирования. А криптография - это всегда сложно и дорого. Поэтому - если на неё можно забить, на неё - забьют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

211. Сообщение от Tron is Whistling (?), 27-Июл-24, 22:33	+/–
Да они и нафиг не нужны стали - юзеры ныне такие пошли, что сами сдают свои пароли и данные кредитки по первому "ваш почтовый ящик будет заблокирован, пришлите все свои деньги на счёт X".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #212

212. Сообщение от нах. (?), 27-Июл-24, 23:17	+/–
ну нет, там надо уметь быть убедительным. А бутовые вирусы писали вовсе не ради минутного заработка, а просто развлечения ради. И вот разглядываешь очередной трупик - а там легалайз мариванна, поверх (забыл уже, что там была за дрянь) и сверху near dark (в этом был таймер и он удалял таблицу разделов, поэтому и трупик, а то можно ж было еще кого-то четвертого и пятого намотать в этот же бутерброд) Спасибо мариванне за заботливо сохраненную таблицу в седьмом секторе. Представь до какого п-ца оно бы щас докатилось, если бы любой BOOTX64.efi тут же бы загружался. Ан, нет, тут попердолиться надо (отдельно интересно откуда у эсэсовца Вадика оказался тот касперский... впрочем он в целом небрезглив и внимателен - мне бы и в голову не пришло что там не самый обычный шим и grub - казалось бы, ну нафига?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

213. Сообщение от Изя (?), 28-Июл-24, 05:29	+1 +/–
Почти угадали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

214. Сообщение от Аноним (214), 28-Июл-24, 08:03	+/–
>>> Настоящий корень - ключ ME boot ROM - и правда от Intel. >> Да скажем правду - секретный ключ от IntelME есть в майора с АНБ. > Как минимум он есть у "богов" из интеля. Кому и на каких условиях они это дают - и что еще им подписано - неизвестно. Это означает что сколь-нибудь доказуемой и ожидаемой безопасности с таким раскладом не видать. Интел при производстве чипов засовывает в них целого товарища майора с АНБ, причем живьём! > То-есть можно сформировать себе ложные ожидания. И потом залететь на это при случае. А вот именно гарантий - в этой схеме по нулям. Утечет эта пакость или что-то ей подписаное у интеля или кого там - и упс, вся схема бита. И если товарищ майор АНБ сбежит с чипа интела то может всем рассказать что в IntelME у вас на компе творится. 1. Публичный ключ Intel Boot Guard физически неизменяем. Он есть корнем вашего доверия. Это значит, что прописывать его надо очень аккуратно и приватную часть хранить очень надёжно. Если потеряете приватную часть ключа то обновления UEFI будут невозможны. 2. Проверка UEFI и публичных ключей Secure Boot с помощью вашего ключа становится не отключаемой. Это безответная операция! Она даёт гарантию отсутствия бутктов в вашей UEFI. Да буткит в UEFI могут засунуть и производители прошивки, например ASUS. Буткит в ваш UEFI желают прописать многие, озаботился охраной UEFI стоит каждому пользователю. 3. У нас нет выбора. В DNS за углом Эльбрусы без IntelME пока не продают. Стоит смотреть: Secure Boot в сертифицированном FSF железе: https://www.raptorcs.com/ "Talos™ II drives the state of the art of secure computing forward. Talos™ II gives you — and only you — full control of your machine's security. Rest assured knowing that only your authorized software and firmware are running via POWER9's secure boot features. Don't trust us? Look at the secure boot sources yourself — and modify them as you wish. That's the power of Talos™ II" > В здоровенном x86-64 более 9000 векторов атак. Наличие других векторов атак не значит, что не надо настраивать Integrity.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #225

215. Сообщение от Аноним (214), 28-Июл-24, 08:24	+/–
>> К ARM у меня другие вопросы по безопасности. Отсутствие инструкции NX. > А зачем для этого вообще какие-то инструкции? А, потому что у x86 урода изначально вообще не было запрета выполнения как категории? Ну так это его родовые костыли, странно другим в претензию это ставить :) > А у ARMов и прочих более новых дизайнов - MMU сразу с правами R, W и X на страницы. И вот тут - если X не разрешен, вы и пролетаете с выполнением кода оттуда. >> Как выделять память только для чтения в режиме исполнения и с запретом исполнения в режиме записи? > Правами страниц через MMU, внезапно. А вы что подумали? Такой набор правил в целом даже характерное название "W^X" получил. Нормально такое через MMU ессно делается. Правда в том что ARM память не защищает. Или в Linux не реализована защита памяти на процессорах ARM из-за сложностей этой архитектуры. Жду твоих тестов с ARM: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309 Инструкции NX или PAE нужны: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#250 >> А в виде железок вроде не, "такая скотина нужна самому!" Завод в стране надо свой! Лучше два завода. РФ смогла бы сама сразу клепать свои Эльбрусы и SPARC, а со временем и RISC-V со своим SoC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195 Ответы: #229

217. Сообщение от Аноним (214), 28-Июл-24, 08:33	+/–
UEFI не поддерживает верификацию с шифрованного раздела как умеет GRUB. > Всё будет в efi-файле. Все туда совать не надо. Это шаг назад в безопасности. Ядро и инитрд желательно держать на шифрование разделе. А в efi-файл засунуть минимум: core.img от загрузчика GRUB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186

218. Сообщение от мяв (?), 28-Июл-24, 08:42	+/–
>нет. дат. кончайте троллить. берете shim, берете shell.efi, кидаете в папку на esp, переименовываете в grubx64.efi и шим его загрузит. >устарела поздравляю, теперь идите учитесь смотреть на что-то, кроме циферок. шим как умел грузить левые файла, так и умеет. >квалификация экперта прям с языка сняли. МС ими драйвера сторонних разработчик подписывает. не верите - гугл в зубы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #219

219. Сообщение от нах. (?), 28-Июл-24, 10:24	+/–
> берете shim, берете shell.efi, кидаете в папку на esp, переименовываете в grubx64.efi и шим его > загрузит. дай угадаю - secure boot у тебя - выключен. При попытке загрузить шимом что-то кроме единственноверного grub от rhel (при включеном secure boot  а не просто наличии uefi) - внезапно, вылазит окошко и требует... а хрен поймешь на самом деле чего оно требует (не для юзверей там написано, да и вообще непонятно для кого - ашипка "Ашипка"). Если продраться через неюзерфрендли диалог - оно конечно загрузится (и в следующие разы на твоем локалхосте - и только на нем - ничего уже не переспросит). Но тебе двадцать раз придется ткнуть в "OK", лично, с консольки. И никак эту проверку не обойти - все три штуки правильных с точки зрения Secure boot загрузчика - внезапно, подписаны сертификатом, намертво вшитым в shim. shim подписан сертификатом ms, переподписать самому с сертификатом от васяна не получится. А твои фантазии - просто от того что у тебя есть uefi (и следовательно - shim), но ты не пыталось включить secure boot примерно никогда. Впрочем я понятия не имею что у тебя там за shell.efi - у меня вон в половину серверов такой встроен в uefi, и он, естественно, подписанный и загружается (и шим не нужен). Только им снова ничего нельзя загрузить кроме подписанных модулей, если он обнаруживает что secure boot включен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218 Ответы: #220

220. Сообщение от Аноним (-), 28-Июл-24, 11:07	+/–
Так, для особо умных, намекаю: 1) В grub было парочку фееричных багов, позволяющих кому попало грузить что угодно, чтоб такие как ты безопасТники не скучали. 2) Ключами майкрософт подписано столько всего интересного - что даже это нафиг не надо. Достаточно посмотреть какое-нибудь изучение чем пользуется малварь. 3) А когда профакапился макйрософт они объяснили что отзывать ключ не будут, это же винда грузииться перестанет! Как можно! И хрен с ними, с вирусами...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #219 Ответы: #223

222. Сообщение от Аноним (222), 28-Июл-24, 11:53	+/–
> Root of Trust идущая от железа - это Новость перечитай теперь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205 Ответы: #236

223. Сообщение от нах. (?), 28-Июл-24, 11:59	+/–
> Так, для особо умных, намекаю: > 1) В grub было парочку фееричных багов, было (ms небось все локти искусала что повелась на вопли шва60дкофанов), но они, как ты правильно выражаешься - специфичны. Требовали несколько странных конфигов и физического доступа к хосту. А зачем нам тогда вообще вся возня, доступ-то уже есть. Нет, васян с тремя классами образования - вообще ничего не сможет. Ты скорее всего тоже не осилишь, мало умения читать опеннет. Кто-то конечно сможет, но неуловимые джо ему вряд ли нужны. Т.е. минимальный уровень защиты технология даже в таком виде все еще обеспечивает. Ключами microsoft действительно понаподписывали...всякого, драйвер от васянов загружающий через доступный апи любой исполняемый код например. Но опять же - не васян сможет этим воспользоваться, далеко не васян. Т.е. количество могущих и умеющих действительно в десятки если не сотни раз поубавили. Это тебе не AWARD_SW
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #220

224. Сообщение от Аноним (224), 28-Июл-24, 12:15	+/–
В одной на ресурсы назначаются пользователи. Открываешь ресурс, и сразу видно, кто к нему имеет доступ. В иной пользователю назначаются ресурсы. Это один из интересующих примеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

225. Сообщение от Аноним (-), 28-Июл-24, 12:19	+/–
> причем живьём! Накаркаете. > И если товарищ майор АНБ сбежит с чипа интела то может всем > рассказать что в IntelME у вас на компе творится. Название Management Engine намекает что оно создано МЕНЕДЖИТЬ КОМП. Умея все, от включения и заканчивая реинсталом оси, ремотно в полной версии задумки ;) > 1. Публичный ключ Intel Boot Guard физически неизменяем. Он есть корнем вашего доверия. Причин доверять такой системе - нет. Потому что интел и неопределенный кругом лиц и подписаного софта - могут обойти это сбоку, через ключ ME и софт на самом привилегированом проце системы. У ME привилегий больше чем у x86 ядер. Они вас - видят, а вы их - нет. Это надежный детектор. Когда кто-то косплеит бога, 1 из 1х вещей приходящих в голову - жить в отдельном измерении, где богов не видно смертным. В обратную сторону, конечно, влиять могут. Характерный паттерн, при первом намеке на это - вся схема как на ладони. > Это значит, что прописывать его надо очень аккуратно и приватную часть хранить > очень надёжно. Если потеряете приватную часть ключа то обновления UEFI будут невозможны. А еще это значит что с вот этим процом у вас 1 выстрел. И если что не так - ну, вы меняете проц. Примерно такая же проблема есть с ARM, но там такие эксперименты дешевле :) > 2. Проверка UEFI и публичных ключей Secure Boot с помощью вашего ключа > становится не отключаемой. Это безответная операция! Спасибо капитан очевидность. Но это бусы для индейцев. Формальная декларация. Ибо есть еще проц ME с отдельным ключом. Более мощный по правам. И индейцев туда вообще пускать не собираются. У вас нет контроля над платформой, вы - в гостях. Кольца - фуфло, типа того что гномам раздали. > Она даёт гарантию отсутствия бутктов в вашей UEFI. Да буткит в UEFI могут > засунуть и производители прошивки, например ASUS. Буткит в ваш UEFI желают > прописать многие, озаботился охраной UEFI стоит каждому пользователю. Никаких реальных гарантий чего либо это не дает, ессно. Потому что настоящий root of trust зарезервирован Intel (и AMD) для себя. С самыми мощными привилегиями в платформе. Какая неожиданность. ФакЪ, вам даже нормальный дебаг - не дадут, и не скажут как реально врубить platform level debug. Но если индеец любопытный, найдет некоторые подробности у позитивов. Только это - индейцы-повстанцы, а никак и не официалы вовсе. Ну такая вот "доверяемая" платфрма вырисовывается. Где все на дуле пистолета, "доверяй, а нето грузиться не будем". > 3. У нас нет выбора. В DNS за углом Эльбрусы без IntelME пока не продают. Это, несомненно, забойный аргумент за безопасность платформы и доверие к ней. > Стоит смотреть: > Secure Boot в сертифицированном FSF железе: https://www.raptorcs.com/ Ну как бы ваша платформа или нет - определяется прежде всего доступом к наивысшему уровню привилегий. Имея этот доступ - можно остальных своим софтом оттуда выпереть, сделав им достаточно неудобно как минимуму, особенно при ремотном/софтварном доступе. А если индейцу отдают на откуп менее привилегированый проц, совсем не пустив в более привилегированый...  больно уж характерный паттерн. Ни в раз не уникальный для интела и амд. >> В здоровенном x86-64 более 9000 векторов атак. > Наличие других векторов атак не значит, что не надо настраивать Integrity. Если некто защищается от именно ФИЗИЧЕСКОГО ДОСТУПА, странно перекрыть 10 векторов из более 9000 а на остальные - забить. Если бы они сказали что - от софта пытающегося флешить в фирмвари левак, это другой вопрос уже был бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #214

226. Сообщение от Аноним (226), 28-Июл-24, 12:43	+/–
EFI без U вполне себе торт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

227. Сообщение от Аноним (226), 28-Июл-24, 12:45	+/–
Я свой худший враг. Так что все очевидно!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

228. Сообщение от Аноним (228), 28-Июл-24, 13:55	+/–
> Этот производитель всегда славился наплевательским подходом в разработке bios для своих продуктов. А у какого прозводителя ненаплевательский подход?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

229. Сообщение от Аноним (-), 28-Июл-24, 14:26	+/–
> Правда в том что ARM память не защищает. Или в Linux не > реализована защита памяти на процессорах ARM из-за сложностей этой архитектуры. Это откуда такая "правда"? Тот же линух (ядро) прекрасно маркирует свои куски non exec, и соотв сегменты программ. Правами MMU ессно. > Жду твоих тестов с ARM: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#309 Ну найди мне 10 отличий amd64 от armhf - на одном и том же Debian 12? На обоих paxtest kiddie ессно. И было это как-то так: Debian 12/armhf (32 bit): Test results: Executable anonymous mapping             : Killed Executable bss                           : Killed Executable data                          : Killed Executable heap                          : Killed Executable stack                         : Killed Executable shared library bss            : Killed Executable shared library data           : Killed Executable anonymous mapping (mprotect)  : Vulnerable Executable bss (mprotect)                : Vulnerable Executable data (mprotect)               : Vulnerable Executable heap (mprotect)               : Vulnerable Executable stack (mprotect)              : Vulnerable Executable shared library bss (mprotect) : Vulnerable Executable shared library data (mprotect): Vulnerable Writable text segments                   : Vulnerable Debian 12/amd64: Test results: Executable anonymous mapping             : Killed Executable bss                           : Killed Executable data                          : Killed Executable heap                          : Killed Executable stack                         : Killed Executable shared library bss            : Killed Executable shared library data           : Killed Executable anonymous mapping (mprotect)  : Vulnerable Executable bss (mprotect)                : Vulnerable Executable data (mprotect)               : Vulnerable Executable heap (mprotect)               : Vulnerable Executable stack (mprotect)              : Vulnerable Executable shared library bss (mprotect) : Vulnerable Executable shared library data (mprotect): Vulnerable Writable text segments                   : Vulnerable И они отличаются - например чем? (да, это не тот хeнтaй, извраты с mprotect не заткнуты). Но вон то намекает что права mmu работают. > Инструкции NX или PAE нужны: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#250 Это что, ссылка на сам себя как на авторитетный источник? Эти инструкции актуальны только лохматым 32 bit x86 какахам, не умевшим non-executable маркировку памяти по первости. Остальные выводы сделали, их MMU с самого начала умеют r/w/x права. По каким правилам ОС в конкретной инкарнации эти правила выставляет - вопрос номер два. >>> А в виде железок вроде не, "такая скотина нужна самому!" > Завод в стране надо свой! Лучше два завода. РФ смогла бы сама > сразу клепать свои Эльбрусы и SPARC, а со временем и RISC-V > со своим SoC. Да мало ли кому что надо. Вы представляете себе размер этого стека технологий? Ни 1 страна в мире ВСЕ комплектующие, расходники и проч для этого не производит самостоятельно. Что хотите с этим то и делайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215 Ответы: #240

233. Сообщение от Аноним (-), 28-Июл-24, 16:06	+1 +/–
> Они хорошие и этот ключ оставили чтобы вы свой core.img от GRUB подписали. Да, и AWARD_SW вон те тоже сделали чтобы мне удобнее было в чужой BIOS заходить и менять столь вредным админам их пароль на BIOS. И ведь хрен поспоришь - удобно же!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #253

234. Сообщение от Аноним (235), 28-Июл-24, 19:35	+/–
Ну наконец-то у меня неподписанный syslinux-efi на hp elitebook g7 не будет вешать загрузку на десять минут.
Ответить | Правка | Наверх | Cообщить модератору

235. Сообщение от Аноним (235), 28-Июл-24, 19:45	+/–
Секурбут для людей можно сделать одной восьминогой микросхемой и перемычкой, разрешающей писать на эту микросхему и грузиться с неё. А то, что у нас сейчас - это секурбут ОТ людей, когда на какие-то планшеты слаку поставить можно только выдрав загрузчик и ядра из убунты, а на некоторые - вообще никак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #261

236. Сообщение от Электрон (?), 28-Июл-24, 22:53	+/–
Новость - брешь в реализации Secureboot (который в исполнении производителей ради ограничения пользователей я нисколько не оправдываю). А livecd поверх потенциально скомпрометированной системы - это by design. На первом шагу возможен дамп livecd для последующего pwnage. Первое будут исправлять, а это нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222

237. Сообщение от Аноним (-), 29-Июл-24, 00:06	+/–
> Когда загремишь в больничку и протестируешь на себе сделанную сейчас полезную продукцию > - отпишись о впечатлениях. Если сможешь. Намного лучше попасть в больничку где вот те бинт, вот те зеленка - а больше мы вообще нихрена не разработали. Какие тебе еще нафиг томографы?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #260

238. Сообщение от Аноним (-), 29-Июл-24, 02:31	+/–
> В целом же любое шифрование служит только одной цели - дать время > минимизировать ущерб при случайной утечке данных. Ну не, почему. Иногда помогает. Если некто нашел "холодный" диск/вырубленый ноут/комп и проч - и не можете поспрашивать в убедительном виде что и кто - крипто свое дело сделало. А если начинается вон то, про физический доступ... как это на практике будут гасить, если оно кому-то надо? Не, никто не будет возиться с TPM, i2c шиной и какой там еще порнографией. Скорее закинут троянец через многочисленные дыры в браузере или чем там у вас. Эскалируют права через многочисленные CVE (вы их все точно патчили в темпе вальса и ребутались как зайцы?). Дальше... а что это у нас тут? А, диск? Уже смонтированый, со всеми ключами, по фэншую?! Во, видите, вы сами все ввели. И никакой академической гребли. Если это обычный пользак, и не предпринял никаких мер - его наиболее ценные данные сделают фьють по сети в пользу атакующего. ЧСХ это до некторой степени полезно даже если эскалация не прокатила, ведь если интересный юзер имел доступ, то и левый код/скприпт под ним - тоже это все сможет! Если атакующий эстет, он после эскалации может попытаться стырить бонусом из "физической" памяти ключ которым шифрованый диск реально шифруется, а не то что там в TPM. Чтобы шифровать и расшифровывать, ОС должна знать этот ключ. Значит он в памяти - есть. И его можно умыкнуть. И так можно вообще все оптом расшифровать и даже потом, если оно зачем-то кому-то надо. Я примерно так себе аннулировал шифрование профайла Tox, когда пароль на него забыл. Крякать ЭТО? Ух не, там Argon, чтоли, считает долго, брутфорсить помрешь нахрен. Но если есть права бога (а у меня в отношении VM они конечно же есть вон оттуда) - дампануть RAM вполне опция. И вот он, забытый пароль. Не, вынести его из RAM нельзя. А как иначе шифровать тогда?! Есть варианты алго шифрования, где ключи только в регистрах, на которые эта магия не работает - но оно медленно и специфично. И потому распостранения не получило. На физической железке можно включить режим ядра Lockdown - тогда даже рут не сможет копаться в физической оперативке по простому. Но сколько хомячков так делает? Правильно - немного. Поэтому отлично сработает после эскалации (для которой CVE - хватает). Если кто не понял в чем проблема: атакующие используют самый простой вектор ведущий к достижению цели. Как гласит комикс XKCD, на практике - "вот тебе 5-баксовый разводной ключ, просто дубась им пока не скажет пароль". А вон то в случае если эта опция атакующему недоступна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #245

239. Сообщение от Аноним (226), 29-Июл-24, 04:19	+/–
Это было очевидно с самого начала. Помните, когда оно только появилось, пошли ноуты без возможности отключения сесуре бута? Все взвыли и опцию таки завезли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #248

240. Сообщение от Аноним (240), 29-Июл-24, 08:26	+/–
В дебиане лучше бы реализовали mprotect для всей системы, ядра и приложений. Вот для ARM, RISC-V с реализацией mprotect будут проблемы из-за архитектуры этих процов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229

242. Сообщение от Аноним (253), 29-Июл-24, 09:27	–2 +/–
А, в добавок какой резон заморачиваться когда пароли всёравно - у другого (MS подписанта)... Более, когда на продажу же - заранее даже не пойми кому(вкл.своих скрыто врагов разнообразных, начиная с народа, любого), да и конкурентам, в т.ч.и начиная с MSже. Ну и линуксы и прочее никто не отменял же, их может и мало, %-но у пользователей, зато вони так много что, зачем им это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

243. Сообщение от Аноним (253), 29-Июл-24, 09:46	+/–
> Достаточно посмотреть что например Linux пищет про таблицы ACPI при загрузке. Там баг на баге и багом погоняет. Это скорей всего не баг(и) - а, сознательная вредоносность. Мин.вредоносный маркетинг, направленый на уничтожение самой возможности любых альтернативных ОС и просто совместимости с DOS и всякие UEFI тут были уже ранее. Вредоносность так же как и например с графической VESA2 API в BIOS видеокарт, где и ранее как только не пакостили её(от ограничений кол-ва видеорежимов и вообще так и не начале поддержки WideScreen до порча значений регистров при вызовах) так по ныне с nV 900-йо серсии и выше - вообще уже несколько раз пакостя, например, вообще выпилив функции API в защищённом режиме - что не постандарту в итоге в ч.н.все VESA DOS игры уже вываливаются (правда нек.игроманы сделали свои драйвер(а):] но, альт.ОС на такое паскудство не расчитанные т.е.и все более ранние вообще линуксы в ч.н., котрые заведомо можно запустить уже только на VESA-драйвере, уже собственно даже не запустить... Рука MS? М.б.но не только им это выгодно а и всяким зловредным структурам псевдо-гос. и не очень)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #250

245. Сообщение от ProfessorNavigator (ok), 29-Июл-24, 12:48	+/–
> Ну не, почему. Иногда помогает. Если некто нашел Это и подразумевалось под случайной утечкой. Если вы потеряли флэшку/ноут/что_угодно_с_памятью, то шифрование даст вам некоторый запас времени, чтобы вывести из под удара то, что для вас критически важно. Поменять пароли там, предупредить людей и т.п. Если кому-то очень нужны данные с вашего утерянного устройства, то шифрование не спасёт, а лишь отсрочит их получение. > А если начинается вон то, про физический доступ... Если у атакующего есть физический доступ к железу, то как бы мера защиты тут может быть одна - просверлить жёсткий диск. И то не факт, что поможет - всегда будут те, кто сможет рассказать всё нужное и без всяких жёстких дисков. > Если это обычный пользак, и не предпринял никаких мер - его наиболее > ценные данные сделают фьють по сети в пользу атакующего. С "обычным пользаком" никто из "серьёзных" людей даже заморачиваться не будет. Потому что затраты многократно превысят ценность полученной информации. В крайнем случае, если уж очень надо - прессанут по быстрому. Причём совершенно не обязательно, что с помощью физического воздействия. Достаточно просто человека как следует напугать. А этого можно добиться и просто словами. Или вовсе договорятся за скромное вознаграждение. С "обычными пользаками" заморачиваются обычно (пардон за каламбур) только в одном случае - когда бьют по площадям. В этом случае - да, "не качеством, так количеством доберём". Но тут опять же применяются банально простые методы, вроде звонка с заявлением: "Всё пропало, срочно переведи нам деньги". С ломом кого-то скорее всего будут морочиться, только если нашли дырень, которая есть у +/- 70% пользователей. Тут уж мало кто от искушения удержится. И то, с оговорками. Потому что проблем огрести можно массу, а вот прибыль совсем не гарантирована. > Если кто не понял в чем проблема: атакующие используют самый простой вектор > ведущий к достижению цели. О том и речь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238

248. Сообщение от Kuromi (ok), 29-Июл-24, 14:27	+/–
> Это было очевидно с самого начала. Помните, когда оно только появилось, пошли > ноуты без возможности отключения сесуре бута? Все взвыли и опцию таки > завезли. Ну так не стоило Балмеру и компании так подозрительно хихикать и умиляться. Хитрый план сделать Виндовс единственной ОС которую можно запускать на ПК оказался слишком уж очевиден.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239

250. Сообщение от Аноним (-), 29-Июл-24, 15:30	+/–
> Это скорей всего не баг(и) - а, сознательная вредоносность. Нагамнякать таблицу ACPI - ну даже не знаю. А что оно так то дает? > Мин.вредоносный маркетинг, направленый на уничтожение самой возможности любых альтернативных > ОС и просто совместимости с DOS и всякие UEFI тут были уже ранее. Совместимостью с DOS имхо никто не парится. А так - индусы сами порой от этой рукоджопии и страдают. Не, на самом деле все проще: они тестят этот кус крапа с 1 версией винды, которую планируют преинсталить en masse. Остальное разве что по остаточному принципу и скорей продавать. Получается ессно весьма ожидаемый ужастик от индусов которые вообще не понимали что делали - но с 1 виндой как-то вроде заработало, так что - скорей-быстрей продавать. Все тайванокитайские OEM в этом смысле одинаковые. Что производители мамок, что *-линки. Это копипастеры почти без локальной экспертизы. > видеорежимов и вообще так и не начале поддержки WideScreen до порча > значений регистров при вызовах) Да тоже небось не со зла - а потому что никто вообще это не тестировал даже. Так, на минималках при загрузке что-то рисует - а потом после старта ОС все равно драйвер в нативный режим это переключает - и там в этом массиве числокрушилок с кучей сервисных процов - ничего общего с VESA нет вообще совсем никак. А то что оно немного умеет это косплеить для всякого легаси и чтобы показывать что-то при загрузке - так оно "до кучи". Более того - на ARM64, RISCV64 и проч - с PCIe - вообще никакого "vesa bios" при всем желании выполнить не получится. > в ч.н.все VESA DOS игры уже вываливаются (правда нек.игроманы сделали свои > драйвер(а):] но, альт.ОС на такое паскудство не расчитанные т.е.и все более > ранние вообще линуксы в ч.н., котрые заведомо можно запустить уже только > на VESA-драйвере, уже собственно даже не запустить... Рука MS? М.б.но не > только им это выгодно а и всяким зловредным структурам псевдо-гос. и не очень) Да не, просто эта эмуляция доисторического легаси вон теми числодробилками - тестирована совсем по минимуму. Достаточно чтобы что-то на экране при загрузке казалось - а детали всяких продвинутых видеорежимов ессно никто не тестирует и близко. А т.к. это в общем то та еще эмуляция, и внутрях оно уже давно вообще совсем не ЭТО...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #243 Ответы: #251

251. Сообщение от Аноним (253), 29-Июл-24, 17:38	+/–
Считаю я досточно привёл аргументов, в отличие ваших "да ну..." в качестве "аргументов". Которые к тому же разбиваются о ещё один факт - в их более ранних BIOS - всё работало, поломки - сознательные. Аппаратных изменений, чтобы на них сваливать, так мало что, как ук. - сами игроки правят, беря куски драйверов от древних(10+ лет) версий карт. Тестировать производителю, даже любой самой задрыпанной компании но, с много-сот миллионным оборотом,  - не то что не сложно а, обязательно делается ибо иначе сразу сверхмассовые возвраты, и просто копейки для их бюджета. Незаметить незапуск даже всех VESA DOS игр, не говоря про альтернативных отн-но MS/Mac ОСей, можно конечно, если не желать это замечать. Т.б.уже на протяжении почти десятилетия...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #257

253. Сообщение от Аноним (253), 29-Июл-24, 17:58	+1 +/–
(Upd: Обновленно) /// > Да, и AWARD_SW вон те тоже сделали чтобы мне удобнее было в чужой BIOS заходить и менять столь вредным админам их пароль на BIOS. И ведь хрен поспоришь - удобно же! Не вам, а сервис центру, куда вы сами понесёте свой ПК если забудете свой же пароль (я вот когда то тоже думал что даже по спец шаблону составляя пароль не забуду, а как то недолго времени спустя оказалось что я недооценивал паскудскость человеческой памяти) > В параметрах ключа указывалось, что он не заслуживает доверия и его не следует поставлять в своих продуктах. Лично мне как то не ясно куда это %censored% и прч.такое там у них смотрит, и т.б.на шифрацию аккаунтов и т.б.дисков, ведь им же самим м.б.понадобится очень быстро получить доступ, не тратя время на переборы(всяких аж 48 битных ключей) что к тому же требует сверх мощности, да даже если по дыре в алгоритме быстрей - что доступно же далеко не каждому их агенту и т.б.может быть надо быстро. В общем, подозреваю со временем все пароли, %censored%, будут попросту запрещенны, включая BIOS'овские. Впрочем, одна из тенденций - идентификация по карточкам и face-контроль, их то так легко не проверить в коде любому желающему на AWARD-SW-"вшивость"... И доверие у пользователей создают...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #233

256. Сообщение от Анониссимус (?), 29-Июл-24, 20:23	+/–
Можно установить троянца в ESP, чтобы перехватить пароль расшифровки твоего корня. Если он, конечно, у тебя зашифрован.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

257. Сообщение от Аноним (-), 29-Июл-24, 22:42	+/–
> Которые к тому же разбиваются о ещё один факт - в их > более ранних BIOS - всё работало, поломки - сознательные. Если учесть что BIOS у сабжей стал UEFI так то - и какой-то compat с BIOS работает как правило поверх этого и оно, таки, ремимплементация - тут тоже никаких теорий заговора может и не быть. Обычное сочетание оверинженерии, битрота и хренового тестирования может то, что никакому заговорщику не под силу. Бизнес жадный. Времена разработки и тесты - по минимуму. И скорей-быстрей продавать. Ну оно и получается чем должно. > Аппаратных изменений, чтобы на них сваливать, так мало что, как ук. - > сами игроки правят, беря куски драйверов от древних(10+ лет) версий карт. Аппаратных изменений в видеокартах - немеряно. Вплоть до смены всей микроархитектуры раза 3-4 уже. Но чтобы это знать - надо в топике немного разбираться. И, конечно, внутрях оно не имеет ничерта общего с VGA адаптерами и чем там еще. Так, эмулирует абстракцию на минималках чтобы что-то показывать вон там при загрузке. Тестится тоже на минималках. > Тестировать производителю, даже любой самой задрыпанной компании но, с много-сот миллионным > оборотом,  - не то что не сложно а, обязательно делается Видите ли, сейчас массовый клиент не вызывает VESA BIOS. Вообще совсем никак. Ну, может, при загрузке пару менюх. Ну вот это и проверят. И да, там даже допустимо если оно выглядит компромиссно, нормальный юзер видит это - раз в эн лет. > ибо иначе сразу сверхмассовые возвраты, и просто копейки для их бюджета. Откуда какие сверхмассовые возвраты из-за кривой VESA? Кто ей пользуется? Оно должно "что-то показывать" до момента пока юзер не вкатит драйвер. На этом требования к нему заканчиваются. > Незаметить незапуск даже всех VESA DOS игр, ...проще простого, intel вообще уже грозится окончательно убабахать compat с BIOS в новых компах. DOS игры если кто и запускает - то в чем-то типа DOSBOX. А DOS в диком виде я видел лет цать назад - на какой-то старинной кассе. Больше он вообще хождения в современном мире не имеет. > не говоря про альтернативных отн-но MS/Mac ОСей, можно конечно, Ну, как бы вон тех это все не очволнует. Вон там для пингвина дрова есть еще, и хорош. Кто там и как в колибри это прикручивать бу - никого не е. > протяжении почти десятилетия... Чуть больше я думаю. Замена dos-based win 9x -> NT based win случилась около 20 лет назад. В примерно те же поры массовый софт перестал что либо делать с VGA/VESA BIOS'ами. Драйвер первым делом переводит GPU в нативный режим, vga-фэйк с шины пропадает нафиг, и на этом - гудбай, его до ресета железки более никто не увидит там :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251

260. Сообщение от нах. (?), 01-Авг-24, 09:51	+/–
>> Когда загремишь в больничку и протестируешь на себе сделанную сейчас полезную продукцию >> - отпишись о впечатлениях. Если сможешь. > Намного лучше попасть в больничку где вот те бинт, вот те зеленка > - а больше мы вообще нихрена не разработали. Какие тебе еще > нафиг томографы?! возможно с твоим насморком - это было бы сильно лучше, чем тот японский томограф, который добавил бы к нему лучевую болезнь в тяжелой форме только потому, что доктор захотел посмотреть, что у тебя в легких точно чисто. И история с очень полезной и эффективной не имеющей побочек вакцинкой от того же насморка тоже ничему, я смотрю, не научила.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237

261. Сообщение от нах. (?), 01-Авг-24, 10:21	+/–
останется переделать все операционные системы для загрузки с волшебной микросхемы. > А то, что у нас сейчас - это секурбут ОТ людей, когда на какие-то планшеты слаку поставить вот ты действительно не понимаешь что как раз _людей_ - эти твои проблемы вот совершенно не интересуют? И если ценой небольшого усложнения жизни кр@сн0гл@зикам (cp@ка на планшете, планшете, карл! - это б-жественно же ж!) доступно большое усложнение жизни вредителям - то безусловно именно так и надо было сделать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #235

262. Сообщение от Аноним (263), 02-Авг-24, 19:29	+/–
https://archive.org/details/aaeon-uefi-firmware-git-repos (Лучше скачать через Torrent, но можно и wget'ом) wget https://archive.org/download/aaeon-uefi-firmware-git-repos/R... mkdir Ryzen2000_4000 cd Ryzen2000_4000/ unzip ../Ryzen2000_4000.git.zip mv Ryzen2000_4000.git .git sed -i '/\bbare *= *true\b/d' .git/config git reset -q -- . git checkout -- . cd Keys/FW/AmiTest/ openssl pkcs12 -in FW_priKey.pfx -nocerts -nodes -out FW_priKey.pem -passin pass:abcd git status Код выше можно целиком скопипастить прямо в терминал, убедившись, что ссылка на zip правильная (OpenNet может её неправильно отобразить). На выходе получится Keys/FW/AmiTest/FW_priKey.pem , это и есть PK.key из текста новости. Если будете ковыряться вручную, то пароль от FW_priKey.pfx – abcd . PFX (он же .p12) можно, например, открыть в xca. Дальше по инструкции отсюда: https://wiki.archlinux.org/title/Unified_Extensible_Firmware... В ней надо пропустить только первую команду после создания GUID, то есть генерацию новых PK.crt и PK.key . Вместо них следует использовать Keys/FW/AmiTest/FW_pubKey.cer и свежесозданный Keys/FW/AmiTest/FW_priKey.pem . Для проверки того, что всё сгенерировалось правильно, можно использовать sbkeysync с опцией --dry-run, как описано здесь: https://wiki.archlinux.org/title/Unified_Extensible_Firmware... . Каталог вместо /etc/secureboot/keys/ может быть любым. Более простой вариант использования описан в тексте новости, но работать он будет только на тех компьютерах, где этот тестовый ключ считается доверенным с завода, либо если добавить этот тестовый ключ себе в UEFI, как описано по ссылке выше. Удачи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

263. Сообщение от Аноним (263), 02-Авг-24, 19:35	+/–
Пароль "abcd". `john --incremental:Alnum --min-length=4 --max-length=4 --format=pfx-opencl` справился за одну секунду, благо, длину пароля нам любезно сообщили авторы доклада, но даже без этого в режиме incremental он справился бы крайне быстро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

264. Сообщение от tim (??), 03-Авг-24, 13:52	+/–
Ой, да ладно, как будто раздолбаи только от смузи заводятся. Если вспомнить, то капитаны волчьих стай паролем в энигме матерное слово ставили, чем бритишам облегчили расшифровку на пару порядков
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема