Зависит от реализации, но чаще всего там есть и SMM-драйверы, и отдельная подсистема. И не работаю с серверными системами, поэтому из IPMI встречался пока только с Intel AMT, работает она без SMM или нет — тоже не проверял, но по идее не должна.
CSM — это Compatibility Support Module, т.е. слой эмуляции legacy BIOS. Если ОС поддерживает UEFI-загрузку и GOP — можно обойтись без него.
Чипы те называются Environmental Controller (EC), на некоторых платах для них пишут SMM-драйверы с вызовом через ACPI, чтобы управление получалось независимым от ОС.
У IO-trap'ов есть применение, мы их для отладки используем достаточно активно, к примеру.
Под конкретную машину надо брать и удалять из прошивки SMM-драйверы по одному, если исходного кода нет. Так оно будет отваливаться по частям и можно выяснить, без чего можно жить еще, а без чего уже нельзя.
Отключение возможно, но очень много вещей перестанет работать — эмуляция USB-устройств для DOS, CSM, мониторинг оборотов, IO-ловушки и масса другого. Можно опробовать удалить драйвер SmmInit или все SMM-драйверы и проверить.
Еще можно пропатчить БИОС на предмет обхода установки бита SMI_LOCK, а затем просто отключать источники SMI, пока не выяснится корень проблемы.
Его не надо вычленять, он в БИОСе в совершенно открытом виде лежит, в файлах типа SMM Driver, Combined PEI/SMM (исключительно редкий вид) и Combined DXE/SMM (раньше были распространены, сейчас от них отказались). Файлы лежат совершенно открыто в DXE-томе и по формату не отличаются от обычных DXE-драйверов, только вместо DXE_SYSTEM_TABLE используют SMM_SYSTEM_TABLE.
По существу вопроса: не было необходимости, поэтому можно считать, что не приходилось. Зато SMM-драйверов написал с десяток, так что кое-что понимаю в том, как они работают и зачем нужны. Рассказывать о конкретных особенностях не могу, NDA (я из второй половины вышеупомянутых людей как раз), но зато могу попросить: исследуйте популярные прошивки, пишите статьи, там конь не валялся еще и места море для улучшений как безопасности, так и функциональности.
Да, прошить такой БИОС получится только программатором, если в нем нет уязвимостей, через которые можно снять с него защиту от записи. Вышеупомянутая уязвимость S3-бутскрипта как раз одна из таких, и если с ее помощью снять биты BIOSWE и SMM_BWP, то шть можно будет хоть через Intel FTP, хоть через flashrom.
Более того, это не D6K такой краб, просто цель поставлена другая — научиться прошивать модифицированный БИОС поверх оригинального при помощи оригинальной же утилиты для обновления, и чтобы при этом все работало. Вот тут он поясняет свои дальнейшие действия после того места, на котором закончилась эта статья.
Да нет, ломают они там отлично, просто у них очень мало людей и очень много однотипных модов, поэтому на разработку новых каких-то времени не хватает почти никогда. Я уверен, что защиту эту сломали давно и до меня, но информацией не делились по каким-то причинам. А мне раз в 2 недели стабильно кто-нибудь писал по поводу этой защиты, и теперь я всех новых просителей буду вот сюда молча посылать.
Вообще, в теме модификации UEFI сейчас слишком мало людей, т.к. многие почему-то думают, что это сложно и модифицированное не будет работать. На деле же имеются открытые спецификации, почти полная открытая документация на все стадии загрузки, открытые исходники TianoCore, из которых на 75% любой UEFI и состоит, даже форматы исполняемых файлов (практически) стандартные, ну буквально реверсь-не хочу. А реверсят в итоге ~20 человек, половина из которых работает на MITRE, а другая не может ничего писать, т.к. у нее NDA на 1000 страниц. Так и живем.
P.S. пользуясь случаем, прорекламирую вчерашнюю статьюd_olex про недавнюю уязвимость в S3 Boot Script, ее эксплуатацию и последствия.
Дождались. Отличный пост, отличное дополнение к CHIPSEC, прогоню у себя обязательно.
Напиши что-нибудь на Хабр, d_olex, да хоть перевод этого же поста на русский, дабы тебе можно было поставить плюс в карму.
Hopper пробовал, но он показался примитивным совсем, даже с учетом встроенного генератора псевдокода и цены в 70 долларов. Можно написать и про него, на самом деле, материала хватает.
Ну не буду же я писать, что мой софт лучше, чем у Тедди или Энди. :) Да и багов море в любом софте такого рода, т.к. большая часть вендоров спецификацию в глаза не видели и на соответствие ей свои образы не проверяют, поэтому что-то хорошо работает в одной программе, что-то другое — в другой., так и живем.
Не знаю, работают ли скрипты в IDA demo, а основную покупать адски дорого, если рассматривать это все как хобби. Буду изучать radare2, когда время появится. Псто ждем с нетерпением, у меня тут тоже назревает продолжение про те же яйца, только в другой руке и на более новых ноутбуках HP.
А вы пробовали Uboot'ом проинициализировать хоть что-то более или менее сложное, да тот же контролер DRAM в AMD APU? Я вот пробовал и могу сказать — пусть хоть UEFI, хоть coreboot, хоть FSP, хоть черт лысый, лишь бы поддержка от производителя CPU была и возможность реализовать свою инициализацию без слишком уж сильного колдунства. А Legacy BIOS за 30+ лет его использования оброс таким количеством костылей и подпорок, что UEFI по сравнению с ним — верх логики, архитектуры и продуманности.
Про сертификацию и прочее — все вопросы к вендорам. Думаете, вам в Uboot или coreboot белый список WiFi-карт не добавят и загрузчик своим ключем не подпишут? Еще как добавят и подпишут, только выковыривать будет гораздо сложнее и одной IDA Demo уже не обойдешься. Все эти защиты и списки — желание вендрора, а не свойство UEFI, и я своими руками пишу UEFI-совместимые прошивки, в которых не только нет защиты от модификации, но и можно при помощи штатных утилит добавить свои DXE-драйверы, загрузчики и приложения в прошивку — было бы желание. А у «закрывальщиков» советую просто ничего не покупать.
Про OpenGL, графику и прочий модный Setup — это продает. Вследствие интеграции всего подряд под крышку процессора платы разных линеек и даже разных вендоров практически перестали отличаться, и поэтому отдел маркетинга лезет из кожи вон, чтобы выделить свои платы из череды таких же. Отсюда и серо-буро-малиновые текстолиты, и системы водяного охлаждения на чипах, которые без радиатора кое-как греются до 60 градусов, и карта звездного неба на фоне Setup, и прочий дуалбут в Android. Это все кошмар-кошмар, конечно, и лучше бы баги правили, но в сегменте «для хомяков» надежность и предсказуемость уже не продает, а вот красивая картинка — еще как. Альтернатива — производители для Embedded и Industrial, с другими подходами, целями и ценами. Вот там как был текстовый Setup, так и есть, только поддержку тач-скринов добавили, а то не у всех систем клавиатуры есть.
Низкоуровневую инициализацию оно не может, ровно потому, что ядро одно на всех, а инициализация отличается от платы к плате даже внутри одной линейки.
Я рад, что BIOS заменили на UEFI, ибо если его правильно готовить (выкинуть все лишнее, не увлекаться слишком новыми фичами и не добавлять ненужных искусственных ограничений, вроде описанного в статье) — сложность написания кода прошивки снижается на порядок, как и сложность доработки уже существующего. А вот пихать туда все больше хлама — это действительно не очень правильно, но маркетологов уже не остановить.
AMI уже добавляет поддержку OpenGL в Setup screen, дуалбут во встроенный Android, браузер и прочее такое. HP зачем-то ринулись писать «защиты», и сейчас последние версии проверяют DXE из PEI, а потом еще PEI из DXE (смогу открутить эту новую защиту — напишу продолжение к этой статье), оборудование проверяется по белым спискам, а прошить что-то чужое без программатора стало не то, чтобы невозможно, но очень трудно.
Меня, как программиста на C, смущает type&&.
Символов им в ASCII не хватает или чего? '$' не использован еще, зато на бедный амперсанд вешают уже пятую функцию: побитовый AND (if (attributes & EFI_FILE_ATTRIB_FIXED) {...}), логический AND (if (a && b) {...}), взятие адреса (UINT8* ptr = (UINT8*) &a;), ссылочный тип (void f(const QByteArray& data) {...}) и теперь вот еще один ссылочный тип. С нетерпением жду новых стандартов, уже интересно, куда еще амперсанд допишут.
Загрузить свою винду — не поможет от зашифрованных носителей. Опасность OptionROM в том, что при неправильной реализации для код OptionROM может получить доступ к SMM или flash write, и потому сможет прошить себя в БИОС и закрепиться в SMM, и уже оттуда управлять системой с максимальными правами, будучи совершенно незаметным для пользователя ПК. От этого не спасет никакое шифрование и никакая защита уровня ядра ОС.
CSM и SecureBoot — взаимоисключающие опции, поэтому я и сказал, что не хотите заниматься SecureBoot-ом, включите CSM — и вся система безопасности, основанная на проверке ЭЦП драйверов и загрузчиков отключится автоматически.
Не вижу смысла спорить, если вы не считаете этот вектор атаки сколько либо важным — дело ваше.
Злонамеренный коллега, пока вы отошли за кофе. Горничная в отеле, где вы оставили на столике ноутбук. Полицейский на досмотре в аэропорту. Любой, на секунду получивший доступ до вышего выключенного ПК и способный его включить.
Новое железо, способное загружать OptionROM'ы, появляется каждый раз при использовании любой периферии с PCI(e): PCMCIA, FireWire, Thunderbolt, SATA Express. Да, они не так распространены, как USB, но их опасности это не отменяет.
Рулить ключами не просто, но безопасность никогда простой и не была, и от security-convenience tradeoff никуда не деться. Не хочется управлять: CSM = Enabled и вперед.
Если бояться закладок в железе или БИОСе, придется делать свое железо и писать свой БИОС. Ни то, ни другое не являются космически сложными проектами, а «верхняя» половина БИОСа и так уже открыта под лицензией BSD разработчиками проекта TianoCore, адаптируй — не хочу. Про тепличные условия я не могу поговорить — NDA, но подскажу, что прав локального рута более чем достаточно.
SecureBoot спасет вас от подмены UEFI-загрузчика и злобных Option ROM'ов. Не хотите заниматься управлением ключами самостоятельно — отключайте, на десктопах это пока еще можно сделать. Все годы жили так прекрасно, что про EvilMaid-атаку и буткиты не писал только ленивый, а сделать с ними ничего нельзя было, теперь сделали — и технологию восприняли как ограничение свободы, и это при том, что никто не мешает добавить свои ключи в любую из баз или удалить уже существующие.
Одна из самых жутких уязвимостей, продемонстрированных на 31C3, на мой взгляд, это дыра в работе с S3 Boot Script'ом, которая позволяет обойти защиту SMRAM от доступа через DMA или сбросить биты BIOSWE/SMM_BWP, открыв микросхему БИОСа на запись из ОС (а это позволяет и обойти SecureBoot, и встроить свой вредоносный код, и вообще полностью контролировать уязвимую машину).
Уязвимости подвержены подавляющее большинство систем с UEFI, исправление уже доступно, но пока оно пройдет через все раунды — может случиться все, что угодно. Ждем обновлений и надеемся, что никто из специалистов не решится написать и выложить полноценный эксплоит прямо завтра.
Чипы те называются Environmental Controller (EC), на некоторых платах для них пишут SMM-драйверы с вызовом через ACPI, чтобы управление получалось независимым от ОС.
У IO-trap'ов есть применение, мы их для отладки используем достаточно активно, к примеру.
Под конкретную машину надо брать и удалять из прошивки SMM-драйверы по одному, если исходного кода нет. Так оно будет отваливаться по частям и можно выяснить, без чего можно жить еще, а без чего уже нельзя.
Еще можно пропатчить БИОС на предмет обхода установки бита SMI_LOCK, а затем просто отключать источники SMI, пока не выяснится корень проблемы.
По существу вопроса: не было необходимости, поэтому можно считать, что не приходилось. Зато SMM-драйверов написал с десяток, так что кое-что понимаю в том, как они работают и зачем нужны. Рассказывать о конкретных особенностях не могу, NDA (я из второй половины вышеупомянутых людей как раз), но зато могу попросить: исследуйте популярные прошивки, пишите статьи, там конь не валялся еще и места море для улучшений как безопасности, так и функциональности.
Вообще, в теме модификации UEFI сейчас слишком мало людей, т.к. многие почему-то думают, что это сложно и модифицированное не будет работать. На деле же имеются открытые спецификации, почти полная открытая документация на все стадии загрузки, открытые исходники TianoCore, из которых на 75% любой UEFI и состоит, даже форматы исполняемых файлов (практически) стандартные, ну буквально реверсь-не хочу. А реверсят в итоге ~20 человек, половина из которых работает на MITRE, а другая не может ничего писать, т.к. у нее NDA на 1000 страниц. Так и живем.
P.S. пользуясь случаем, прорекламирую вчерашнюю статью d_olex про недавнюю уязвимость в S3 Boot Script, ее эксплуатацию и последствия.
Напиши что-нибудь на Хабр, d_olex, да хоть перевод этого же поста на русский, дабы тебе можно было поставить плюс в карму.
Про сертификацию и прочее — все вопросы к вендорам. Думаете, вам в Uboot или coreboot белый список WiFi-карт не добавят и загрузчик своим ключем не подпишут? Еще как добавят и подпишут, только выковыривать будет гораздо сложнее и одной IDA Demo уже не обойдешься. Все эти защиты и списки — желание вендрора, а не свойство UEFI, и я своими руками пишу UEFI-совместимые прошивки, в которых не только нет защиты от модификации, но и можно при помощи штатных утилит добавить свои DXE-драйверы, загрузчики и приложения в прошивку — было бы желание. А у «закрывальщиков» советую просто ничего не покупать.
Про OpenGL, графику и прочий модный Setup — это продает. Вследствие интеграции всего подряд под крышку процессора платы разных линеек и даже разных вендоров практически перестали отличаться, и поэтому отдел маркетинга лезет из кожи вон, чтобы выделить свои платы из череды таких же. Отсюда и серо-буро-малиновые текстолиты, и системы водяного охлаждения на чипах, которые без радиатора кое-как греются до 60 градусов, и карта звездного неба на фоне Setup, и прочий дуалбут в Android. Это все кошмар-кошмар, конечно, и лучше бы баги правили, но в сегменте «для хомяков» надежность и предсказуемость уже не продает, а вот красивая картинка — еще как. Альтернатива — производители для Embedded и Industrial, с другими подходами, целями и ценами. Вот там как был текстовый Setup, так и есть, только поддержку тач-скринов добавили, а то не у всех систем клавиатуры есть.
Я рад, что BIOS заменили на UEFI, ибо если его правильно готовить (выкинуть все лишнее, не увлекаться слишком новыми фичами и не добавлять ненужных искусственных ограничений, вроде описанного в статье) — сложность написания кода прошивки снижается на порядок, как и сложность доработки уже существующего. А вот пихать туда все больше хлама — это действительно не очень правильно, но маркетологов уже не остановить.
AMI уже добавляет поддержку OpenGL в Setup screen, дуалбут во встроенный Android, браузер и прочее такое. HP зачем-то ринулись писать «защиты», и сейчас последние версии проверяют DXE из PEI, а потом еще PEI из DXE (смогу открутить эту новую защиту — напишу продолжение к этой статье), оборудование проверяется по белым спискам, а прошить что-то чужое без программатора стало не то, чтобы невозможно, но очень трудно.
Символов им в ASCII не хватает или чего? '$' не использован еще, зато на бедный амперсанд вешают уже пятую функцию: побитовый AND (if (attributes & EFI_FILE_ATTRIB_FIXED) {...}), логический AND (if (a && b) {...}), взятие адреса (UINT8* ptr = (UINT8*) &a;), ссылочный тип (void f(const QByteArray& data) {...}) и теперь вот еще один ссылочный тип. С нетерпением жду новых стандартов, уже интересно, куда еще амперсанд допишут.
CSM и SecureBoot — взаимоисключающие опции, поэтому я и сказал, что не хотите заниматься SecureBoot-ом, включите CSM — и вся система безопасности, основанная на проверке ЭЦП драйверов и загрузчиков отключится автоматически.
Не вижу смысла спорить, если вы не считаете этот вектор атаки сколько либо важным — дело ваше.
Новое железо, способное загружать OptionROM'ы, появляется каждый раз при использовании любой периферии с PCI(e): PCMCIA, FireWire, Thunderbolt, SATA Express. Да, они не так распространены, как USB, но их опасности это не отменяет.
Рулить ключами не просто, но безопасность никогда простой и не была, и от security-convenience tradeoff никуда не деться. Не хочется управлять: CSM = Enabled и вперед.
Если бояться закладок в железе или БИОСе, придется делать свое железо и писать свой БИОС. Ни то, ни другое не являются космически сложными проектами, а «верхняя» половина БИОСа и так уже открыта под лицензией BSD разработчиками проекта TianoCore, адаптируй — не хочу. Про тепличные условия я не могу поговорить — NDA, но подскажу, что прав локального рута более чем достаточно.
Уязвимости подвержены подавляющее большинство систем с UEFI, исправление уже доступно, но пока оно пройдет через все раунды — может случиться все, что угодно. Ждем обновлений и надеемся, что никто из специалистов не решится написать и выложить полноценный эксплоит прямо завтра.