https://opennet.ru/openforum/vsluhforumID3/109646.html В пакете Cryptsetup (https://gitlab.com/cryptsetup/cryptsetup), применяемом для настройки шифрования дисковых разделов в Linux, выявлена уязвимость (http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html) (CVE-2016-4484 (https://security-tracker.debian.org/tracker/CVE-2016-4484)), позволяющая получить доступ в командную оболочку начального загрузочного окружения initramfs или Dracut с правами пользователя root. Проблема вызвана ошибкой в коде скрипта разблокировки системных разделов и проявляется только при использовании LUKS (Linux Unified Key Setup) для шифрования разделов.<br><br><br>Для эксплуатации уязвимости достаточно нажать и удерживать клавишу Enter в ответ на запрос ввода пароля для доступа к зашифрованным разделам. после чего root shell. После примерно 70 секунд удерживания Enter пользователь будет выброшен в root shell загрузочного окружения. Атака хорошо повторяема и не зависит от настроек или системного окружения. Несмотря на то, что полный доступ предоставляется только в окруж https://opennet.ru/openforum/vsluhforumID3/109646.html#98 Sat, 19 Nov 2016 12:14:19 GMT &gt; А как этот grub запустится, если он сам зашифрован будет? Или шифруется <br>&gt; не веcь /boot, а только ядро и initrd?<br><br>груб запускается с мбр и ко, дальше предположительно он умеет спросить пароль и открыть зашифрованный раздел (зашифрована не вся поверхность, там ещё технические структуры типо таблицы разделов и прочего, в этом объёме пускатель груба и лежит)<br> https://opennet.ru/openforum/vsluhforumID3/109646.html#97 Fri, 18 Nov 2016 11:36:02 GMT Инсталлятор 8.6 перестал давать такое делать. Надо 8.5. Предположу, что 8.5 не проверяет есть ли бут на незашифрованном разделе.<br> https://opennet.ru/openforum/vsluhforumID3/109646.html#96 Thu, 17 Nov 2016 19:16:52 GMT Зачем пробовать? На двух серверах поднял, хоть и не без бубна, и оно уже год работает. Ну и с обновлениями ядра тоже своя специфика.<br> https://opennet.ru/openforum/vsluhforumID3/109646.html#95 Thu, 17 Nov 2016 07:01:00 GMT &gt; iLo чем не устраивает?<br><br>Да вот понимаешь, жила была фирма супермикро. И запалилась на инженерном логине в таких вещах. Ну конечно же они случайно забыли, вы ничего не подумайте.<br><br> https://opennet.ru/openforum/vsluhforumID3/109646.html#94 Thu, 17 Nov 2016 06:13:58 GMT Может ли система подписей UEFI-прошива -&gt; загрузчик -&gt; ядро обеспечить защиту от подмены ядра?<br> https://opennet.ru/openforum/vsluhforumID3/109646.html#93 Thu, 17 Nov 2016 03:29:59 GMT &gt; Ещё вроде Ieee1394, которвй FireWire.<br><br>А также PCI/PCIe и прочие infiniband. И таки да - есть девайсы которые сделав DMA снимают к чертям блокировку экрана с компа. Для 1394 кто-то такой PoC делал, вытряхивая винду с экрана блокировки как будто пользователь ввел верный пароль. Разумеется пароль никто не знает - приблуда просто патчит код и процесс уверен что пароль введен правильно. Потому что ему код пропатчили.<br><br>А кому мало - еще rowhammer есть. Даже, блин, rowhammer.js - даже вебстраничка может до кучи попробовать подолбить один и тот же адрес памяти. В надежде что битики перевернутся, после чего можно немного пропатчить память. Например память ядра. Убедив его сделать что-нибудь полезное атакующему. На js это конечно получается лажово и алгоритмы трансформации доступа у контролеров памяти разные. Но потенциально даже голимая вебпага может на всем что DDR3 и старее провалиться в kernel mode. Не говоря о нативных программах которые могут пытаться повысить себе привилегии гораздо наглее и потому потенци https://opennet.ru/openforum/vsluhforumID3/109646.html#92 Thu, 17 Nov 2016 03:20:33 GMT &gt; Благородный дон происходит от крокодилов???<br><br>Вроде бы, переваривать пластик не умеют даже крокодилы. Многие пластики достаточно устойчивы к химии. И RoHS конечно RoHS'ом но применяемые в электронной промышленности материалы все-таки не сказать что полезны для здоровья.<br> https://opennet.ru/openforum/vsluhforumID3/109646.html#91 Thu, 17 Nov 2016 03:17:39 GMT &gt; Это в принципе не уязвимость как таковая. Зашифрованные данные остаются зашифрованными. <br><br>Тем не менее, атакующий может подпихнуть приблуду которая ему сольет твой пароль при этом. И если у атакуюшего выдастся минутка когда ты отошел посцать - можно зажать энтер, подпихнуть приблуду, отвалить в туман и сделать вид что так и было. А вот дальше атакующий уже знает как все это расшифровывать, извини.<br> https://opennet.ru/openforum/vsluhforumID3/109646.html#90 Thu, 17 Nov 2016 03:15:28 GMT Это валидно при условии что бутлоадер согласен тебя пустить в продвинутости. Тот же grub умеет пароль просить при этом. Не то чтобы это сильная защита, но если атакующий ограничен во времени - это немного стопорнет атакующего. Хотя если он сможет загрузиться с другого носителя - эта линия защиты будет расплющена.<br><br>Чтобы менять настройки BIOS было нельзя - бывает пароль на BIOS. А на него бывает AWARD_SW, после ввода которого менять их становится таки можно. И прочие management engine.<br>