Monday, March 05, 2007

Handy Tool To Play with Windows Integrity Levels

Mark Minasi wrote to me recently to point out that his new tool, chml, is capable of setting NoReadUp and NoExecuteUp policy on file objects, in addition to the standard NoWriteUp policy, which is used by default on Vista.

As I wrote before the default IL policy used on Vista assumes only the NoWriteUp policy. That means that all objects which do not have assigned any IL explicitly (and consequently are treated as if they were marked with Medium IL) can be read by low integrity processes (only writes are prevented). Also, the standard Windows icacls command, which allows to set IL for file objects, assumes always the NoWriteUp policy only (unless I’m missing some secret switch).

However, it’s possible, for each object, to define not only the integrity level but also the policy which will be used to access it. All this information is stored in the same SACE which also defines the IL.

There doesn’t seem to be too much documentation from Microsoft about how to set those permissions, except this paper about Protected Mode IE and the sddl.h file itself.

Anyway, it’s good to see a tool like chml as it allows to do some cool things in a very simple way. E.g. consider that you have some secret documents in the folder c:\secretes and that you don’t feel like sharing those files with anybody who can exploit your Protected Mode IE. As I pointed out in my previous article, by default all your personal files are accessible to your Protected Mode IE low integrity process, so in the event of successful exploitation the attacker is free to steal them all. However now, using Mark Minasi’s tool, you can just do this:
chml.exe c:\secrets -i:m -nr -nx
This should prevent all the low IL processes, like e.g. Protected Mode IE, from reading the contents of your secret directory.

BTW, you can use chml to also examine the SACE which was created:
chml.exe c:\secrets -showsddl
and you should get something like that as a result:
SDDL string for c:\secrets's integrity label=S:(ML;OICI;NRNX;;;ME)
Where S means that it’s an SACE (in contrast to e.g. DACE), ML says that this ACE defines mandatory label, OICI means “Object Inherit” and “Container Inherit”, NRNX defines that to access this object the NoReadUp and NoExecuteUp policies should be used (which also implies the NoWriteUp BTW) and finally the ME stands for Medium Integrity Level.

All credits go to Mark Minasi and the Windows IL team :)

As a side note: the updated slides for my recent Black Hat DC talk about cheating hardware based memory acquisition can be found here. You can also get the demo movies here.


Anonymous said...

so we can understand this as, that at least some of the security problems from your previous post are now in a much better state (ala, your private keys are more safe), right? :)

Joanna Rutkowska said...

No, not really. I don't see how exploiting additional NR and NX policies solves any problem which couldn't be solved using the approach I described in my previous post (i.e. having multiple accounts for different purposes and making use of file system's ACLs).

My private keys cannot be made safer, because mail client still needs access to the passphrase and still has access to its child's (i.e. gpg.exe) memory.

Still, however, ability to set NR and NX policies makes it much easier for users to achieve similar level of privilege separation without all this complicated setup with multiple accounts. So, it's a very good thing :)

Anonymous said...

Hi joanna, i saw u in last year's HITB. I didnt see u on the list as on of the speakers this year. Anyway, i am here to say hello to you. That speech you gave on the conference last year was amazing. Thank you.

Anonymous said...

Shameless plug -

There's a whole chapter on this in Writing Secure Code for Vista, which is out this week. The sample code has some additional tools.