"Святая святых" пошла чинить крайне серьезную проблему - загрузочные вирусы, с которыми из ОС вообще ничего не сделать, а в ответ конкуренты и "сообщество" так яростно пошло их за это шельмовать, что результат получился компромиссом ни-нам-ни-вам.
Сносить ничего не надо, нужно все загрузчики подписать своим сертификатом, не доверять предоустановленной иерархии сертификатов, и подписывать все, что прошивка может исполнять, вручную самостоятельно.
Только вот это готовы делать три с половиной анонимуса, а MS доставили защиту от загрузочных вирусов на каждый х86 ПК 13 лет назад, пусть дырявую-хреновую, но тем не менее. И буткит теперь в дикой природе найти - очень редкое событие, раз в год плюс-минус, т.е. для обычного пользователя и от дешевых атак защита вполне себе работает.
Не то, чтобы она прямо требовалась, но если коротко - потому что инфраструктура для подписывания миллирда разношерстных загрузчиков и управления сотней ключей для этого - очень дорого стоит, и потому когда Microsoft спросил всех остальных участников рынка "кто будет оплачивать банкет", других желающих почему-то не нашлось.
Там вообще надо долго рассказывать, но в итоге получилось удивительно дерьмовое решение, в котором т.н. shim подписан ключом MS (UEFI CA, которым подписана чертова прорва всего, в том числе уязвимого), сам этот shim доверяет всему, что записано в переменной MOKList, которая от перезаписи из ОС защищена (как Задорнов говорил, внимание!) отсутствием атрибута RT.
По человечески, надо всю эту бессмысленную хрень давно уже выкидывать и заново проектировать с учетом того, что на дворе 25 год, и скоро без PQC безопасную загрузку перестанут покупать. Но пока в UEFI Forum заседают три с половиной пенсионера, а за развитие EDK2 отвечают два разработчика из Intel - ничего не изменится.
Скорее всего правильный ответ - "никогда", я вообще не видел, чтобы HUAWEI что-то делала для починки уязвимостей в своих продуктах.
Я закончу этот цикл статей, и мы с @vit9696 вместе подумаем, как нам починить эту идиотскую уязвимость на всех тех миллионах устройств, которые она затрагивает, и которые без нас никто уже не починит никогда. Скорее всего, придется добавить в прошивку еще один драйвер, который будет переменную SecureFlashCertData нафиг удалять, если вдруг она нашлась и имеет неожиданные атрибуты.
Отдельно очень хочется спросить у Microsoft следующее: "господа, а вы там не охуели случайно, подписывать вашим сертификатом для загрузчиков всякое говно хрен пойми от кого"?
Сертификату MS CA 2011 по умолчанию доверяют чуть ли не вообще все системы с UEFI SecureBoot, и MS все время очень ревностно относилась к тому, что она им подписывает (пока внезапно не подписала древний и дырявый насквозь загрузчик для Windows 7, но это другая история), а тут такая оказия.
Не буду подозревать бэкдоры там, где хватит некомпетентности, но и исключать такой вариант тоже нельзя...
Самое удивительное, что Binarly раскрыли эту уязвимость 10 июня, в тот же день, что и я раскрыл свою CVE-2025-4275, и они получились идеально дополняющими друг друга.
Дело в том, что переменная IhisiParamBuffer, которая используется для эксплуатации CVE-2025-3052, на прошивках Insyde H2O защищена от записи, т.е. их эксплоит работает на всех прошивках, кроме Insyde, а мой - только на Insyde, и для обоих нужна всего лишь возможность писать в NVRAM.
Основная угроза, от которой призван защищать UEFI SB - подмена EFI-загрузчика на вредоносный и\или запуск вредоносных исполняемых файлов до либо параллельно с загрузчиком, через механизмы вроде DriverXXXX/DriverOrder, OptionROM и т.п.
В вашем примере, при правильной настройке (т.е. использовании EFI_STUB и встроенного initramfs) - защитит.
Есть мнение, что вся эта вакханалия - это способ заставить и дальше использовать arm64 и x86 на высокопроизводительных системах, потому что иначе как саботажем вот это "развитие" сложно назвать.
Пока что RISC-V отлично себя чувствует у корпораций как замена микро- и нано-ядер, на которых никакой пользовательский код никогда не должен исполняться, а для своих прошивок можно накрутить любые нестандартные расширения, хоть аналог Apple Matrix eXtension, хоть CHERI, хоть PAC, хоть MTE, и при этом не нужно каждый раз в arm чемодан бабла заносить.
Еще даже немного веселее - здесь мы претворяемся частью самой прошивки, и потому наши efi-файлы она запустит даже тогда, когда не стала бы запускать ничего другого, даже если оно в обычном режиме работы проходит все проверки UEFI SecureBoot. Я во второй части уже описал это все подробно на английском, осталось теперь написать то же самое на русском.
Надо статью писать давно уже, и про DriverXXXX, и про KeyXXXX, и про SysPrepXXXX, а то авторы спецификации потребовали, IBV молча реализовали, и никто не в курсе, кроме атакующих, очень удобно...
@ValdikSS, приколись, как они могут. Я думал, что всякую фигню UEFI CA подписывать, а потом ее героически (неправильно) банить - это максимум того, что эта "индустрия" может, но здесь Insyde превзошли и самих себя, и всех остальных. Очень веселый тамада, и очень интересные конкурсы...
Тоже столкнулся в полный рост с тем, что безопасный парсер бинарных данных на С или С++ написать очень сложно. "Боевых" библиотек для парсеров-комбинаторов нет, а то, что есть - примерно такого же качества, как тут в статье и описано, т.е. либо "заброшено", либо "автор не чинит известные уязвимости, и гордится этим".
Остановился в итоге на двух решениях, которые к парсингу подходят с разных сторон. На KaitaiStruct пишу то, что для безопасности критическим не является, и для чего удобство разработки парсера важнее его безопасности. Реально критическое по безопасности делаю на WUFFS.
Вам - ничего не хочу, потому что ваши примерны никакого отношения к простоте не имеют. Костылить строки вместо стандартных, собирать запросы вручную при наличии prepared statements, открывать API без аутентификации на всю сеть - это все не про "так проще", а про "мы вообще не в курсе, чем мы тут занимаемся, но надо сделать вчера еще, поэтому некогда объяснять - срезаем все углы".
Просто - это не значит плохо, или глупо, или недоработано, или дыряво, или еще как-то с изъяном, просто - это так, чтобы сделано было все необходимое, и не сделано было ничего лишнего. Подчеркиваю, все необходимое, и ничего лишнего. Что-то перестало быть нужным - удаляйте, removed is debugged, что-то понадобилось - добавляйте, но руководствуясь тем же принципом.
Software - оно потому и soft, что легко поддается изменениям, и бороться с неконтролируемым ростом сложности (а с ней и неконтролируемым ростом числа уязвимостей, потому что уязвимости - они тоже следствие сложности в первую очередь) в нем нужно в момент потенциального добавления этой сложности, другого момента у вас зачастую уже не будет.
Выбирай сложность согласно максимально возможному будущему развитию проекта. Ты повидал многое, ты знаешь, как случаются факапы, как случаются успешные успехи, которые не случаются потому что в кузнице не оказалось гвоздя. Ты знаешь куда ведут все модные тенденции, не стесняйся закладывать их в проект, если он может туда прийти.
Дорогой Мастер, от лица специалиста по безопасности, которому потом поручат чинить уязвимости в вашем переусложненном шедевре, покорнейше прошу вас проследовать в афедрон. Если вы умеете будущее предсказывать - бросайте дурацкое ИТ и зарабатывайте миллиарды на ставках на спорт и лотереях, а здесь сложность систем и так запредельная, чтобы ее еще дополнительно делать "на вырост". You Ain't Gonna Need It! Вы исполнитель и не принимаете управленческих решений, не знаете, как будет происходить развитие вашего продукта, не отвечаете за его судьбу, и не представляете, как дорого чинить результаты подхода "надо предусмотреть вообще все, что нам предсказывает наша внутренняя Ванга".
Из трех моих рабочих виз в США (все три - H-1B) на дополнительную проверку отправляли две, оба раза это затягивало процесс получения визы на 4 месяца. Триггер - не гражданство РФ (у меня есть еще и немецкое, и визы ставились в немецкий паспорт), а профиль работы (т.е. если назвать себя firmware security engineer - под проверку попадешь однозначно, а если low-level software developer - уже могут быть варианты). В третий раз я именно так себя и назвал, но интервьюер в Мюнхенском консульстве дополнительно уточнила, мол, у вас должность официально называется Software Engineer ICT4 - Security, скажите, а вот эта безопасность - она не про работу с критическими системами для правительства США или министерства обороны США. Нет, говорю, у меня клиренса нет, а коллегам с ним запрещено общаться со мной, чтобы не потерять свой, поэтому и я с ними не работаю, и они со мной, опасности нет. В итоге вместо 5 месяцев визу удалось получить за 20 дней.
Я работал над тем, чтобы сделать эту технологию безопасной без каких-либо "если" и "но", в течение всего 2023 года, и верю и себе, и бывшим коллегам, которые работали над ней вместе со мной. Ваше право не верить им, мне, корпорации в чужой юрисдикции - это ваше право, но "ни одна модель, ни один ассистент кода, ни одно автодополнение из интернета ваши данные конфиденциальными не оставит" - это крайне сильное утверждение, требующее доказательств.
Спасибо вам за то, что вы серьезно относитесь к безопасности ваших данных, и именно благодаря вам, и таким как вы, весь этот Apple Intelligence можно отключить одним слайдером, и он реально отключится.
Очень много очень серьезной работы было сделано для того, чтобы задачи построения таких контекстов, которые из за вычислительной сложности нельзя было выполнить локально, можно было выполнить на удаленном сервере таким образом, чтобы никто, вот прямо совсем никто, даже очень ресурсный атакующий внутри корпорации, не мог ничего сделать с ними.
Ваш покорный слуга почти год участвовал в портировании SEPOS на виртуальную машину (вместе с драйверами всех аппаратных устройств, которых, кроме как у SEP и у внутреннего cycle-accurate симулятора SEP, не было больше ни у кого).
Могу сказать искреннее большое спасибо Apple за то, что весь этот прости рандом "интеллект" отключается одним слайдером, так же, как и Siri, и остается отключенным (передаю привет идиоту из менеджмента, который продавил принудительное включение Apple Intelligence при обновлении на .3, посылаю ему лучи ураганной диареи).
Пока всякие любители прогресса и последователи истинной веры в то, что нейросети спасут их от работы, а умножение матриц поможет решить их проблемы, сетуют на то, что в их "искусственный интеллект" недокладывают интеллекта, мы тут в своем погребе спокойно ждем, пока волна идиотского хайпа наконец закончится, и корпорации перестанут тратить триллионы долларов на ерунду, от которой до сих пор на клиентских устройствах нет никакого толка, а все ее применения - либо игрушки, либо "давайте еще сильнее сломаем уже и так испорченный копирайтингом и SEO Интернет", либо крайне нишевые.
С кем бы я серьезно но обсуждал прогресс больших языковых моделей и новую волну "ИИ", практически каждый говорит о том, что в его профессиональной области знаний и навыков ИИ пока что ничего, кроме буллшита, не выдает, и потому нафиг там не нужен, но в других областях его выхлоп выглядит правдоподобно. В том то и дело, ребята! Там, где вы эксперты - вы легко отличаете специалиста от дурака, а там, где нет - уже не можете отличить так легко, а цифровой дурак специально сделан так, чтобы красиво нанизывать токены друг на друга и выглядеть правдоподобным. Иногда это интересно и полезно, но если вы начнете верить тому, что этот цифровой дурак несет - не удивляйтесь потом, что он вам посоветует ботулотоксин от простуды.
Выбирая между "релизить говно" и "отложить или отменить, если не получается не релизить говно" Apple раз за разом выбирает второе, и за это радоваться надо, в не статьи эмоциональные писать. В городе Купертино все отлично.
"Святая святых" пошла чинить крайне серьезную проблему - загрузочные вирусы, с которыми из ОС вообще ничего не сделать, а в ответ конкуренты и "сообщество" так яростно пошло их за это шельмовать, что результат получился компромиссом ни-нам-ни-вам.
Сносить ничего не надо, нужно все загрузчики подписать своим сертификатом, не доверять предоустановленной иерархии сертификатов, и подписывать все, что прошивка может исполнять, вручную самостоятельно.
Только вот это готовы делать три с половиной анонимуса, а MS доставили защиту от загрузочных вирусов на каждый х86 ПК 13 лет назад, пусть дырявую-хреновую, но тем не менее. И буткит теперь в дикой природе найти - очень редкое событие, раз в год плюс-минус, т.е. для обычного пользователя и от дешевых атак защита вполне себе работает.
Не то, чтобы она прямо требовалась, но если коротко - потому что инфраструктура для подписывания миллирда разношерстных загрузчиков и управления сотней ключей для этого - очень дорого стоит, и потому когда Microsoft спросил всех остальных участников рынка "кто будет оплачивать банкет", других желающих почему-то не нашлось.
Там вообще надо долго рассказывать, но в итоге получилось удивительно дерьмовое решение, в котором т.н. shim подписан ключом MS (UEFI CA, которым подписана чертова прорва всего, в том числе уязвимого), сам этот shim доверяет всему, что записано в переменной MOKList, которая от перезаписи из ОС защищена (как Задорнов говорил, внимание!) отсутствием атрибута RT.
По человечески, надо всю эту бессмысленную хрень давно уже выкидывать и заново проектировать с учетом того, что на дворе 25 год, и скоро без PQC безопасную загрузку перестанут покупать. Но пока в UEFI Forum заседают три с половиной пенсионера, а за развитие EDK2 отвечают два разработчика из Intel - ничего не изменится.
Скорее всего правильный ответ - "никогда", я вообще не видел, чтобы HUAWEI что-то делала для починки уязвимостей в своих продуктах.
Я закончу этот цикл статей, и мы с @vit9696 вместе подумаем, как нам починить эту идиотскую уязвимость на всех тех миллионах устройств, которые она затрагивает, и которые без нас никто уже не починит никогда. Скорее всего, придется добавить в прошивку еще один драйвер, который будет переменную SecureFlashCertData нафиг удалять, если вдруг она нашлась и имеет неожиданные атрибуты.
Отдельно очень хочется спросить у Microsoft следующее: "господа, а вы там не охуели случайно, подписывать вашим сертификатом для загрузчиков всякое говно хрен пойми от кого"?
Сертификату MS CA 2011 по умолчанию доверяют чуть ли не вообще все системы с UEFI SecureBoot, и MS все время очень ревностно относилась к тому, что она им подписывает (пока внезапно не подписала древний и дырявый насквозь загрузчик для Windows 7, но это другая история), а тут такая оказия.
Не буду подозревать бэкдоры там, где хватит некомпетентности, но и исключать такой вариант тоже нельзя...
Самое удивительное, что Binarly раскрыли эту уязвимость 10 июня, в тот же день, что и я раскрыл свою CVE-2025-4275, и они получились идеально дополняющими друг друга.
Дело в том, что переменная IhisiParamBuffer, которая используется для эксплуатации CVE-2025-3052, на прошивках Insyde H2O защищена от записи, т.е. их эксплоит работает на всех прошивках, кроме Insyde, а мой - только на Insyde, и для обоих нужна всего лишь возможность писать в NVRAM.
Основная угроза, от которой призван защищать UEFI SB - подмена EFI-загрузчика на вредоносный и\или запуск вредоносных исполняемых файлов до либо параллельно с загрузчиком, через механизмы вроде DriverXXXX/DriverOrder, OptionROM и т.п.
В вашем примере, при правильной настройке (т.е. использовании EFI_STUB и встроенного initramfs) - защитит.
Написал, вот она: https://habr.com/ru/articles/918192/
Есть мнение, что вся эта вакханалия - это способ заставить и дальше использовать arm64 и x86 на высокопроизводительных системах, потому что иначе как саботажем вот это "развитие" сложно назвать.
Пока что RISC-V отлично себя чувствует у корпораций как замена микро- и нано-ядер, на которых никакой пользовательский код никогда не должен исполняться, а для своих прошивок можно накрутить любые нестандартные расширения, хоть аналог Apple Matrix eXtension, хоть CHERI, хоть PAC, хоть MTE, и при этом не нужно каждый раз в arm чемодан бабла заносить.
Еще даже немного веселее - здесь мы претворяемся частью самой прошивки, и потому наши efi-файлы она запустит даже тогда, когда не стала бы запускать ничего другого, даже если оно в обычном режиме работы проходит все проверки UEFI SecureBoot. Я во второй части уже описал это все подробно на английском, осталось теперь написать то же самое на русском.
Надо статью писать давно уже, и про DriverXXXX, и про KeyXXXX, и про SysPrepXXXX, а то авторы спецификации потребовали, IBV молча реализовали, и никто не в курсе, кроме атакующих, очень удобно...
Вторая часть на английском, русскую версию напишу чуть позже.
@ValdikSS, приколись, как они могут. Я думал, что всякую фигню UEFI CA подписывать, а потом ее героически (неправильно) банить - это максимум того, что эта "индустрия" может, но здесь Insyde превзошли и самих себя, и всех остальных. Очень веселый тамада, и очень интересные конкурсы...
Тоже столкнулся в полный рост с тем, что безопасный парсер бинарных данных на С или С++ написать очень сложно. "Боевых" библиотек для парсеров-комбинаторов нет, а то, что есть - примерно такого же качества, как тут в статье и описано, т.е. либо "заброшено", либо "автор не чинит известные уязвимости, и гордится этим".
Остановился в итоге на двух решениях, которые к парсингу подходят с разных сторон. На KaitaiStruct пишу то, что для безопасности критическим не является, и для чего удобство разработки парсера важнее его безопасности. Реально критическое по безопасности делаю на WUFFS.
Вам - ничего не хочу, потому что ваши примерны никакого отношения к простоте не имеют. Костылить строки вместо стандартных, собирать запросы вручную при наличии prepared statements, открывать API без аутентификации на всю сеть - это все не про "так проще", а про "мы вообще не в курсе, чем мы тут занимаемся, но надо сделать вчера еще, поэтому некогда объяснять - срезаем все углы".
Просто - это не значит плохо, или глупо, или недоработано, или дыряво, или еще как-то с изъяном, просто - это так, чтобы сделано было все необходимое, и не сделано было ничего лишнего. Подчеркиваю, все необходимое, и ничего лишнего. Что-то перестало быть нужным - удаляйте, removed is debugged, что-то понадобилось - добавляйте, но руководствуясь тем же принципом.
Software - оно потому и soft, что легко поддается изменениям, и бороться с неконтролируемым ростом сложности (а с ней и неконтролируемым ростом числа уязвимостей, потому что уязвимости - они тоже следствие сложности в первую очередь) в нем нужно в момент потенциального добавления этой сложности, другого момента у вас зачастую уже не будет.
Дорогой Мастер, от лица специалиста по безопасности, которому потом поручат чинить уязвимости в вашем переусложненном шедевре, покорнейше прошу вас проследовать в афедрон. Если вы умеете будущее предсказывать - бросайте дурацкое ИТ и зарабатывайте миллиарды на ставках на спорт и лотереях, а здесь сложность систем и так запредельная, чтобы ее еще дополнительно делать "на вырост". You Ain't Gonna Need It!
Вы исполнитель и не принимаете управленческих решений, не знаете, как будет происходить развитие вашего продукта, не отвечаете за его судьбу, и не представляете, как дорого чинить результаты подхода "надо предусмотреть вообще все, что нам предсказывает наша внутренняя Ванга".
Из трех моих рабочих виз в США (все три - H-1B) на дополнительную проверку отправляли две, оба раза это затягивало процесс получения визы на 4 месяца. Триггер - не гражданство РФ (у меня есть еще и немецкое, и визы ставились в немецкий паспорт), а профиль работы (т.е. если назвать себя firmware security engineer - под проверку попадешь однозначно, а если low-level software developer - уже могут быть варианты). В третий раз я именно так себя и назвал, но интервьюер в Мюнхенском консульстве дополнительно уточнила, мол, у вас должность официально называется Software Engineer ICT4 - Security, скажите, а вот эта безопасность - она не про работу с критическими системами для правительства США или министерства обороны США. Нет, говорю, у меня клиренса нет, а коллегам с ним запрещено общаться со мной, чтобы не потерять свой, поэтому и я с ними не работаю, и они со мной, опасности нет. В итоге вместо 5 месяцев визу удалось получить за 20 дней.
Я работал над тем, чтобы сделать эту технологию безопасной без каких-либо "если" и "но", в течение всего 2023 года, и верю и себе, и бывшим коллегам, которые работали над ней вместе со мной. Ваше право не верить им, мне, корпорации в чужой юрисдикции - это ваше право, но "ни одна модель, ни один ассистент кода, ни одно автодополнение из интернета ваши данные конфиденциальными не оставит" - это крайне сильное утверждение, требующее доказательств.
Спасибо вам за то, что вы серьезно относитесь к безопасности ваших данных, и именно благодаря вам, и таким как вы, весь этот Apple Intelligence можно отключить одним слайдером, и он реально отключится.
[Citation Needed] (tm). Пожалуйста найдите способ вынуть ваши данные из Private Cloud Compute и получите неплохую прибавку к зарплате.
Очень много очень серьезной работы было сделано для того, чтобы задачи построения таких контекстов, которые из за вычислительной сложности нельзя было выполнить локально, можно было выполнить на удаленном сервере таким образом, чтобы никто, вот прямо совсем никто, даже очень ресурсный атакующий внутри корпорации, не мог ничего сделать с ними.
Ваш покорный слуга почти год участвовал в портировании SEPOS на виртуальную машину (вместе с драйверами всех аппаратных устройств, которых, кроме как у SEP и у внутреннего cycle-accurate симулятора SEP, не было больше ни у кого).
В итоге эта работа стала частью виртуальной системы vresearch101, которая позволит независимым исследователям проверить обещания Apple, найти уязвимости и получить за них награду.
Могу сказать искреннее большое спасибо Apple за то, что весь этот прости рандом "интеллект" отключается одним слайдером, так же, как и Siri, и остается отключенным (передаю привет идиоту из менеджмента, который продавил принудительное включение Apple Intelligence при обновлении на .3, посылаю ему лучи ураганной диареи).
Пока всякие любители прогресса и последователи истинной веры в то, что нейросети спасут их от работы, а умножение матриц поможет решить их проблемы, сетуют на то, что в их "искусственный интеллект" недокладывают интеллекта, мы тут в своем погребе спокойно ждем, пока волна идиотского хайпа наконец закончится, и корпорации перестанут тратить триллионы долларов на ерунду, от которой до сих пор на клиентских устройствах нет никакого толка, а все ее применения - либо игрушки, либо "давайте еще сильнее сломаем уже и так испорченный копирайтингом и SEO Интернет", либо крайне нишевые.
С кем бы я серьезно но обсуждал прогресс больших языковых моделей и новую волну "ИИ", практически каждый говорит о том, что в его профессиональной области знаний и навыков ИИ пока что ничего, кроме буллшита, не выдает, и потому нафиг там не нужен, но в других областях его выхлоп выглядит правдоподобно. В том то и дело, ребята! Там, где вы эксперты - вы легко отличаете специалиста от дурака, а там, где нет - уже не можете отличить так легко, а цифровой дурак специально сделан так, чтобы красиво нанизывать токены друг на друга и выглядеть правдоподобным. Иногда это интересно и полезно, но если вы начнете верить тому, что этот цифровой дурак несет - не удивляйтесь потом, что он вам посоветует ботулотоксин от простуды.
Выбирая между "релизить говно" и "отложить или отменить, если не получается не релизить говно" Apple раз за разом выбирает второе, и за это радоваться надо, в не статьи эмоциональные писать. В городе Купертино все отлично.