Vista's security impact on the leaktests

I - Vista's security features

MIC (Mandatory Integrity Control) provides different integrity levels to the processes and files : low, medium, high, and system. These integrity levels are then used by the UIPI (User Interface Process Isolation) feature, to block a process with a lower integrity level to access (write/modify) other processes with higher integrity levels. Thus a medium integrity level cannot write/modify a high or system process, and a low one cannot write/modify any processes except other low integrity ones. If applied to folders and files, a low integrity process cannot write to files and folders having a medium integrity level.

UAC (User Account Control) adds to Vista many layers. While it is infamous for supposedly being invasive, because displaying popups, it does fortunately more than that. The first thing it does is to run all processes with standard user rights even under an administrator account. That clearly means that everything you run under your admin account will have by default restricted rights. The second thing UAC does, is to request user's permission in case something on the system is trying to do an action requiring administrator privileges. Then, UAC provides virtualization for programs not being designed to run as a limited user, by redirecting system area write requests to virtualized folders. Finally, UAC enables Internet Explorer 'Protected Mode' feature, which sets IE to a low integrity level (see UIPI above), preventing it from writing to critical system places, should it be exploited.

ASLR (Address Space Layout Randomization) randomizes system function addresses at every boot. Thus, a rogue code executing inside an exploited process could not predict where the functions it needs to call are located. This should prevent remote arbitrary code execution from working successfully.

Vista has more security features that I won't detail, such as BitLocker, Service hardening, and Kernel Patch Protection (PatchGuard). More information at : Wikipedia : Security features new to Windows Vista.


II - Impact on the leaktests

As you have read, the default 'out of the box' Vista security is very different than Windows XP, and brings some improvements. Below we will see per leaktests the impact on them, if any. The test will simply consist of running the leaktest, without any third party security software installed (no personal firewall, no HIPS), under an administrator account. All tests are done under Windows Vista Ultimate 64bits, with DEP enabled. DEP is not new to Vista, it already exists into Windows XP Service Pack 2 (SP2), Windows XP Tablet PC Edition 2005, and Windows Server 2003.

The tests requiring Internet Explorer are done with IE 32bits, as it is the version that all Vista editions have by default, even on Vista x64. The built-in firewall is left to default settings, blocking only inbound.

Leak test : Vista did not block the leaktest picture
Tooleaky : Vista did not block the leaktest picture
FireHole : Vista did block the leaktest picture
Yalta : Vista did not block the leaktest picture
Outbound : did not run (missing dll)
PCAudit : was hanging
AWFT : is crashing
Thermite : injection and outbound successful, but failed to create the file 'securityfocus.htm' picture
Copycat : injection and outbound successful, but failed to create the file 'exploited.txt'
MBtest : did not run (missing dll)
Wallbreaker : Vista did not block the leaktest picture
PCAudit2 : Vista did not block the leaktest picture
Ghost : Vista did not block the leaktest picture
DNStester : Vista did not block the leaktest picture
Surfer : Vista did block the leaktest picture
Breakout : did not run/was hanging
Jumper : Vista did block the leaktest picture
CPIL : Vista did block the leaktest picture
CPIL suite : Vista did block the leaktest
PCFlank : Vista did not block the leaktest picture
Coat : Vista did not block the leaktest picture
Runner : Vista did block the leaktest picture
OSfwbypass : Vista did block the leaktest picture
ZAbypass : Vista did not block the leaktest picture

Result : 9 leaktests are blocked on Vista, 3 weren't tested due to not being compatible or because WinpCap not being installed (WinPcap 4.0 or newer is required on Vista x64), and 12 leaktests are still working despite new Vista's security features. That means that 37,5% of the leaktests are blocked either from running properly, or from making a successfull outbound leak.
If you look differently the same numbers, we can say also that 50% of the leaktests (12) only are sucessfull on Vista, so that half are blocked (12 on 24). Pick the statistic you prefer.

III - Analyse of the results

Which features prevented some leaktests from being successful ? Mainly UAC, by running the processes with standard rights and not administrator ones. Some leaktests, lacking of sufficient privileges, couldn't manipulate explorer or Internet Explorer, create files, or writing registry. Additionaly, with the IE protected mode (enabled by UAC), IE is running with a low integrity level and has therefore even less rights than the others processes. That means that once IE is injected or manipulated, the rogue program has gain very few rights, maybe even less than it had. Other blocks could be due to library incompatibilities, as the leaktests weren't coded to be working on Vista. Apparently ASLR did not help, unlike I expected against Thermite and Copycat. However, it should be highlighted that these two leaktests both fail against Internet Explorer 64bits (Vista x64 includes IE 32bits and 64bits).

