Joanne Rutkowska early this month published a blog called " Running Vista Every Day!". In it, while generally supporting Microsoft's Vista, siad that she had found what she considered to be a major security flaw in Vista. The flaw centered around the User Account Control (UAC).
Joanne generally likes UAC. As she describes it "User Account Control (UAC) is a new security mechanism introduced in Vista, whose primary goal is to force users to work using restricted accounts, instead working as administrators. This is, in my opinion the most important security mechanism introduced in Vista. That doesn’t mean it can not be bypassed in many ways (due to implementation flaws), but just the fact that such a design change has been made into Windows is, without doubt, a great step towards securing consumer OSes."
However "One thing that I found particularly annoying though, is that Vista automatically assumes that all setup programs (application installers) should be run with administrator privileges. So, when you try to run such a program, you get a UAC prompt and you have only two choices: either to agree to run this application as administrator or to disallow running it at all. That means that if you downloaded some freeware Tetris game, you will have to run its installer as administrator, giving it not only full access to all your file system and registry, but also allowing e.g. to load kernel drivers! Why Tetris installer should be allowed to load kernel drivers?"
She further states the following: "
To get around this problem, e.g. on XP, I would normally just add appropriate permissions to my normal (restricted) user account, in such a way that this account would be ale to add new directories under C:\Program Files and to add new keys under HKLM\Software (in most cases this is just enough), but still would not be able to modify any global files nor registry keys nor, heaven forbid, to load drivers. More paranoid people could chose to create a separate account, called e.g. installer and use it to install most of the applications. Of course, the real life is not that beautiful and you sometimes need to play a bit with regmon to tweak the permissions, but, in general it works for majority of applications and I have been successfully using this approach for years now on my XP box.
That approach would not work on Vista, because every time Vista detects that an executable is a setup program (and believe me Vista is really good at doing this), it will only allow running it as administrator… Even though it’s possible to disable heuristics-based installer detection via local policy settings – see picture below:
Picture
that doesn’t seem to work for those installer executables which have embedded manifest saying that they should be run as administrator.
I see the above limitation as a very severe hole in the design of UAC. After all, I would like to be offered a choice whether to fully trust given installer executable (and run it as full administrator) or just allow it to add a folder in C:\Program Files and some keys under HKLM\Software and do nothing more. I could do that under XP, but apparently I can’t under Vista, which is a bit disturbing (unless I’m missing some secret option to change that behavior). "
She then describes the overall security threat: "
Still, even though that might look like a secure configuration, this is all just an illusion of security! The whole security of the system can be compromised if attacker finds and exploits e.g. a bug in kernel driver.
It should be noted that Microsoft has also implemented several anti-exploitation techniques in Vista, the two most advertised are Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP). However, ASLR does not protect against local kernel exploitation, because it’s possible, even for the Low IL process, to query system about the list of loaded kernel modules together with their base addresses (using ZwQuerySystemInformation function). Also, hardware DEP, which works only on 64-bit processors, is not applied to the whole non-paged pool (as well as some other areas, but non-paged pool is the biggest one). In other words, the hardware NX bit is not set on all pages comprising the non-paged pool. BTW, there is a reason for Microsoft doing this and this is not due to compatibility issues (at least I believe so). I wonder who else can guess... ;)
UPDATE (see above): David Solomon, pointed out, that Hardware DEP is also available on many modern 32-bit processors (as the NX bit is implemented in PAE mode).
It’s very good that Microsoft implemented those anti-exploitation technologies (besides ASLR and NX, there are also some others). However the point is, they could be bypassed by a clever attacker under some circumstances. Now think about how many 3rd party kernel drivers are typically present in an average Windows systems – all those graphics card drivers, audio drivers, SATA drivers, A/V drivers, etc... and try answering the question how many possible bugs could be there? (BTW, it should be mentioned that Microsoft did a clever step by moving some classes of kernel drivers into user mode, like e.g. USB drivers – this is called UMDF).
When attacker successfully exploits kernel bug, then all the security scheme implemented by the OS is just worth nothing. So, what can we do? Well, we need to complement all those cool prevention technologies with effective detection technology. But has Microsoft done anything to make systematic detection possible? This is a rhetoric question of course and the negative answer applies unfortunately not only to Microsoft products but also to all other general purpose operating systems I’m aware of :( "
This article has stirred up the beginnings of a great debate on Vista security. Ryan Naraine published a blog last week "Hacker, Microsoft duke it out over Vista design flaw" where he had the response to Joanne's blog from Microsoft and an email discussion with Joanne about their response.
The blog concludes with these final comments from Joanne: "
There are two different things, which should be distinguished:
1. The fact that UAC *design* assumes that every setup executable should be run elevated.
2. The fact that UAC *implementation* contains bugs, the one noted in the original blog entry that allows a low integrity level process to send WM_KEYDOWN messages to a command prompt window running at high integrity level.
I was “pissed off” not because of #1, I was “pissed off” because Microsoft employee — Mark Russinovich — declared that all *implementation* bugs in UAC are not to be considered as security bugs (see fact #2).
True, I also don’t like the fact that UAC forces users to run every setup program with elevated privileges (fact #1), but, I can understand such a design decision (as being a compromise between usability and security) and this was not the reason why I wrote my follow up titled “Vista Security Model - A Big Joke”. "
Bottom line: Vista is a significant improvement over previous MS OS's. However, it has a major possible flaw in the way UAC is implemented. The successful use of malware in kernel drivers can be the way to bypass most of Microsoft's Vista security.
Stay tuned for more discussions on this.
Guy
www.authenticationworld.com
guy.huuntington@authenticationworld.com
