Pull to refresh

Comments 4

Все это возможно только потому, что производители оборудования для конечного пользователя не видят никакой необходимости заботиться о безопасности своих EFI-совместимых прошивок, в результате ошибки, обнаруженные пару лет назад, на большинстве систем так и не исправлены, а о новых и говорить нечего. К примеру, представленная на 31C3 в декабре 2014 атака на S3 BootScript (а именно ее использует упомянутый в статье червь) все еще работает на подавляющем большинстве систем с EFI/UEFI.
По настоящему безопасностью UEFI займутся только тогда, когда атаки на него выйдут из PoC-песочницы (момент уже очень близок), либо когда Intel и MS перестанут сертифицировать продукты, не проходящие валидацию Chipsec'ом и тестирование HSTI. Пока не произошло ни то, ни другое, поэтому нужно либо пользоваться системами тех, кому «не пофиг», вроде Dell или HP, либо брать безопасность в свои руки и все патчить самостоятельно. Про второй вариант я попробую рассказать на конференции ZeroNights 2015, если доклад одобрят.
EFI? Проблемы появились заметно раньше (и опять, что характерно, в интерфейсе придуманным Apple). Но вообще эти чудеса — относительно недавнее изобретение: я хорошо помню что материнка для Pentium!!! продавалась ещё с аппаратной защитой от перепрошивки (просто джампер замкни — и ни один червь не прорвётся), а когда через год она умерла и я купил точно такую же, то там этот джампер был выкушен. Ещё через пару лет об этом уже все забыли (на более новых материнках джампер уже даже не предусмотрен конструкцией) — а теперь у нас, видите ли, черви появляются. Раньше нужно было думать.
Такую аппаратную защиту можно сделать и сейчас, ничего не мешает, только вот спроса на нее практически нет — никому снова нет дела до безопасности прошивки, а две микросхемы SPI (чтобы разделить изменяемые части вроде регионов GbE, ME и NVRAM от собственно региона BIOS) ставить дороже, чем одну. Более того, система с RO-прошивкой все равно подвержена эксплуатации через уязвимости в S3 и SMM, только приподит она не к персистентности, а «всего лишь» к повышению привелегий до уровня SMM-кода, что тоже весьма неплохо.
Что дейсвтительно надо сделать, так это, во-первых, планомерно уменьшать attack surface путем выкидывания из прошивки всего лишнего (а не добавления всего отдаленно показавшего нужным, как происходит сейчас), а во-вторых — проводить аудит, проверять и перепровеять прошивку перед выпуском. И если со вторым еще более-менее неплохо стало в последнее время (Chipsec, LUV, FWTS, HSTI, вот это все), то с первым у EFI и всей индустрии большие проблемы, которые никто не спешит решать.
UFO just landed and posted this here
Sign up to leave a comment.