Я только что сделал офер человеку в 51. Стараюсь даже не смотреть на возраст, пока не пообщаюсь с человеком. Встречал как ленивых зануд в 25, так и активных людей в 50+.
Тут скорее проблема в том, что включенные исключения, даже если их никто не кидает, порождают лэндинг пады, т.е. избыточный код. RTTI порождает кучу дополнительной информации. Все это кардинально усложняет linker-скрипты и т.д.
Я видал несколько реализаций std под МК. Конечно, они не 100% соответствуют стандарту.
А еще без исключений, без RTTI (dynamic_cast) и т.д.
На stack overflow множество раз обсуждали почему плохо писать на C++ ядерные драйвера, это же относится и к МК. Вывод во всех эти обсуждениях простой: писать можно, но приходится быть очень осторожным и надо неплохо понимать, что же генерирует компилятор при использовании тех или иных конструкций C++.
Вот ссылка на стандарт, в котором можете прочитать главы 7.6.8 и 7.6.9. Стирание проводится кардинально быстрее, чем забивание нулями через команды записи, так как данные реально передавать через относительно медленный интерфейс не надо.
В emmc встроен контроллер, балансирующий запись между ячейками NAND'а. В процессе работы часть ячеек начинает отмирать и они помечаются как неиспользуемые, но в них остается информация. Т.е. если шифрование не было включено изначально, то эти ячейки на всегда сохранят ваши данные. Правда восстановить их оттуда не так тривиально :)
Надо будет написать статью про современные АПМДЗ как-нибудь, а то много заблуждений основанных на опыте общения со старинными DOS'овыми железками бытует :)
Странные у вас регуляторы. У нас в рамках всех СЗИ (и Win и Linux) есть Authentication Package и PAM-модули для SSO и даже релогина замковых пользователей, включая удаленную аутентификацию, смену аутентифицирующей информации и т.д.
Про цену — это абсолютно верно. Аппаратные замки оправданы только начиная с класса КС3, а таких систем не так уж и много.
является сильным преувеличением.
Если бы Вы сказали «Предзагрузочный контроль целостности пораждает ряд векторов атак, которых нет в Secure Boot», это было бы гораздо ближе к правде.
Очень хорошо, что Вы про них знаете. Но я не вижу принципиальных сложностьей в борьбе с ними.
2. Я Вам верю, что ошибся, так как действительно лично не изучал как работает winload с реестром, а воспользовался информацией полученной от коллег. Большое спасибо, что Вы изучили и об этом рассказали. Тем не менее, даже учитывая, что winload работает с логом транзакций, я не вижу принципиальной сложности в реализации. Если сложно транзакции имплементировать можно просто удалять лог для проверяемых веток или помечать ветку чистой (поправив sequence + чексумму). Запись в них в нормальной работе СЗИ произвоится все равно не должна.
3. В моем понимани, единственное что должен гарантировать АПМДЗ с точки зрения контроля целостности — это то, что СЗИ работающее в Windows получит управление. Я уже указал, что для СЗИ под Windows сейчас работает подход с виртуализацией, а для Linux СЗИ встроенно в ядро, поэтому достаточно контролировать его и initramfs перед kexec'ом.
4. Актуальней будет, если вы укажете на разницу при использовании Linux. До этого вы писали про разные версии драйверов/ядер, а я не понял к чему это, так как АПМДЗ контролирует только то, что грузит в память, во время kexec -l, т.е. ядро и initramfs. В моем понимании это никак не отличается от Secure Boot.
5. Какой вы можете предложить альтернативный путь? Переписать винду/отказаться от винды? Так этим путем и идет наше государство, пересаживаясь на Linux.
6. Если Вы этот разговор закончили, хотел бы сказать большое спасибо, было позновательно и интересно. Побольше бы таких осведомленных комментаторов.
АПМДЗ является частым случаем реализации одной из стадий поэтапного контроля. Это такой же кусок кода, как и сам winload. Они одновременно находятся в одной и той же памяти и исполняются одновременно на одном уровне привелегий. От того, что вы расположите их в одном PE или в разных ничего не поменяется.
Еще раз повторю: вы говорите о различиях в реализации парсинга в winload'е и АПМДЗ, что является частным случаем ошибки/уязвимости. Точно такие же ошибки есть в любом коде, будь то Secure Boot или любая другая система защиты.
Есть множество статей о реальных уязвимостях в конкретных реализациях Secure Boot'а.
Ничего не мешает АПМДЗ проверять целостность реестра и наличие драйвера СЗИ уже в памяти по ExitBootServices. Можно использовать для проверки реестра в памяти куски кода winload'а, вызывая их из своего UEFI-модуля. Можно исполнять все, вплоть до получения управления драйвером в тонком гипервизоре (blue pill/bitvisor) и контролировать целостность всех исполняемых страниц памяти при их вызове (ага, мы так умеем). Можно написать свой загрузчик винды, который будет использовать тот же код (ReactOS'овский XP грузил на ура). На любой названный вами вектор атаки я всегда смогу ответить методом защиты. Это обычное соревнование брони и снаряда. Вы будете усложнять потенциальные атаки, а я защиту, а остановится это там, где разработка методов атаки станет слишком дорогой.
Также учтите, что ФСБ, например, выдает заключение на винду только в составе с конкретным СЗИ. Т.е. рассматривается всегда комплекс: АПМДЗ, СЗИ, среда функционирования (ОС + Железо).
Если вдруг Вы хотите ответ по конкретным предложенным атакам, хотя это ничего и не доказывает, то вот:
winload не умеет в файлы транзакций, так что ничем не отличается даже от аккорда. Незакрытые транзации закроет уже ядро, а все бутовые драйвера, загруженные winload'ом, получат управление.
В модель угроз не входит возможность исполнить код в ядре, а без этого вы NTFS не поломаете. Ни одно СЗИ на (не только Российское) не сможет защититься от кода на том же уровне привелегий. Для систем выше КС3 требуется обеспечение замкнутости программной среды, т.е. СЗИ проверяет ВЕСЬ исполняемый в системе код, а не только код, исполняемый в ядре. КС3 и ниже — тупой ленивый нарушитель. Уязвимости (и в ядре и в юзер моде) рассматриваются как нечто обязательно присутствующее и, согласно современным требованиям, любые СЗИ + ОС обязаны реализовывать меры по снижению вероятности эксплуатации: CFG, ASLR и т.д. Все понимают, что абсолютной защиты небывает.
Я не знаю ниодного сертифицированного дистрибутива с СЗИ, использующего dracut. Но если есть опубликованная уязвимость или документированная возможность, позволяющая «на лету заменить ядро», при сертификации это бы закрыли.
Ничего не забыл? Т.е. ни одна из предложенных вами атак в реальной жизни не сработает. Это вовсе не означает, что вы не сможете найти уязвимость.
сводится к банальной проблеме останова, теореме Райса и т.д. Т.е. вы апелируете к тому, что в конкретных реализациях (ntfs-3g vs ntfs.sys) есть разница в реализации (в любом нетривиальном коде наверняка есть хотя бы одна ошибка).
2. Не вижу никакой разницы между Secure Boot и нормально реализованным КЦ в АПМДЗ, за исключением обозначенной выше проблемы вскрытия корпуса, которая в нормальных системах исключается другими мерами. И то и другое — модули UEFI, работающие в один и тот же момент времени. Почему вы считаете, что в модуле Secure Boot не может быть уязвимостей, а в таком же модуле UEFI, загружающемся из Option ROM обязательно будут? На всякий случай уточню, что АПМДЗ точно также может проверять целостность загрузчика уже после загрузки в память.
3. Я не могу отвечать за все СЗИ под Windows на Российском рынке, но то, что я разрабатываю, работает больше похоже на Secure Boot: наш АПМДЗ контролирует целостность загрузчика, ядра и веток реестра, которые парсит загрузчик, а потом стартует наш бутовый драйвер, который контролирует целостность остального уже с использованием виндовых драйверов/функций ядра.
На всякий случай уточню, что изначально реестр винды грузит и парсит winload, а не ядро, вычитывая оттуда список бутовых драйверов, к которым относятся и все средства защиты.
4. Большая часть разрабатываемых и внедряемых на текущий момент систем в гос-секторе (где и применяются сертифицированные СЗИ), делаются на Linux'ах, так как Майкрософту запретили продавать винды во многие наши госы. В этом случае АПМДЗ контролирует целостность ядра и initramfs (в котором СЗИ реализовано в виде LSM-модуля), а потом делает в него kexec, без всяких загрузчиков. Драйвера файловых систем в АПМДЗ и целевом Linux'е, как вы понимаете, одинаковые.
5. Все системы под максимальную модель нарушителя теперь строятся только на верифицируемой (читай отечественной) элементной базе, т.е. на базе интеловских процов с ME, ISH и другими плюшками, можно построить только систему под внутреннего нарушителя с моделью из КС3 (читай «тупой и ленивый нарушитель»). А на Эльбрусьях, например, вместо Secure Boot есть наш АПМДЗ, который грузит Linux kexec'ом.
6. Не бывает абсолютной защиты. Бывает защита, пробивание которой стоит дороже, чем данные, которые она защищает.
Если отличий в реализации парсера реестра / драйвера NTFS в АПМДЗ и winload'е будет мало, а их поиск будет слишком дорогим, то проще будет выбрать другой вектор атаки. В конце концов, там после АПМДЗ еще и целиковая винда будет работать. Где проще найти/спрятать уязвимость, в АПМДЗ или в ядре винды?
7.
Но это же столько отечественных научных работ по доверенной загрузке нужно признать несостоятельными.
Прошу прощения, но звучит как будто все кто занимается разработкой отечественных систем защиты — тупые, а один вы Дартаньян :) Все понимают, что у АПМДЗ есть минусы, но пока у нас в стране нет своей элементной базы с собственным Secure Boot'ом и поэтессами, ничего лучше пока никто не предложил.
Извините, не совсем понял, могли бы пояснить? До запуска основной ОС можно контролировать целостность из модуля UEFI (Secure Boot?), из аппаратного модуля с Option ROM, из загрузчика, лежащего на аппаратно-ридонли флешке, установленной внутри корпуса и т.д. Если рассматривать возможность вскрытия корпуса, то, конечно, защита возможна только относительная (корневой ключ, зашитый в проц на производстве и надежда, что Китайцы не смогут выпустить свой процессор, но с другим ключем).
Я не очень понимаю, почему нельзя написать код, который будет повторять парсинг того, что контролируется? Я могу просто воспользоваться тем же драйвером, что и винда :) РеактОС вон грузит виндовые драйвера, что мешает то же самое сделать в контролирующем компоненте?
Я, например, не знал, что «про ФСТЭК уже обсуждалось», а в статье этого не увидел.
Вы говорите правильные вещи, которые надо было указать в статье, чтобы она собрала плюсов:
— на что сертифицировано данное изделие
— модель угроз со ссылкой на правила пользования изделием
— методики тестирования с описанием вашего стенда
— ваши предложения по улучшению данной системы и т.д.
Если сделать статью более системной, отношение к ней может измениться как у читателей, так и у производителя.
На мой взгляд, на текущий момент и статья и реакция производителя слишком эмоциональны, что в таких вопросах явно лишнее.
Прошу прощения, но если Ваш нарушитель может тыкнуть мышкой и удалить часть системных файлов СЗИ, что ему мешает тыкнуть в иконку «специальной тулзы производителя»? Или я неправильно понял вектор атаки?
Я видал несколько реализаций std под МК. Конечно, они не 100% соответствуют стандарту.
На stack overflow множество раз обсуждали почему плохо писать на C++ ядерные драйвера, это же относится и к МК. Вывод во всех эти обсуждениях простой: писать можно, но приходится быть очень осторожным и надо неплохо понимать, что же генерирует компилятор при использовании тех или иных конструкций C++.
Странные у вас регуляторы. У нас в рамках всех СЗИ (и Win и Linux) есть Authentication Package и PAM-модули для SSO и даже релогина замковых пользователей, включая удаленную аутентификацию, смену аутентифицирующей информации и т.д.
Про цену — это абсолютно верно. Аппаратные замки оправданы только начиная с класса КС3, а таких систем не так уж и много.
является сильным преувеличением.
Если бы Вы сказали «Предзагрузочный контроль целостности пораждает ряд векторов атак, которых нет в Secure Boot», это было бы гораздо ближе к правде.
Очень хорошо, что Вы про них знаете. Но я не вижу принципиальных сложностьей в борьбе с ними.
2. Я Вам верю, что ошибся, так как действительно лично не изучал как работает winload с реестром, а воспользовался информацией полученной от коллег. Большое спасибо, что Вы изучили и об этом рассказали. Тем не менее, даже учитывая, что winload работает с логом транзакций, я не вижу принципиальной сложности в реализации. Если сложно транзакции имплементировать можно просто удалять лог для проверяемых веток или помечать ветку чистой (поправив sequence + чексумму). Запись в них в нормальной работе СЗИ произвоится все равно не должна.
3. В моем понимани, единственное что должен гарантировать АПМДЗ с точки зрения контроля целостности — это то, что СЗИ работающее в Windows получит управление. Я уже указал, что для СЗИ под Windows сейчас работает подход с виртуализацией, а для Linux СЗИ встроенно в ядро, поэтому достаточно контролировать его и initramfs перед kexec'ом.
4. Актуальней будет, если вы укажете на разницу при использовании Linux. До этого вы писали про разные версии драйверов/ядер, а я не понял к чему это, так как АПМДЗ контролирует только то, что грузит в память, во время kexec -l, т.е. ядро и initramfs. В моем понимании это никак не отличается от Secure Boot.
5. Какой вы можете предложить альтернативный путь? Переписать винду/отказаться от винды? Так этим путем и идет наше государство, пересаживаясь на Linux.
6. Если Вы этот разговор закончили, хотел бы сказать большое спасибо, было позновательно и интересно. Побольше бы таких осведомленных комментаторов.
АПМДЗ является частым случаем реализации одной из стадий поэтапного контроля. Это такой же кусок кода, как и сам winload. Они одновременно находятся в одной и той же памяти и исполняются одновременно на одном уровне привелегий. От того, что вы расположите их в одном PE или в разных ничего не поменяется.
Еще раз повторю: вы говорите о различиях в реализации парсинга в winload'е и АПМДЗ, что является частным случаем ошибки/уязвимости. Точно такие же ошибки есть в любом коде, будь то Secure Boot или любая другая система защиты.
Есть множество статей о реальных уязвимостях в конкретных реализациях Secure Boot'а.
Ничего не мешает АПМДЗ проверять целостность реестра и наличие драйвера СЗИ уже в памяти по ExitBootServices. Можно использовать для проверки реестра в памяти куски кода winload'а, вызывая их из своего UEFI-модуля. Можно исполнять все, вплоть до получения управления драйвером в тонком гипервизоре (blue pill/bitvisor) и контролировать целостность всех исполняемых страниц памяти при их вызове (ага, мы так умеем). Можно написать свой загрузчик винды, который будет использовать тот же код (ReactOS'овский XP грузил на ура). На любой названный вами вектор атаки я всегда смогу ответить методом защиты. Это обычное соревнование брони и снаряда. Вы будете усложнять потенциальные атаки, а я защиту, а остановится это там, где разработка методов атаки станет слишком дорогой.
Также учтите, что ФСБ, например, выдает заключение на винду только в составе с конкретным СЗИ. Т.е. рассматривается всегда комплекс: АПМДЗ, СЗИ, среда функционирования (ОС + Железо).
Если вдруг Вы хотите ответ по конкретным предложенным атакам, хотя это ничего и не доказывает, то вот:
winload не умеет в файлы транзакций, так что ничем не отличается даже от аккорда. Незакрытые транзации закроет уже ядро, а все бутовые драйвера, загруженные winload'ом, получат управление.
В модель угроз не входит возможность исполнить код в ядре, а без этого вы NTFS не поломаете. Ни одно СЗИ на (не только Российское) не сможет защититься от кода на том же уровне привелегий. Для систем выше КС3 требуется обеспечение замкнутости программной среды, т.е. СЗИ проверяет ВЕСЬ исполняемый в системе код, а не только код, исполняемый в ядре. КС3 и ниже — тупой ленивый нарушитель. Уязвимости (и в ядре и в юзер моде) рассматриваются как нечто обязательно присутствующее и, согласно современным требованиям, любые СЗИ + ОС обязаны реализовывать меры по снижению вероятности эксплуатации: CFG, ASLR и т.д. Все понимают, что абсолютной защиты небывает.
Я не знаю ниодного сертифицированного дистрибутива с СЗИ, использующего dracut. Но если есть опубликованная уязвимость или документированная возможность, позволяющая «на лету заменить ядро», при сертификации это бы закрыли.
Ничего не забыл? Т.е. ни одна из предложенных вами атак в реальной жизни не сработает. Это вовсе не означает, что вы не сможете найти уязвимость.
2. Не вижу никакой разницы между Secure Boot и нормально реализованным КЦ в АПМДЗ, за исключением обозначенной выше проблемы вскрытия корпуса, которая в нормальных системах исключается другими мерами. И то и другое — модули UEFI, работающие в один и тот же момент времени. Почему вы считаете, что в модуле Secure Boot не может быть уязвимостей, а в таком же модуле UEFI, загружающемся из Option ROM обязательно будут? На всякий случай уточню, что АПМДЗ точно также может проверять целостность загрузчика уже после загрузки в память.
3. Я не могу отвечать за все СЗИ под Windows на Российском рынке, но то, что я разрабатываю, работает больше похоже на Secure Boot: наш АПМДЗ контролирует целостность загрузчика, ядра и веток реестра, которые парсит загрузчик, а потом стартует наш бутовый драйвер, который контролирует целостность остального уже с использованием виндовых драйверов/функций ядра.
На всякий случай уточню, что изначально реестр винды грузит и парсит winload, а не ядро, вычитывая оттуда список бутовых драйверов, к которым относятся и все средства защиты.
4. Большая часть разрабатываемых и внедряемых на текущий момент систем в гос-секторе (где и применяются сертифицированные СЗИ), делаются на Linux'ах, так как Майкрософту запретили продавать винды во многие наши госы. В этом случае АПМДЗ контролирует целостность ядра и initramfs (в котором СЗИ реализовано в виде LSM-модуля), а потом делает в него kexec, без всяких загрузчиков. Драйвера файловых систем в АПМДЗ и целевом Linux'е, как вы понимаете, одинаковые.
5. Все системы под максимальную модель нарушителя теперь строятся только на верифицируемой (читай отечественной) элементной базе, т.е. на базе интеловских процов с ME, ISH и другими плюшками, можно построить только систему под внутреннего нарушителя с моделью из КС3 (читай «тупой и ленивый нарушитель»). А на Эльбрусьях, например, вместо Secure Boot есть наш АПМДЗ, который грузит Linux kexec'ом.
6. Не бывает абсолютной защиты. Бывает защита, пробивание которой стоит дороже, чем данные, которые она защищает.
Если отличий в реализации парсера реестра / драйвера NTFS в АПМДЗ и winload'е будет мало, а их поиск будет слишком дорогим, то проще будет выбрать другой вектор атаки. В конце концов, там после АПМДЗ еще и целиковая винда будет работать. Где проще найти/спрятать уязвимость, в АПМДЗ или в ядре винды?
7.
Прошу прощения, но звучит как будто все кто занимается разработкой отечественных систем защиты — тупые, а один вы Дартаньян :) Все понимают, что у АПМДЗ есть минусы, но пока у нас в стране нет своей элементной базы с собственным Secure Boot'ом и поэтессами, ничего лучше пока никто не предложил.
Я не очень понимаю, почему нельзя написать код, который будет повторять парсинг того, что контролируется? Я могу просто воспользоваться тем же драйвером, что и винда :) РеактОС вон грузит виндовые драйвера, что мешает то же самое сделать в контролирующем компоненте?
Вы говорите правильные вещи, которые надо было указать в статье, чтобы она собрала плюсов:
— на что сертифицировано данное изделие
— модель угроз со ссылкой на правила пользования изделием
— методики тестирования с описанием вашего стенда
— ваши предложения по улучшению данной системы и т.д.
Если сделать статью более системной, отношение к ней может измениться как у читателей, так и у производителя.
На мой взгляд, на текущий момент и статья и реакция производителя слишком эмоциональны, что в таких вопросах явно лишнее.