Game Over Man, Game OVER!

Okay, so I am sure many of you have seen (or will see) the video at McAfee’s Avert Labs Blog, showing how Vista is impacted by MSSec advisery 935423 – a pretty serious zero day exploit:
http://www.microsoft.com/technet/security/advisory/935423.mspx

(You can see the video clip and comments from Avert here http://www.avertlabs.com/research/blog/?p=233 )

However, the video and comments are misleading. While the core vulnerability exists in Vista, it is mitigated by several factors; IE7 Protected Mode (the MIC model wherein IE7 runs with low integrity, and communicates with higher integrity components via a broker process, protecting the shell and other processes from this attack) and UAC which, even if IE Protected Mode is disabled, will only allow the exploit the privileges of a standard user, making it far easier to recover from an attack.

Also, this video is not showing an OS (Vista) crash-restart as is claimed but is showing a shell (explorer.exe) crash restart. To recover in this instance, launch taskmanager from the winlogon desktop, start a command prompt and delete the offending file from the profile desktop folder. If a trojan was installed, provided UAC is enabled, and this attack was instigated from a non-elevated process, the scope would be limited to user profile autostart entries in the registry and AV/anti-malware would easily mitigate (or one could easily manually remove the malware via autoruns or similar tool).

On XP this is a far more serious issue as those protection mechanisms don’t exist and the user is likely running with unrestricted admin privileges. In short, highlighting Vista may make for more dramatic coverage, but ultimately Vista’s default security settings and mechanisms work to mitigate this vulnerability exactly as advertised.

Which brings me to my final point: DON’T TURN OFF UAC (and by extension IE Protected Mode)!!!!!!!!!!! This is EXACTLY the kind of exploit that I talked about in this post http://makfu.blogspot.com/2006/10/mr-t-says-do-not-turn-off-uac-in-vista.html .

I NEED MORE INTERNETS!!!

Okay, so you are like me and like to run lots and lots of applications concurrently. However, when you have a whole lot of apps open (especially those with visible window objects, toolbars and other graphical elements) you notice that you hit a brick wall in Vista or XP and simply can’t open any additional Windows or IE/Firefox Tab’s and other strange behavior, despite having plenty of available memory.

What you have just hit is a Desktop Heap space limitation. This is a pretty common occurrence in 32 bit Windows as the default is set just a tad too low for my tastes. But what is the Desktop Heap you ask? The desktop heap is an area of memory carved out of a kernel mode data structure called Session Space. Each session maps various data structures (shared sections) into Session Space, including each session’s Desktop Heap. If you are running more than one session, either via Terminal Services on a server, or Fast User Switching on XP or Vista, you actually have multiple Desktop Heaps (one for each session) mapped into Session Space.

Now what does the Desktop Heap do? First understand that each session is technically called a Windows Station (or WinStation for short) and has several top-level objects including several desktops (a winlogon desktop, a secure desktop in Vista and the main user desktop). A desktop is a logical display surface and has other subordinate objects including windows, menus, icons, etc. These objects are described by the data structures allocated from the Desktop Heap.

So in short, if you have too many windows open, you can exhaust the heap.

So what can you do about it? Well there are two options:

1. Upgrade to a 64bit version of Windows where the default Desktop Heap value is very large and practically inexhaustible.

2. Increase the Desktop Heap size (probably the simpler answer).
To do this, edit the following key in the registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems]Windows=”%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16″

Modify the “SharedSection=1024,3072,512” value to “SharedSection=1024,8192,512”.

This will increase the Desktop Heap for any given interactive session to 8MB versus the 3MB default. As an aside, the values for “SharedSection” refer to the global (non session specific) win32 heap (you should never need to change this), the interactive session specific win32 Desktop Heap size (the value that matters) and the size of the win32 Desktop Heap for non-interactive sessions (in Vista, this would be session 0 and again, you should never need to change this value). Once again, only value number two needs to be modified.

One interesting note is that on XP, you shouldn’t increase this value past 8MB (which should be more than large enough), especially if you are running multiple session (Fast User Switching). However, on Vista, the Session Space data structure from which the Desktop Heap is allocated is entirely dynamic and can actually be safely increased to the same default 20MB value used on 64bit Windows even when running multiple sessions (and while completely unnecessary, the value on x64 Windows could probably be increased into the gigabyte range).

Keep on internetting…