Уязвимости в процессе загрузки системы могут эксплуатироваться и локально, и удаленно, но для этого нужно повышение провилегий до возможности монтирования ESP и переписывания загрузчика на нем (обычного LPE до System хватит за глаза). Дальше при отсутвии SecureBoot малварь может подменить загрузчик системы на собственный, и дальше рулить системой как ей заблагорассудится (т.к. она контролирует загрузку ядра и имеет возможность патчить его на лету), а в случае с включенным SecureBoot придется обходить сначала его, иначе вместо перехвата управления получится банальный DoS.
Да я это все слишком близко к сердцу и не принимаю, просто сейчас оно все именно вот так, и каких-то тенденций к изменению ситуации пока не видно. Единственная плата с открытой реализацией UEFI — Intel Galileo, там тоже не обошлось без блобов.
Про «все так плохо» — нет, это зависит от настроек, которые установил производитель ПК. Если он захочет, у вас современная машина с чипсетом/СнК Intel даже до ResetVector'а не дойдет, если хеш прошивки не сойдется с эталонным, но так настраивают систему только полные мудаки, и у таких я советую просто ничего не покупать.
Основная проблема открытых прошивок — Intel и AMD не горят желанием открывать MRC для новых систем даже своим же IBV, тем более сообществу. Взамен предлагается использовать Intel FSP / AMD AGESA binary, которые, по факту — мегабайтные BLOBы, реализующие 90% фазы PEI. В итоге что закрытый UEFI, что открытый coreboot + SeaBIOS/TianoCore/Linux — разницы с точки зрения любящего свободу пользователя почти никакой. А реверсить код MRC — дело не на один год, к тому времени целевая платформа уже устаревает до грани полной непривлекательности.
Решать эту проблему нужно с открытия железа и спецификаций к нему, за открытым софтом к таким системам дело не станет.
Добавлю также, эталонная что реализация SecureBoot открыта под лицензией BSD и является частью проекта TianoCore, и мой опыт показывает, что реализации IBV отличаются от нее очень мало, но, конечно, это все равно не тот открытый код, который нам нужен.
Да там социальной инженерии простейшей хватит за глаза, скорее всего. На самом деле, прошивка у Acer чаще всего настолько дырявая, что заморачиваться обращением в Support мало кто захочет.
Добавлю еще, что на некоторых системах (на вот этом Acer тестовом, к примеру) есть возможность сброса пароля звонком в Acer Support, где нужно будет доказать, что машина не украдена, а затем назвать набор цыфр, которые отображаются на экране после 3 неудачных попыток ввода пароля. В ответ они пришлют другой набор, и если ответ правильный, то драйвер UnlockPwd этот самый пароль сотрет.
Стирание NVRAM при помощи программатора, либо подсистемой Crisis Recovery прошивки — два стандартных способа, которые помогают в случае, если PKpriv или пароль утеряны. Если доступ к PKpriv есть, отключить SecureBoot можно удалением переменной PK вызовом SetVariable с нужными параметрами из любой загруженной ОС.
Про безопасность SecureBoot и атаки на него я уже ранее писал, здесь больше про то, как им взять и начать пользоваться.
Безопасность SecureBoot держится на безопасности NVRAM, т.е. для нее необходимо, чтобы к содержимому NVRAM нельзя было получить доступ каким-то обходным способом, а не стандартными GetVariable/SetVariable, и по умолчанию на обеих ноутбуках это не так (прошивки уязвимы к атакам на S3 BootScript, что позволяет записать свой код в микросхему, что позволяет стартовать раньше SecureBoot, т.е. толку от него без защиты остального — ноль без палочки).
Безопасность любой системы определяется по самому слабому звену, поэтому вместе с SecureBoot нужно использовать и другие способы защиты прошивки, теорию о которых я описывал в вышеупомянутом цикле, а практику показывал на ZeroNights 2015.
Если вы простой пользователь и хотите, чтобы о безопасности вашей прошивки подумал вендор — покупайте системы HP или Dell, несмотря на все их недостатки, конкретно с защитой прошивок там все намного лучше, чем у конкурентов.
Скорее не об аудитории, а о темах, которые там обсуждаются. GT, за вычетом космонавтики и железа — это такой новый «Чулан», куда переехала политота, войны с РосКомПозором, «Гляньте чуваки, какой новый гаджет на кикстартере» и прочее вот такое. Да, теперь там пишут и про разработку собственных устройств, и про FPGA, но только и исключительно по воле «кровавой одменистрации», а основной набор тем из топа по прежнему примерно такой, как перечислен выше. От того и отношение к ресурсу соотвествующее.
Влезу немного со своим рылом в калышный ряд, но Хабр перестал быть тортом не потому, что с него ушли создатели инфошума, а в основном потому, что администрация волевым решением унесла на GT все железячные топики, будь это DIY, программирование МК или промышленная автоматика — все на GT, к обзорам умных браслетов и прочей ерунде для гиков. В результате мы потеряли посты DIHALT'а, dlinyj, и кучи других товарищей, а в замен получили очередные 100500 статей о преимуществах C# над C++. Этот перенос — та самая соломинка, сломавшая спину моему писательскому верблюду. Написал все, что не мог не написать, еще напишу статью или пару статей про SecureBoot, так как обещал, ну и все, дальше только стендэлон на английском, как у d_olex.
Проблема в том, что если лампочки Hue еще можно заменить на что-то похожее (особенно если 16 миллионов цветов не нужны), то хаб менять вообще не на что — он объективно лучше, чем другие ZLL-хабы вроде GE Wink. Есть еще интересный Samsung SmartThings, но пока его сложно купить вне Великобритании, а для управления линейкой Hue ему все равно нужен Hue Bridge.
В общем, хорошо, что они одумались, но посмотреть на какой-нибудь RaspBee все же теперь стоит, если еще не.
Был момент, когда на amazon.de было 1,5 звезды, 2 дня назад, как раз между анонсом сертификационной программы Friends of Hue и отказом от блокировки. Теперь минусовать не за что, народ меняет отзывы обратно.
Хочешь сделать людям хорошо — сделай сначала плохо, а потом верни как было.
В этот раз DRM'о внедрить не получилось, народ обрушил рейтинги Hue Starter Kit на amazon.com и amazon.de практически до 1, а Philips встала в один ряд с Sony, Keurig и FTDI, но ничего — через пару месяцев или лет они попробуют еще раз, по еще какой-нибудь выдуманной причине.
Там даже исследования никакие не нужны, на самом деле. Адекваной реализации стоит ожидать только на серверных платах, на которых этот самый IOMMU нужен не для безопасности, а для проброса PCIe-устройств в виртуальные окружения. Все остальные системы, производимые массово, имеют IOMMU либо отключеным (чаще всего), либо настроеным по умолчанию (и защиты прошивки и/или ранних стадий загрузки ОС от DMA-атак такая настройка не предполагает).
Короче: если существует опасность вышеуказанных атак, то лучше все внешние порты с DMA, OROMами и/или Bus Master'ингом отключить, желательно аппаратно.
Для безопасного использования внешних PCIe-устройств необходима поддержка, правильная настройка и использование IOMMU (у Intel он называется VT-d, поддерживается далеко не всеми процессорами, требуется для защиты от доступа к физической памяти ПК при помощи DMA, инициированного прошивкой внешнего PCIe-устройства) и SecureBoot (чтобы защитить систему от загрузки вредоносного Option ROM во время старта).
А теперь поднимите руки, у кого обе эти технологии хотя бы включены, я уже не говорю про правильно настроены…
Классная станция, дай ТНБ каждому ремонтнику такую.
Понятно, что настоящие джедаи умудряются проделать то же самое в гараже, используя строительный фен и помощь такой-то матери, но с хорошим инструментом и работать приятнее, и на выходе получается не 30% брака, а 0,3%.
Про «все так плохо» — нет, это зависит от настроек, которые установил производитель ПК. Если он захочет, у вас современная машина с чипсетом/СнК Intel даже до ResetVector'а не дойдет, если хеш прошивки не сойдется с эталонным, но так настраивают систему только полные мудаки, и у таких я советую просто ничего не покупать.
Решать эту проблему нужно с открытия железа и спецификаций к нему, за открытым софтом к таким системам дело не станет.
Добавлю также, эталонная что реализация SecureBoot открыта под лицензией BSD и является частью проекта TianoCore, и мой опыт показывает, что реализации IBV отличаются от нее очень мало, но, конечно, это все равно не тот открытый код, который нам нужен.
Безопасность SecureBoot держится на безопасности NVRAM, т.е. для нее необходимо, чтобы к содержимому NVRAM нельзя было получить доступ каким-то обходным способом, а не стандартными GetVariable/SetVariable, и по умолчанию на обеих ноутбуках это не так (прошивки уязвимы к атакам на S3 BootScript, что позволяет записать свой код в микросхему, что позволяет стартовать раньше SecureBoot, т.е. толку от него без защиты остального — ноль без палочки).
Безопасность любой системы определяется по самому слабому звену, поэтому вместе с SecureBoot нужно использовать и другие способы защиты прошивки, теорию о которых я описывал в вышеупомянутом цикле, а практику показывал на ZeroNights 2015.
Если вы простой пользователь и хотите, чтобы о безопасности вашей прошивки подумал вендор — покупайте системы HP или Dell, несмотря на все их недостатки, конкретно с защитой прошивок там все намного лучше, чем у конкурентов.
В общем, хорошо, что они одумались, но посмотреть на какой-нибудь RaspBee все же теперь стоит, если еще не.
В этот раз DRM'о внедрить не получилось, народ обрушил рейтинги Hue Starter Kit на amazon.com и amazon.de практически до 1, а Philips встала в один ряд с Sony, Keurig и FTDI, но ничего — через пару месяцев или лет они попробуют еще раз, по еще какой-нибудь выдуманной причине.
Короче: если существует опасность вышеуказанных атак, то лучше все внешние порты с DMA, OROMами и/или Bus Master'ингом отключить, желательно аппаратно.
А теперь поднимите руки, у кого обе эти технологии хотя бы включены, я уже не говорю про правильно настроены…
Понятно, что настоящие джедаи умудряются проделать то же самое в гараже, используя строительный фен и помощь такой-то матери, но с хорошим инструментом и работать приятнее, и на выходе получается не 30% брака, а 0,3%.