В Windows Vista ограничат доступ к ядру

[SDA]

В операционной системе Windows Vista, а также последующих версиях программных платформ Microsoft для 64-разрядных компьютеров появятся специальные средства безопасности, ограничивающие доступ приложений к ядру ОС. Запуск программного кода на уровне ядра в 64-битной версии Windows Vista будет возможен только в том случае, если этот код имеет специальную цифровую подпись. Основная цель данной инициативы заключается в том, чтобы предотвратить распространение вредоносного программного обеспечения. В Microsoft полагают, что цифровая подпись станет своеобразной гарантией того, что инсталлируемый пакет соответствует требованиям безопасности. Кроме того, в случае возникновения проблемы корпорация сможет проанализировать отчет об ошибке и на основании подписей установить, какое ПО виновато в возникновении сбоя.

Предполагается, что процедуре обязательной сертификации подвергнутся, прежде всего, драйверы. При этом даже пользователи с привилегиями администраторов не смогут установить или запустить не имеющий цифровой подписи программный код на уровне ядра операционной системы. Таким образом, всем сторонним разработчикам, чьи программные продукты или их отдельные модули, использующие режим ядра (kernel-mode), не имеют цифровой подписи, предстоит пройти процедуру сертификации Publisher Identity Certificate (PIC). И только после получения сертификата соответствующее программное обеспечение сможет взаимодействовать с 64-разрядными версиями Windows.

xakep.ru

[Xen]

Твою мать

[orvman]

Запуск программного кода на уровне ядра в 64-битной версии Windows Vista будет возможен только в том случае, если этот код имеет специальную цифровую подпись.

Я как сисадмин заявляю - маяться теперь будем долго при инсталлах и т.д... А нашим работодателям теперь придется выбрасывать все старые девайсы (которых уже в продаже нет) и закупать новые. И куда всё это складывать? Эх...

[Xen]

Ну к тому времени, к какому 64-битные платформы с Вистой получит достаточное распространение, поддержка девайсов будет, скорее всего, обеспечена. Другое дело, что одиночным кернел-девелоперам придется закупаться серфами

[orvman]

Согласен. Первое время будет полный пипец. Эти бессонные ночи и факи с машинами..., а потом несовместимость. А как быть, если у меня принтер или сканер выпущен год назад, а техподдержка для этих моделей самими производителями уже не ведется? И в тоже самое время на машине крутится софт, который будет работать только на этой ОС.
Теперь надо осмотрительно брать девайсы и известных фирм и не гоняться где дешевле... Впрочем, люди уже это скоро сами поймут.

[pig]

одиночным кернел-девелоперам придется закупаться серфами

Почти уверен, что довольно скоро кто-нибудь класса Benny напишет и сертифицирует драйвер, позволяющий обходить эту защиту. Или генератор сертификатов.

[Xen]

Если подписанный продукт уличают в чем-то незаконном или просто некорректном, сертификат отзывается. Так что и предложения о "частных" подписях стороннего бинарника - дело рискованное...

[Sanja]

Сломают хакеры... руткит.ком похимичит Ж)) Иначе такое накроется Ж)))

[Sanja]

>чем-то незаконном или просто некорректном, сертификат отзывается

Уж ненамекаеш ли ты что сертефикаты через и-нет проверятся будут - бред Ж) будет 1 сертификат на все... есть нету.. а если есть права админа можно файлики пропитчить.. а там и проверка отменится... прорвемся!

[Geser]

Уж ненамекаеш ли ты что сертефикаты через и-нет проверятся будут - бред

НУ почему же бред? Через пару лет с компьютером не подключенным к интернету делать будет нечего.

[aintrust]

Парни, чтобы снять большинство вопросов, которые вы поднимаете, очень советую прочитать первоисточник, который находится вот тут: http://www.microsoft.com/whdc/system...kmsigning.mspx.

В частности, там написано следующее:
---
To increase the safety and stability of the Microsoft Windows platform, beginning with Windows Vista:
• Users who are not administrators cannot install unsigned device drivers.
• Drivers must be signed for devices that stream protected content. This includes audio drivers that use Protected User Mode Audio (PUMA) and Protected Audio Path (PAP), and video device drivers that handle protected video path-output protection management (PVP-OPM) commands.
• Unsigned kernel-mode software will not load and will not run on x64-based systems.
Note: Even users with administrator privileges cannot load unsigned kernel-mode code on x64-based systems. This applies for any software module that loads in kernel mode, including device drivers, filter drivers, and kernel services.
• To optimize the performance of driver verification at boot time, boot-driver binaries must have an embedded Publisher Identity Certificate (PIC) in addition to the signed .cat file for the package.
---