Successful leaktests were working because they did not require administrator rights, and were manipulating IE, which has a lower integrity level than them (which means that they are not restricted on it). It still baffles me than even with standard rights, a process can hijack another one and inject it's code via CreateRemoteThread. Granted, now you cannot anymore inject higher integrity level processes such as the system ones (with UAC enabled), but still many doors are open.

An important point that should be highlighted, is that UAC primary purpose is to run processes as standard user, and to enable the user to elevate when needed; not to stop malware (as pointed out by Mark Russinovich). Thus, leaktest impact because of UAC should be seen as a benefitial side effect, and lack of impact should not be seen as a security vulnerability. Point also talked by Jesper Johansson.


IV - Conclusion

Vista includes a lot of security improvements, and it fortunately blocks some leaktests, and consequently, some real malware. Now, running under an administrator account is not very much different than being under a standard user account (thanks to UAC). However, the new security model, even if a good improvement, could be better. Indeed, even set at a low integrity level (IL), a critical internet enabled application can be abused by higher IL processes. That's good that a low IL cannot modify higher IL, but higher IL can send messages to lower ones, and abuse them. I would have added to UIPI a special 'critical' flag, to prevent low IL applications being flagged by it to be manipulated by anything else than system processes. The system processes having a high IL, they cannot be modified by medium (default) processes, and thus couldn't be used to abuse 'critical' low IL applications. A kind of sanbox, stronger than actually, which would prevent all leaktests to send messages or to write the memory of Internet Explorer. I have no idea if it is practical, may be it would break some things, but the idea is here.

Also, protected mode is only available for IE, and do not apply to any other browser you may have such as Firefox or Opera. You can manually set your browser to a low IL with the command line 'icacls' but it's not very user-friendly, and it won't work if you forget to apply a low IL also to the folders your browser needs to access to (profile and download folders for instance). Even then, that's not a perfect solution. For instance IE which has been built with UIPI in mind has access to 'C:\Users\youraccount\AppData\LocalLow\Temp', whereas any other browser will try to access to 'C:\Users\youraccount\AppData\Local\Temp', folder that they cannot anymore access once set to a low IL. I have tried to configure Firefox to modify it's default Temp folder, but it seems it relies on the system variable TEMP which points by default on 'Local\Temp'. So either you have to set a low IL to 'Local\Temp', somehow defeating the purpose of UIPI by allowing low IL processes to access a folder used by medium IL processes (everything you run, actually), or either you try to workaround it. I am sure most of the users won't dive into tedious manipulations, and would rather check a checkbox "enable protected mode" in Firefox, or run it with default settings (therefore not using the full benefits of UIPI). That can only help leaktests and malware. I would really like to see GUI interfaces integrated to Windows to manage IL and a new option in alternative browsers like "Vista option : enable low integrity level" (which would redirect them automatically to 'LocalLow\Temp'). I really think it's doable, let's hope it will happen.

Then, Internet Explorer 64bits which is immune to advanced injections from 32bits leaktests, is not the default on Vista x64. Why the most secure IE version is not the default is probably for compatibility reasons, as some activex may not work with it. While I can understand the decision, one may wonder how the users will know they are launching IE 32bits and not 64bits ? Will they know they are using a less secure version ? Probably not, especially when you see written at the bottom "Protected Mode : Enabled".

The bottom line is that Vista's security is better, but still does not discard the need for third-party firewalls and antivirus. Even if good efforts have been made, for instance UIPI which prevents system services from being exploited (because they run at high IL), I can already see some improvements which could be added, like the aformentioned ones. In addition, the main security margin gain is thanks to UAC, a feature that can be disabled by the user. Disabling it would be a mistake, if security is one of your concerns. Unfortunately, few people will stop at that, and will simply turn it off to not see anymore popups, loosing nearly all the benefits of Vista's security. While I disagree about supposed UAC's intrusiveness, which is quite quiet once everything is set up, that is a fact that some people turns it off anyway.

Current Vista's security model is definitly better and safer than XP, there's no doubt about it. UIPI, ASLR, UAC, IE protected mode, Service hardening, and Kernel Patch Protection (Vista x64), make the OS stronger than before. However, trade-off between security and usability have been (logically) made by Microsoft, and therefore some holes still exist. Ultimately, this is not the end of the leaktests as of yet, nor of the real in the wild malware. That may even be the begining of a new privilege escalation trend among the malware against the new Microsoft's OS. Time will tell.


March 14 2007
Guillaume Kaddouch.

---

External links :

Joanna Rutkowska : Running Vista Every Day!
Michael Howard : Address Space Layout Randomization in Windows Vista
Wikipedia : Features new to Windows Vista
Marc Silbey, Peter Brundrett : Understanding and Working in Protected Mode Internet Explorer