Happy Patch Tuesday - Random thoughts
The SnapShot Viewer 0-day that has seen limited exploitation in the wild is now patched - here's an interesting write-up with some things you may not have known about it. Here's the deal - IE Protected Mode, while not a true defendable security boundary - is awesome and this particular vulnerability proves its worth. This vuln allowed a bad guy to write an arbitrary file to an arbitrary location on disk without having to run shellcode or perform heap spray. That's about as bad as it gets vuln-wise because there's little or no risk of crashing the browser and the victim may not even realize what's happened. On Windows XP with IE6 this is all fail, all the time - because your mom running IE6 on Windows XP is likely running with admin rights - which means not only is she NOT going to get a gold bar prompt blocking the instantiation of the buggy AX (we introduced that in IE7), but since she's also running as admin - the AX can write the malware anywhere it wants (like to any of the known auto-start entry points (ASEPS) that are available to admins. On Vista the exploit would be full of fail. Why? Well for starters if the AX control has never been used by IE before - it will be blocked from being loaded behind a gold bar vs. just running silently. If the user decided to trust the AX and allow it to run (it is after all a Microsoft AX) the bad guys would probably assume they could write their malware to say the Windows directory or if they were more sophisticated the users startup folder (which would work for non-admins) - but on Vista - even THAT would be full of fail due to Protected Mode IE. PMIE is on by default (along with UAC which is what makes it possible) and it means that IEXPLORE.EXE is running at "Low" integrity. This means that the only folders that the IEXPLORE.EXE process can write to are ones that have a Low IL label. How do you know which folders have a "Low" integrity label allowing processes running at Low IL to write to them? Let me show you:
C:\Users\rhensing\AppData>dir
Volume in drive C has no label.
Volume Serial Number is 3E4D-4005
Directory of C:\Users\rhensing\AppData
08/12/2008 04:51 PM <DIR> Local
08/01/2008 06:10 PM <DIR> LocalLow
06/23/2008 09:19 AM <DIR> Roaming
0 File(s) 0 bytes
3 Dir(s) 5,155,340,288 bytes free
C:\Users\rhensing\AppData>icacls LocalLow
LocalLow NORTHAMERICA\rhensing:(F)
NORTHAMERICA\rhensing:(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
BUILTIN\Administrators:(F)
BUILTIN\Administrators:(OI)(CI)(IO)(F)
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW) <---- Lookie here!
Successfully processed 1 files; Failed processing 0 files
The AppData\LocalLow folder is, I believe, the only folder that's writeable by a Low IL process. And it's not an ASEP so assuming the bad guys adjusted their exploits to start dropping their malware in that folder - they'd have to still find a way to get it to execute (i.e. chain this vulnerability with some other one that allows you to run a program from a known location).
Let's see, what else is interesting this month . . . OH we released a blog on how we can use the programmable 010 hex editor from Sweetscape to detect malicious Word documents that attempt to exploit vulnerabilities. If you're interested in the gory details of that you can read about it here. Essentially if you know the binary file format - you can teach this hex editor how to parse the file and then you can inspect the various bytes of data you read from the various meaningful offsets in the file to determine whether they represent an attempt to exploit a known vulnerability - it's pretty cool stuff.