Во-первых, речь прежде всего идет о технологии подписывания драйверов (т.н., Driver signing), которая уже давно используется в Windows (еще начиная с Windows 98, как это ни парадоксально звучит!), так что совсем не нужно гадать, будут или нет сертификаты проверяться через Интернет!
Во-вторых, в 32-битной версии Vista (а на сегодняшний день на рынке присутствует львиная доля именно 32-битных драйверов!) можно будет совершенно спокойно установить (если вы, конечно, уверены в его работоспособности под новой операционкой) неподписанный драйвер (таким образом, к примеру, я поставил дрова для "левой" сетевой карты), если вы работаете под учетной записью Администратора.
В-третьих, только в x64-версии Vista нельзя будет поставить (теоретически, в нормальном режиме работы ОС, - ни при каких условиях!) неподписанный драйвер, а если он используется еще и во время загрузки - тогда дополнительно потребуется PIC. Помимо это, для целей разработки/отладки будет введена дополнительная опция в списке опций, вызываемых при загрузке по клавише F8, "Disable Driver Signature Enforcement", работающая на один сеанс, которая позволит "смягчить" вышеуказанные требования к драйверам.

Вывод: а что, собственно, плохого или страшного в таком подходе? Я вообще не вижу в этом ничего революционного: Microsoft постоянно придумывает что-то новенькое, что, по ее мнению, повышает надежность и устойчивость системы. И это просто один из таких шагов, только и всего!

PS. А статейку эту от Microsoft все-таки прочтите (она небольшая - всего 13 страничек в Word-е) - очень полезное и занимательное занятие, особенно для тех, кого интересуют подробности. Да и многие вопросы снимутся сами собой!

[Xen]

Да внатуре прорвемся, не кипешуем, пацаны ;-))))

[WaterFish]

Да внатуре прорвемся, не кипешуем, пацаны ;-))))

99 рублей никто и никогда не отменит::))

[Ms-Rem]

Писателей руткитов это врядли остановит. Имхо самый простой способ обхода такой защиты - это патч ntoskrnl.exe на диске, и восстановление образа ядра в памяти после перезагрузки со скрытием изменений файла путем хуков IRP на ntfs.sys.
Хваленая PatchGuard на windows xp 64 отключается в полпинка хуком KeBugCheckEx, и я не думаю что обойти эту защиту будет сложнее.

[rav]

Они могут сделать проверку подписи ntoskrnl в загрузчике для проверки аутентичности. Тогда ещё и виндовый загрузчик править, а потом ещё и самопроверку целостности в нём отключать. В общем, траха много будет, я полагаю..... Всё-таки в Редмонде не идиоты сидят!

[Ms-Rem]

Можно править сразу MBR, затем хукать bios прерывания, отслеживать загрузку ядра и патчить его в памяти.
Я сомневаюсь, что будут какие-либо затруднения. Во всяком случае от PatchGuard я ожидал большего, а обойти оказалось пустяком.

[rav]

Можно править сразу MBR, затем хукать bios прерывания, отслеживать загрузку ядра и патчить его в памяти.

Кстати, точно. Помнится мне, eEye делала такой финт ушами.

Я сомневаюсь, что будут какие-либо затруднения. Во всяком случае от PatchGuard я ожидал большего, а обойти оказалось пустяком.

Может быть, ещё не смотрел её. Мне пока и без неё жизнь мёдом не кажется...

[Sanja]

Вчера видел анализ и методики хукинга апи под 64x Window + EMT64 Procom

1 из методов - какраз хукинк KeBugCheckEx

[Ms-Rem]

Я еще манипуляции с сегментами использовал. Ведь чтение данных != исполнению кода. Мапим копию ядерной памяти, создаем сегмент, меняем ds в контекста всех ядерных потоков и все. Теперь защита будет читать чистую копию, а оригинал можно патчить сколько угодно.

[rav]

Вчера видел анализ и методики хукинга апи под 64x Window + EMT64 Procom

1 из методов - какраз хукинк KeBugCheckEx

А где можно почитать это в порядке самообразования?