Многое очень спорно, но вот это реально покоробило:
Я уж молчу о том, что отладчики сами по себе плохи, они просто не оказывают той помощи, которой от них многие ждут.
Пожалуйста, изучайте свои инструменты откладки и тестирования, фаззеры, санитайзеры, и т.п. Любая ошибка, замеченная ими, значительно дешевле, чем она же, но замеченная пользователем. Если ваша система не позволяет подключить к себе отладчик во время работы — это недостаток системы, а не отладчика! Если вы не умеете пользоваться инструментами — это недостаток квалификации, а не инструментов!
Отладка кода заведомо сложнее его написания, но почему-то автор не предлагает заменить свою IDE на ed, зато предлагает оказаться от отладчика, потому что он якобы «не оказывает помощи»…
Непонятно, к чему этот FPGA подключен, так что собрать себе на нем NES и играть в Черного Плаща прямо на коммутаторе не получится, я думаю, но и без этого уже зашквар полный. С другой стороны, дизайн нормальной цепочки доверия — не хрен собачий, а реализация — и подавно, и потому можно тут смеяться над ними в кулак, пока внезапно не окажется, что у самих рыло в пуху.
Именно так, и даже веселее еще, потому что можно менять не только корневой сертификат, но и вообще все поведение корня доверия, причем там даже не код меняется как таковой, а FPGA bitstream. Всякое видел в своей жизни, но такое — в первый раз.
Еще какая уязвимость, повышение привилегий от локального рута до полного, окончательного и бесповоротного контроля над устройством, включая его root-of-trust.
У gRT->SetVariable, функции, которую ОС вызывает для того, чтобы в NVRAM писать, есть флаг APPEND_WRITE, который позволяет к уже имеющимся revocation list'ам дописать новых записей. Т.к. записи эти хранятся в NVRAM, который в свою очередь хранится на SPI-чипе материнской платы, переустановка ОС не меняет их значений. Если значения там уже есть, SetVariable вернет EFI_SUCCESS, но менять ничего не будет, так что и не перезаписываются, и не дублируются, на самом деле.
Если хотите подробностей, все это описано подробно в спецификации UEFI 2.3.1C+ в разделе Runtime Services: SetVariable.
Тем не менее, питон для STM32, для FreeRTOS можно адаптировать (потому что на голом железе оно уже работает), а то, что интерпретатор жрет — мало кто ожидал что жрать будет не мегабайты.
Меня этот проект интересует потому, что на его основе сейчас создается новая версия UEFI SCT, без которой невозможно проверить конкретную реализацию UEFI-совместимой прошивки на совместимость с конкретной версией спецификации.
Удивительный вопрос, я даже несколько теряюсь. Ручные обновления = отсутствие обновлений = известные и эксплуатируемые уязвимости, которые значительно хуже, чем новые, еще не известные и не эксплуатируемые. Если вы готовы сами следить за обновлениями и нести ответственность за безопасность системы — я только за, но вас таких снова три с половиной, а защитить хоть как-нибудь и закрыть хотя бы известные дыры стараются для всех. UEFI Forum разработал и внедрил общих механизм для обновления всех компонентов прошивки — ESRT, которым пользуются клиенты вроде Windows Update и Linux Vendor Firmware Service. Очень жаль, что поддерживаются эти сервисы пока далеко не всеми, потому что нужны они еще вчера.
В BIOS Setup дата-центра действительно захожу удаленно, через IPMI и RedFish.
Добавлю, что это не только удорожает продукт, но и делает автоматические обновления невозможными в принципе, потому что от пользователя требуется нетривиальное (т.е. не «нажмите Ввод») физическое присутствие, которое невозможно обеспечить либо по причине «у пользователя лапки», либо потому, что система установлена в дата-центре в закрытый шкаф.
Никто другого и не ждал, за 7 лет с запуска UEFI CA им успели подписать такое количество всякой дырявой фигни, что доверять ему теперь — то еще решение. При этом не будешь доверять — OROMы перестанут запускаться, т.е. технология сразу переходит из разряда «включил и работает» в «требует постоянного внимания администратора», и потому отключать ее начнут теперь еще более яростно.
1) Полно таких ноутбуков, а под старый текстовый интерфейс мимикрируют потому, что IBV так захотели. На десктопах давно уже AMI правит бал, и потому там давно уже вакханалия с OpenGL в Setup и GIFами анимированными, а на ноутбуках еще используют Phoenix и Insyde, которые по умолчанию выглядят «как встарья», и которые надо переделывать под мышь самому. Dell, к примеру, переделывает, а другие не парятся.
Мое мнение: старый текстовый интерфейс сильно лучше, чем все эти новомодные тормозящие чудеса в решете (он в текстовую консоль почти без потерь перенаправляется, к примеру, и программировать его проще, т.е. ошибок допустят меньше), но людям нравятся блестки, и потому рано или поздно без блесток не останется ничего.
2) Так и есть, и это действительно связано с тем, что некоторые UEFI OROMы сильно быстрее своих legacy-собратьев, которые вынуждены переключаться в 16-битный реальный режим и сегменты там яростно переключать, и чем больше устройств в массиве — тем заметнее разница. По честному, без бенчмарков это все — так себе аргументация, но я достаточно не люблю CSM, чтобы видеть после его отключения ускорение, пусть даже это ускорение только у меня в голове происходит.
Чтобы подпись отозвали, проблему надо зарепортить UEFI Security Response Tem.
Как только проблему подтвердят, хеш начального загрузчика Касперского (который компрометирует UEFI CA) будет добавлен в UEFI Revocation List File, который затем MS постарается распространить на все машины с ключом MS KEK (на другие он просто не установится) через Windows Update.
Спасибо за статью, особенно за этот замечательный загрузчик Касперского, который теперь надо бы забанить по хорошему, потому что цепочка эта фактически уничтожает последние остатки доверия к подписям с корнем на UEFI CA.
Проблема эта известная, радикальное решение — не доверять UEFI CA совсем (Apple и Microsoft на своих машинах поступают именно так). При этом начнутся сложности с работой OptionROM'ов внешних видеокарт и рейд-контролеров, которые в UEFI 2.4+ можно обойти при помощи SecureBoot Deployment Mode, либо подписыванием ОРОМов своими ключами и загрузкой их с диска или SPI-флеша, а не из устройства.
В общем, теоретически решения есть, и все можно сделать, если очень хотеть. Практически же, за исключением трех с половиной анонимов, UEFI SecureBoot отключен на всех ПК, потому что любая технология, которая одновременно опциональна, досаждает пользователю, и легко отключаема — будет отключена навсегда при первом же досадном случае, что и происходит.
Ну и еще от злоупотребления опусканием скобок потому что «там одна строка всего, а тут два символа дополнительно набирать!!!». Понаступаешь на эти грабли любовно разложенные лет 5, и начинаешь ставить по три пары скобок — на всякий случай. :)
Т.к. скобки угловые забыли поставить и в макросе, и в else, то внутрь попадает только первая строка макроса, а вторая исполняется независимо от условия s->matches == 1.
Случай там довольно редкий (поэтому оно и ехало незаметно до 2018 года), но отлаживать такое было бы весьма забавно, и когда тебе о таком вот сообщает программа — это приятно.
Технология предотвращения эксплуатации переполнения буферов на стеке (название такое из за канареек, которых использовали в шахтах как индикатор уровня CO).
Определяемое на этапе исполнения значение, называемое „канарейкой“ (canary) пишется в конец стека рядом с адресом возврата. В конце каждой функции, это значение проверяется перед выполнением инструкции возврата. Если значение канарейки изменилось (по причине перезаписи в ходе переполнения), программа немедленно рухнет вместо продолжения.
Не обязательно, просто у всех запросы разные и затраты разные. То, что народ едет в Долину — нет никакого сомнения, только вот съездить поработать лет 5, заработав и деньги, и опыт, и нужные знакомства — это одно, а жить там всю жизнь — это другое совсем. Кому-то нравится, кому-то — отнюдь, я для себя уже давно решил, что вернусь в Германию в свой уютный баварский городок на Дунае, когда H-1B закончится.
Пробовал привыкнуть в местной жизни после 7 лет в Германии — бесполезно, понять еще можно более-менее, принять — нет. Еще пару лет максимум (пока жадность еще превалирует над желанием послать весь окружающий цирк в пешее эротическое) — и пошлю, видимо, возьму саббатикал на год и поеду пожить в лесу в Сибири.
Пожалуйста, изучайте свои инструменты откладки и тестирования, фаззеры, санитайзеры, и т.п. Любая ошибка, замеченная ими, значительно дешевле, чем она же, но замеченная пользователем. Если ваша система не позволяет подключить к себе отладчик во время работы — это недостаток системы, а не отладчика! Если вы не умеете пользоваться инструментами — это недостаток квалификации, а не инструментов!
Отладка кода заведомо сложнее его написания, но почему-то автор не предлагает заменить свою IDE на ed, зато предлагает оказаться от отладчика, потому что он якобы «не оказывает помощи»…
Если хотите подробностей, все это описано подробно в спецификации UEFI 2.3.1C+ в разделе Runtime Services: SetVariable.
Меня этот проект интересует потому, что на его основе сейчас создается новая версия UEFI SCT, без которой невозможно проверить конкретную реализацию UEFI-совместимой прошивки на совместимость с конкретной версией спецификации.
В BIOS Setup дата-центра действительно захожу удаленно, через IPMI и RedFish.
Мое мнение: старый текстовый интерфейс сильно лучше, чем все эти новомодные тормозящие чудеса в решете (он в текстовую консоль почти без потерь перенаправляется, к примеру, и программировать его проще, т.е. ошибок допустят меньше), но людям нравятся блестки, и потому рано или поздно без блесток не останется ничего.
2) Так и есть, и это действительно связано с тем, что некоторые UEFI OROMы сильно быстрее своих legacy-собратьев, которые вынуждены переключаться в 16-битный реальный режим и сегменты там яростно переключать, и чем больше устройств в массиве — тем заметнее разница. По честному, без бенчмарков это все — так себе аргументация, но я достаточно не люблю CSM, чтобы видеть после его отключения ускорение, пусть даже это ускорение только у меня в голове происходит.
Как только проблему подтвердят, хеш начального загрузчика Касперского (который компрометирует UEFI CA) будет добавлен в UEFI Revocation List File, который затем MS постарается распространить на все машины с ключом MS KEK (на другие он просто не установится) через Windows Update.
Проблема эта известная, радикальное решение — не доверять UEFI CA совсем (Apple и Microsoft на своих машинах поступают именно так). При этом начнутся сложности с работой OptionROM'ов внешних видеокарт и рейд-контролеров, которые в UEFI 2.4+ можно обойти при помощи SecureBoot Deployment Mode, либо подписыванием ОРОМов своими ключами и загрузкой их с диска или SPI-флеша, а не из устройства.
В общем, теоретически решения есть, и все можно сделать, если очень хотеть. Практически же, за исключением трех с половиной анонимов, UEFI SecureBoot отключен на всех ПК, потому что любая технология, которая одновременно опциональна, досаждает пользователю, и легко отключаема — будет отключена навсегда при первом же досадном случае, что и происходит.
Т.к. скобки угловые забыли поставить и в макросе, и в else, то внутрь попадает только первая строка макроса, а вторая исполняется независимо от условия s->matches == 1.
Случай там довольно редкий (поэтому оно и ехало незаметно до 2018 года), но отлаживать такое было бы весьма забавно, и когда тебе о таком вот сообщает программа — это приятно.
Цитата из статьи «Как устроены дыры в безопасности: переполнение буфера»: