Комментарии 26
Наконец-то настоящий вирус. Поделки на Дельфи именуемые «троян» — это было так уныло.
Надеюсь, что борьба противоположных сторон не приведет к еще большим осложнениям для OpenSource (как это получается с UEFI).
UEFI (а точнее его secure boot) — отключаемая опция. В случае linux и прочего opensource secureboot может быть отключен, в силу своей неактуальности, а при использовании win8 далее — включен и обеспечивать соответствующую защиту. Имхо — вполне актуальное по логике решение.
по умолчанию то он не включен, что не позволит хомячкам установить дистр той же убунты. Предвещаю ответ в стиле «linux» хомячкам не нужен — cannonical с вами не согласна. Имхо secure boot помимо основной нагрузки это еще и палки в колеса остальных «домашних» ОС.
Именно что по-умолчанию он (secure boot) не включен. По крайней мере в последней материнке которую я покупал — он он был выключен. И никаких проблем с установкой арча не возникло.
Только что специально включил Secure Boot на ноуте (Lenovo Yoga), и загрузился штатными средствами с флешки с Ubuntu 12.10 x86-64. Secure Boot этому не помешал, также как и установке и запуску на ноуте друга, тоже со специально включеной опцией.
На мой взгляд, по логике было бы актуальным решение производителей BIOS, которое бы позволило сохранять в CMOS-памяти контрольную сумму нулевого и некоторых других секторов конкретного дискового устройства по вызову админа, установившего ОС, и проверять её перед загрузкой компа с этого устройства.
На моем первом компе биос контролировал МБР, и при попытке записи туда выдавал соответствующее предупреждение.
У меня на стареньких машинах тоже это было. Однако контролировал это дело биос на уровне INT 13h, а в protected-mode BIOS не используется. Но читать секторы на диске, считать и сверять контрольные суммы BIOS по-прежнему может.
Тогда встаёт проблема, как легитимно обновить в BIOS контрольную сумму после обновления загрузчика, то есть по сути возвращаемся к проблеме Secure Boot.
В общих чертах — так (исходно проверка отключена):
Разумеется, надо как-то сделать так, чтобы вирус не смог отключить опцию контроля — это можно было бы сделать только через BIOS Setup.
- В BIOS Setup подключается настройка — контролировать критически важные секторы при загрузке — и ставится действие — Рассчитать значение для контроля. Для экспертов можно сделать редактирование списка контролируемых секторов (по умолчанию, возможно, хватит нулевого).
- Админ ставит систему, потом в BIOS Setup заполняет список контролируемых секторов (если хочет), рассчитывает контрольные значения и ставит опцию контроля.
- Если после перезагрузки BIOS вычисляет несоответствие, он ругается — мол, на диск внесены изменения куда не надо. Возможно, это вирус. Обратитесь к специалисту.
Разумеется, надо как-то сделать так, чтобы вирус не смог отключить опцию контроля — это можно было бы сделать только через BIOS Setup.
По-умолчанию схема включена и активна? Если да, то какие преимущества по сравнению с secure boot для обычного пользователя?
Для обычного пользователя никаких. Для специалистов — отсутствие необходимости подписывать загрузчик: все действия для обеспечения безопасной загрузки выполняются админом в ходе начальной установки ПО на компьютер.
Загрузчик от Linux foundation всё равно в итоге подпишут, и это будет удобнее, чем контрольные суммы в биосе. Тем более, что далеко не все специалисты знают, в каких секторах располагается загрузчик.
Проблема в том, что помимо Microsoft и Linux есть ещё и другие операционные системы, а также мелкие системные разработчики. Им что делать?
А другие операционные системы и мелкие системные разработчики обязательно должны писать свой uefi загрузчик? Мне всегда казалось, что грузить своё ядро через какой нибудь grub намного эффективнее в плане затраченных на разработку ресурсов.
Ну так кому-то grub не нравится… мало ли.
Написать stage 2 загрузчик для своей собственной системы (или сразу ядро грузить) намного проще, чем написать загрузчик с нуля, который будет поддерживать хотя бы линукс и винду в дополнение к своей системе. Если кто-то пишет свой загрузчик — то совершенно определённо, меинстримом этот загрузчик станет, если станет, только через много лет, так что говорить в этом контексте о Secure Boot, который разработчик может отключить на своей машине, как-то глупо.
Вобщем-то, secure boot примерно так и работает, за исключением того что проверяются не просто контрольные суммы, а подписи доверенными сертификатами.
«And we need to go deeper»:
Для сносного противодействия буткитам нужно контролировать ВЕСЬ процесс загрузки, используя устойчивое шифрование вкупе с цифровыми подписями. А начинать нужно с контроля записи BIOS на аппаратном уровне, продолжая до подписанного MBR загрузчика и далее.
Да, это создаст дикие неудобства для «нестандартных» ОС, и ограничит их количество. Да, это замедлит загрузку.
Для сносного противодействия буткитам нужно контролировать ВЕСЬ процесс загрузки, используя устойчивое шифрование вкупе с цифровыми подписями. А начинать нужно с контроля записи BIOS на аппаратном уровне, продолжая до подписанного MBR загрузчика и далее.
Да, это создаст дикие неудобства для «нестандартных» ОС, и ограничит их количество. Да, это замедлит загрузку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Современные буткит-технологии и детальный анализ Win32/Gapz