Contents of this directory is archived and no longer updated.

Чуть не забыл про обещание выложить ответ тех.поддержки по поводу проблематики, изложенной в Секреты Software Restriction Policies (часть 5). Вот какой я получил ответ от них:

Hello Vadims,

My name is Rahul and I am from the Windows Core Team at GTSC.  I have been looking at this case for the Software Restriction Policy.

After some testing we have been able to recreate the behaviour that you are noticing:

This seems to be by design. On the Explorer.exe side, everything seems to be running ok.  We cannot launch the file types restricted via policy. This is because when ShellExecute comes into play, we enforce SRP policies. This is also true for the Windows Script Host, which does it's own checks apart from the shell.  Specifically regarding mshta.exe, we have the following situation:

- Since the shell is allowed to run lnk files, we do it ok;

- Since there's a specific additional rule that will allow us to run anything located under %windir%\system32, the shell can't enforce any SRP policy, since lnk files can be run.

- The shell starts mshta.exe, which, by its own, doesn't enforce the SRP policy, allowing the file to run.

This behaviour is by design.

итого, мы имеем следующее: как выяснилось, политика SRP не очень плотно накладывается на систему и внешние приложения должны сами проверять открытие своих файлов на соответствие правилам SRP. Если мы запускаем файлы через ярлыки. Что с успехом делают cmd.exe, msiexec.exe и cmd.exe. Но такие приложения, как regedit.exe, mshta.exe, hh.exe, mmc.exe ничего не знают о существовании SRP и неспособны произвести такую проверку. Понятно, что это by design (в чём я и не сомневался), но какой-то не очень удачный design. Вот так.


Share this article:

Comments:

shs

Небольшой взгляд в сторону: К сожалению, некоторые приложения, которые, на первый взгляд, вообще никак не должны выполнять код, тем ни менее делают это. А, значит, вообще не подпадают под действие SRP. Так, например, неприятным сюрпризом является то, что, казалось бы, безобиднейший Adobe Acrobat Reader, имеет на борту встроенный интерпретатор JavaScript. Этот интерпретатор (вернее будет сказать - уязвимости в оном интерпретаторе) очень любят использовать зловреды класса Exploit.JS.Pdfka (например, http://www.securelist.com/ru/descriptions/12478810/Exploit.JS.Pdfka.ti) Adobe постоянно латает дыры, но вирусописатели постоянно находят новые по соседству ;). Посему этот интерпретатор лучше отключить от греха подальше. Я в своем блоге запостил простенький "административный шаблон" для отключения оного интерпретатора: http://shss.wordpress.com/2009/12/22/adm-template-acrobat-javascrip-disable/

shs

Извиняюсь, только что заметил опечатку в своей ссылке. Пофиксил: http://shss.wordpress.com/2009/12/22/adm-template-acrobat-javascript-disable/

Comments are closed.