Observations on Mandatory Integrity Control (MIC) in Windows Vista
Hi,
in Windows Vista Microsoft plans to introduce a security concept they call
"Mandatory integrity control" (MIC) which is described here:
[1] http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx
As this sounds like a promising feature I did some testing with Vista RC1 that
gave interesting results. I posted them to that blog asking for clarification
and will post them here as the technology and discussion may be of interest for
some bugtraq readers.
================
Steve,
at first thanks for your blog and the valuable insight it provides. After
reading your post on MIC I decided to have a look on it, given I've done some
research on multi level security systems lately. I stumbled across some
obscurities though which I'd like to clarify here. Please note that this was my
first installation of Win Vista ever so maybe there are some misunderstandings
of concepts on my side...
This is what I did in detail:
- default installation of RC1 (build 5600)
- creation of first and single user (here 'erey')
- logged in as erey, with restricted token and the following privs
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeShutdownPrivilege Shut down the system Enabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
- creation of c:\tools directory and download of tools to it (Sysinternals:
accesschk, ProcessExplorer and Mark Minasi's chml)
=== Integrity level of files
I then checked the integrity levels of the files just downloaded and here comes
the first surprise (or just personal misunderstanding):
AccessChk v2.0 - Check account access of files, registry keys or services
Copyright (C) 2006 Mark Russinovich
Sysinternals - www.sysinternals.com
C:\tools\accesschk.zip
Medium Mandatory Level (Default)
RW BUILTIN\Administrators
RW NT AUTHORITY\SYSTEM
R BUILTIN\Users
RW NT AUTHORITY\Authenticated Users
C:\tools\chml.exe
Medium Mandatory Level (Default)
RW BUILTIN\Administrators
RW NT AUTHORITY\SYSTEM
R BUILTIN\Users
RW NT AUTHORITY\Authenticated Users
I had naively expected that these files had an integrity level of 'low' given
their origin (internet) and the process that wrote them to disk (IE, supposedly
running with 'low' integrity).
Question: why do these files have an integrity level of 'medium'? Lack of
intlevel assigning capability in IE in current state?
Or the other way round: what the hell will ever get intlevel 'low' if not such
files (executables downloaded from the internet, restricted user, by means of
IE, from untrusted sources)?
[one could argue that the Sysinternal stuff is signed, but at least the Minasi
stuff isn't].
=== Integrity level of processes
Looking at the integrity level of processes I noticed the following:
1) Restricted token user 'erey' invokes procexp.exe (medium) => process
integrity: medium
2) (Run as) Administrator 'erey' invokes procexp.exe (medium) => process
integrity: high
This is consistent to your description (or at least my understanding of it ;-):
"when a user invokes a file whose integrity level is higher than low the
resulting process will run with the integrity level of the user"
[which contrasts to the Biba model where the lower level of subject (user) and
object (file) is chosen, but as you correctly say: a model is just a basis...].
This again rises the question: if a user runs an internet-downloaded executable
with admin privileges (and this will happen rather often, think of all the
little helper tools available from the internet, requiring admin privs for
whatever reason), the resulting process will run with intlevel 'high'. Where's
the protection benefit then?
I understand the behaviour is consistent (however I'm not sure if or why the
variation from Biba is a good idea here) and I understand that maybe the
process needs a 'high' intlevel (to perform it's functions correctly) - and yes
UAC came into place and asked me when invoking procexp as an admin - but I'm a
bit sceptic about the use then. My previous understanding of "in Vista we're
running IE with low privs to protect you from all that bad stuff coming from
the internet" was a bit different...
=== Modifying intlevel of files and the results
Time for a change of the integrity level of an executable now...
Trying that gave the following:
- created a copy of procexp.exe
1) - tried (as 'erey' with restricted token) to modify intlevel by
C:\tools>chml procexp_mod.exe -i:l
=> did not work ("Access is denied").
2) I then gave the user 'erey' the privilege "Modify an object label" by gpedit
(+ gpupdate).
After logging out and in again I noticed I did not even (seem to) have it when
running cmd.exe as admin:
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
=============================== =========================================
========
...
SeCreateGlobalPrivilege Create global objects
Enabled
SeRelabelPrivilege Modify an object label
Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set
Disabled
But now chml worked:
C:\tools>chml procexp_mod.exe -i:l
chml v1.010 -- Change Windows Integrity Level
by Mark Minasi (c) 2006 www.minasi.com
"chml -?" for syntax, examples and notes.
Integrity level of procexp_mod.exe successfully set to low.
--
C:\tools>accesschk.exe -i procexp_mod.exe
AccessChk v2.0 - Check account access of files, registry keys or services
Copyright (C) 2006 Mark Russinovich
Sysinternals - www.sysinternals.com
C:\tools\procexp_mod.exe
Low Mandatory Level (!!!)
RW BUILTIN\Administrators
RW NT AUTHORITY\SYSTEM
R BUILTIN\Users
RW NT AUTHORITY\Authenticated Users
3) Invoking the procexp_mod.exe with intlevel 'low' gave the following:
invoking as restricted user 'erey' => process integrity: 'low' (as indicated by
ProcessExplorer)
invoking as admin => process integrity 'high'
BIG surprise! what's going on here? High integrity user runs low integrity
executable and resulting process runs on 'high' integrity!?!
Questions:
a) Looking at the "Explain" text in gpedit:
"Modify an object label
This privilege determines which user accounts can modify the integrity label of
objects, such as files, registry keys, or processes owned by other users.
Processes running under a user account can modify the label of an object owned
by that user to a lower level without this privilege."
... I do not understand why 1) didn't work. I invoked a process cmd.exe
(supposedly running with intlevel 'medium' given the user was restricted) and
tried to modify a file I owned. The observed behaviour seems to contrast the
'help text' but seems consistent to Mark Minasi's comments in the manpage of
chml.
b) why did user 'erey' seemingly not dispose of SeRelabelPrivilege after
assigning it to him directly and logging out+in, neither as restricted user nor
as admin? or at least: why did 'whoami' indicate that? Problem of privilege
enumeration in 'whoami'?
c) please explain scenario 3 mentioned above! ;-))
This seems to contradict fully your explanation (or I got it totally wrong).
There seems to be a different behaviour as for the process intlevel, depending
on the level of the invoking user.
And: is this a good idea? Biba wouldn't have liked that a lot. And neither do I
;-)
Concluding my observations mean:
User downloads executable from internet, saves file to hard disk and this file
has intlevel 'medium': maybe not a good idea.
[maybe resulting from IE currently not assigning intlevels to files it writes]
User running with admin_privs (most windows users will still sometimes do ;-)
invokes this executable resulting in a process running with intlevel 'high':
debatable...
Security aware user labels some executables down to 'low' but invokes them as
admin, process is running with intlevel 'high': what can I say here? ;-)
These are some observations from a guy with some background on "Mandatory"
security models, running Vista for the first time.
Thanks in advance for your answer, I appreciate your efforts.
thanks,
Enno
--
Enno Rey
ERNW Enno Rey Netzwerke GmbH - Breslauer Str. 28 - 69124 Heidelberg
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
www.ernw.de - PGP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1