Чтобы подпись отозвали, проблему надо зарепортить 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 лет в Германии — бесполезно, понять еще можно более-менее, принять — нет. Еще пару лет максимум (пока жадность еще превалирует над желанием послать весь окружающий цирк в пешее эротическое) — и пошлю, видимо, возьму саббатикал на год и поеду пожить в лесу в Сибири.
Атакуют при этом чаще всего не идею, а реализацию.
Intel BootGuard сам по себе отработал штатно, и корень доверия он вполне себе обеспечил, т.к. в PEI-томе, накрытом им, ничего никто не менял. Зато драйвер BootGuardPei, написанный кстати именно AMI, а не OEMом, проверив хеши DXE-тома и обнаружив несовпадение из с эталоном (который тоже не даст исправить именно Intel BootGuard, потому что они в файле в PEI-томе лежат) вместо того, чтобы машину завесить или перезагрузить, поставил единицу в HOB и продолжил работу. Это потом уже BootGuardDxe должен был среагировать на эту единицу и выдать пользователю надпись «хеши поломались, все пропало», но вот незадача, его удалили уже, и потому реагировать на эту сиротливую единицу стало некому.
В итоге платформа замечательно работает с модифицированным DXE-томом, цепочка доверия нарушена, все счастливы, а Gigabyte виноват только в том, что не стал перепроверять реализацию цепочки доверия, предоставленную ему IBV.
Наверняка пофиксили, да. Если поняли, если согласовали фикс с AMI, если получили обновленный референс-код, если интегрировали его, если выпустили обновление, если запретили откат на него, если пользователь это обновление поставил. Несколько многовато если, на мой взгляд.
Очень много информации, нужной для 100% правильной пересборки, в образе либо нет, либо она там в крайне неудобном виде и ее придется доставать при помощи хитрого парсинга, дизассемблера и такой-то матери. Те же номера динамических PCD или AMI'шных SDL TOKENов брать неоткуда, и потому при крупных изменениях все равно придется половину пересобирать, а отличить крупные от некрупных труднее, чем не заморачиваться и собирать каждый раз заново.
Если вы про полезное применение UEFITool, то их масса полезных уже сейчас, но в билды встраивать именно эту утилиту я все равно не стал бы, даже если результат получился бы немного быстрее, чем у нынешней билд-системы в EDK2 (которая тормозит просто забей) — надежность низкая, плюс всякие вендорские фишки поддерживаются весьма слабо.
С последним предложением я бы очень сильно поспорил, потому что в теории теория от практики тоже не отличается, а на практике всю цепочку доверия большинства IBV и OEM уже не раз обходили, и еще не раз обойдут, потому что никто вообще не заморачивается проверкой того, что занятие то действительно бесполезное. А когда начали проверять, неожиданно оказалось, что вся «защита» обходится удалением драйвера BootGuardDxe, который раньше на бит в HOBе реагировал, при помощи упомянутого уже UEFITool'а, упс.
Не надо лучше, не удаляйте все артефакты после успешной сборки, и повторная сборка много времени не займет.
Как разработчики спецификации не старались, все равно не получилось избавиться от всех горизонтальных и вертикальных связей, и потому такая «полевая хирургия» иногда работает хорошо, а иногда не работает никак.
Если бы там было тривиально, уже были бы публичные готовые решения, а пока более менее готовое что-то есть только у Педро (EfiSwissKnife).
С другой стороны, даже не готовое, кривое и на коленке — сильно лучше, чем ничего., поэтому даже такие «сугубо теоретические» статьи я поддерживаю всеми руками. Если найдете возможность выложить что-то — отлично, если нет — другим будет проще подступиться к проблеме.
Статья отличная, спасибо, но «что делать, чтобы собрать данные для графа» было в принципе ясно с самого начала, и сложность там не в отсутствии хороших идей, а в отсутствии реализаций этих хороших идей. Вот и тут видит око, а исходников нет.
Нужна эта функция на самом деле буквально паре человек, а автоматизация ее прямо в UEFITool'е потребует включения туда дизассемблера, поиска по сигнатурам и затем сотен часов отладки еще. Гораздо лучше, на мой взгляд, со стороны UT ограничится UEFIDump'ом и все дальнейшее делать скриптами для IDA/R2/Binja/чтотамувас, потому что оно все специально под подобные задачи заточено.
Если вам нужно выделить памяти с определенным выравниванием, сделайте функцию для этого, какую-нибудь VMAllocAligned(), принимающую выравнивание в качестве параметра.
Сейчас у вас в коде куча магических констант (8292 выглядит как опечатка в 8192, например), памяти выделено больше чем нужно (и потому guard page при выходе за границы может не сработать), вызов VMFree на любой из выделенных подобным образом указателей освободит что-то непонятное в большинстве случаев, а memset зануляет не весь выделенный буфер.
Вызывать прерывания, это, конечно, намного проще, чем стандартные функции через стандартный же ABI…
А PE/COFF-файл можно не только самому собрать в хекс-редакторе, но и любая фигня, способная делать исполняемые файлы для Windows это умеет уже.
Стало именно проще, причем практически везде. Если вы не хотите в это верить — дело ваше, а нам тут пока ехать надо, с мартышками или нет.
BIOS умер под собственным грузом легаси и костылей, не успев за развитием железа, и то, что пришло ему на смену — лучше во всех отношениях. Если вы думаете что это заговор мартышек — я не смогу вас переубедить.
U-boot и прочие embedded device tree вещи на АРМах привели уже к тому, что у каждой собаки свой собственный загрузчик, совместимый примерно ни с чем, при этом какой-нибудь вообще пятистадийный, и у него там внутри половина EFI, кусок линукса, тут написано вендором, тут написано сообществом, тут рыбу заворачивали.
Чем быстрее они там передут хоть на какой-то интерфейс стандартный (даже пусть это будут UEFI и ACPI, фиг с ним), тем лучше будет для их популярности и применимости, на мой взгляд.
Баян нужен был самим авторам прошивки по большей частью, потому что эта простая заглушка стала с развитием железки под ней настолько сложной, что во времена чипсета P55 там творилась уже настолько жесткая вакханалия, что у меня нет слов описать ее. JerleShannara смог бы, я думаю, если у него настроение будет.
То, что потом этот уже имеющийся баян дали загрузчикам ОС совершенно бесплатно, т.е. даром — это хорошо, а не плохо, потому что работа не пропала зря.
А этот EFI_SYSTEM_TABLE где висит? В воздухе? Уже для того, чтобы собрать бинарник, который EFI признает «своим» нужна масса тулов, просто в hexeditor'е вы этого не сделаете.
Висит в памяти, вывесил DxeCore, вам отдадут указательна на нее вторым параметром точки входа (т.е. в регистре EDX).
Нет. «На чём угодно» не получится. «Hello, world» для EFI — сложнее, чем весь BIOS первых 80386х! Во всяком случае у меня сложилось такое впечатление.
Это именно впечатление. «Hello World» для EFI выглядит вот так:
Т.е. от языка нужны следующие возможности: генерация файла PE/COFF и вызов функции с MS x64 ABI.
Про проблемны реализации EFI спорить не готов, потому что выйдет очень длинно, но проблемы именно с CMOS/NVRAM — они исключительно от желания снизить стоимость решения (т.е. не ставить дорогой CMOS SRAM заметного объема) при возросшых требованиях к нему (железо усложнилось кратно).
Как только проблему подтвердят, хеш начального загрузчика Касперского (который компрометирует 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 года), но отлаживать такое было бы весьма забавно, и когда тебе о таком вот сообщает программа — это приятно.
Цитата из статьи «Как устроены дыры в безопасности: переполнение буфера»:
Intel BootGuard сам по себе отработал штатно, и корень доверия он вполне себе обеспечил, т.к. в PEI-томе, накрытом им, ничего никто не менял. Зато драйвер BootGuardPei, написанный кстати именно AMI, а не OEMом, проверив хеши DXE-тома и обнаружив несовпадение из с эталоном (который тоже не даст исправить именно Intel BootGuard, потому что они в файле в PEI-томе лежат) вместо того, чтобы машину завесить или перезагрузить, поставил единицу в HOB и продолжил работу. Это потом уже BootGuardDxe должен был среагировать на эту единицу и выдать пользователю надпись «хеши поломались, все пропало», но вот незадача, его удалили уже, и потому реагировать на эту сиротливую единицу стало некому.
В итоге платформа замечательно работает с модифицированным DXE-томом, цепочка доверия нарушена, все счастливы, а Gigabyte виноват только в том, что не стал перепроверять реализацию цепочки доверия, предоставленную ему IBV.
Наверняка пофиксили, да. Если поняли, если согласовали фикс с AMI, если получили обновленный референс-код, если интегрировали его, если выпустили обновление, если запретили откат на него, если пользователь это обновление поставил. Несколько многовато если, на мой взгляд.
С последним предложением я бы очень сильно поспорил, потому что в теории теория от практики тоже не отличается, а на практике всю цепочку доверия большинства IBV и OEM уже не раз обходили, и еще не раз обойдут, потому что никто вообще не заморачивается проверкой того, что занятие то действительно бесполезное. А когда начали проверять, неожиданно оказалось, что вся «защита» обходится удалением драйвера BootGuardDxe, который раньше на бит в HOBе реагировал, при помощи упомянутого уже UEFITool'а, упс.
Как разработчики спецификации не старались, все равно не получилось избавиться от всех горизонтальных и вертикальных связей, и потому такая «полевая хирургия» иногда работает хорошо, а иногда не работает никак.
С другой стороны, даже не готовое, кривое и на коленке — сильно лучше, чем ничего., поэтому даже такие «сугубо теоретические» статьи я поддерживаю всеми руками. Если найдете возможность выложить что-то — отлично, если нет — другим будет проще подступиться к проблеме.
Нужна эта функция на самом деле буквально паре человек, а автоматизация ее прямо в UEFITool'е потребует включения туда дизассемблера, поиска по сигнатурам и затем сотен часов отладки еще. Гораздо лучше, на мой взгляд, со стороны UT ограничится UEFIDump'ом и все дальнейшее делать скриптами для IDA/R2/Binja/чтотамувас, потому что оно все специально под подобные задачи заточено.
Не делайте так никогда, пожалуйста.
Если вам нужно выделить памяти с определенным выравниванием, сделайте функцию для этого, какую-нибудь VMAllocAligned(), принимающую выравнивание в качестве параметра.
Сейчас у вас в коде куча магических констант (8292 выглядит как опечатка в 8192, например), памяти выделено больше чем нужно (и потому guard page при выходе за границы может не сработать), вызов VMFree на любой из выделенных подобным образом указателей освободит что-то непонятное в большинстве случаев, а memset зануляет не весь выделенный буфер.
А PE/COFF-файл можно не только самому собрать в хекс-редакторе, но и любая фигня, способная делать исполняемые файлы для Windows это умеет уже.
Стало именно проще, причем практически везде. Если вы не хотите в это верить — дело ваше, а нам тут пока ехать надо, с мартышками или нет.
BIOS умер под собственным грузом легаси и костылей, не успев за развитием железа, и то, что пришло ему на смену — лучше во всех отношениях. Если вы думаете что это заговор мартышек — я не смогу вас переубедить.
Чем быстрее они там передут хоть на какой-то интерфейс стандартный (даже пусть это будут UEFI и ACPI, фиг с ним), тем лучше будет для их популярности и применимости, на мой взгляд.
То, что потом этот уже имеющийся баян дали загрузчикам ОС совершенно бесплатно, т.е. даром — это хорошо, а не плохо, потому что работа не пропала зря.
Это именно впечатление. «Hello World» для EFI выглядит вот так:
Т.е. от языка нужны следующие возможности: генерация файла PE/COFF и вызов функции с MS x64 ABI.
Про проблемны реализации EFI спорить не готов, потому что выйдет очень длинно, но проблемы именно с CMOS/NVRAM — они исключительно от желания снизить стоимость решения (т.е. не ставить дорогой CMOS SRAM заметного объема) при возросшых требованиях к нему (железо усложнилось кратно).