So the “MoXB” theme continues as a trend with security researchers – with May 2007 bringing us the “Month of ActiveX Bugs” (MoAXB).
One thing that may be causing some confusion out there are the first few bugs which involve a 3rd party product that allows users to view Office documents in a browser. I want to make clear – these are NOT Microsoft ActiveX controls – they are from a 3rd party company . . . but with so many days left in the month it wouldn’t surprise me if a few of our own aren’t found and eventually released.
Having said that – let’s see how our current products, IE 7 and Vista, do against these 3rd party controls both when they are previously installed and when they are not and an attempt is made to exploit them.
The screen shots below are the experience one would have if they visited the vendors web site and installed the software package on their machine or if the software had been pre-installed on the machine (possibly by an OEM or as part of a corporate desktop deployment).
Here’s the experience with IE7 on XP SP2 the first time an attempt is made to run the pre-installed ActiveX control:
After clicking to allow the control to run – here’s the second dialog box the user has to click through:
At this point – an XP user would be owned shortly after clicking the ‘Run’ button as this looks like a stack based buffer overrun so code execution is pretty straight forward assuming you don’t have DEP enabled in IE (you DO have DEP enabled in IE don’t you?).
Unfortunately, on IE6, if you have the vulnerable AX control pre-installed – IE does not prompt the user to run the control – it simply runs by default . . .
This IMHO is a big reason to encourage everyone you know to upgrade to IE7.
Now, what do things look like if you don’t even have this ActiveX control pre-installed though (i.e. you’re just Joe Random user surfing the Internet)?
As you know – web site authors can host an ActiveX control and ask IE to install it for them. Here’s the experience when the ActiveX control is hosted on a site by a bad guy – I’m assuming the bad guy would use social engineering to trick the user into installing the control (i.e. “To see the dancing pigs (ZOMG they are so funny! LOLOLOL!!!) click here to install the Dancing Pigs Viewer”) and then try to exploit it.
Here is the experience if you browse to a site that uses this control and you don’t have it installed already:
Now assuming the user clicks on the gold bar above and chooses ‘install’ they are then presented with this dialog box:
After clicking ‘Install’ the control is then activated and run since it is a signed ActiveX control and the user just told IE they want it installed.
The point is – no matter which path you go down (either the control was pre-installed for you, or you installed the control yourself) – you still probably have not one but two dialog boxes to interact with before the control actually runs (unless you have previously run the control on your system – as legitimate users of this product likely have). After you allow the control to run at least once, it will continue to run automatically by default until you remove the control or disable it via the IE Manage Add-ons UI (Tools->Mange Add-ons).
The experience on Vista is exactly the same as that of IE7 on XPSP2 (same number of prompts etc.) for the pre-installed software scenario. If you’re using Vista and the control is not pre-installed (i.e. it’s being hosted by the bad guy) then you have an additional prompt to go through (the UAC prompt which is needed in order to copy the files to the right directories and update the registry) as compared to XP SP2. So three chances on Vista to bail out as opposed to just two.
It is at this point some mitigation technologies in Vista make life harder for the attacker who wants to actually turn this into a working exploit and this is where Vista leaves XP SP2 behind when it comes to protecting the average user.
On Vista – the stack based buffer has still been overrun – and there is still shellcode that is about to be executed sitting in memory – but since that shellcode is on the stack – if you have DEP enabled and IE is opted into DEP – it should fail to execute. But even if you don’t have DEP enabled (sadly still the default for a variety of reasons) the shellcode may still fail to work properly if it attempts to makes use of any hard coded addresses to do interesting things as those addresses would be randomized by ASLR and the odds are – the shellcode wouldn’t work properly and the process would simply crash.
Now even if the attacker managed to clear these hurdles (speed bumps?) somehow – IE is running in Protected Mode by default on Vista which means that the shellcode is very limitted in what it can do. It can write to only one folder and one registry key (that I know of). A very popular tactic used by miscreants these days is to use “HTTP download and execute” shellcode . . . this shellcode usually tries to load WinInet and use one of its APIs to download a file and then execute it. If this shellcode wasn’t busted by ASLR – it would probably attempt to download the payload to a well known folder that IE in Protected Mode will not have write access to (i.e. system32).
Even if it did manage to download a file to a low rights folder (%userprofile%\AppData\LocalLow) and then execute it – that process would be running with Low Integrity and also wouldn’t be able to alter any ASEP’s or interact with processes running at a higher integrity level (anything at Medium or higher).
I’m not saying you can’t still do bad things with a low integrity process running from low integrity folders – but I AM saying that the number of things you can do (your attack surface) is GREATLY reduced by UAC and it is still one of my favorite mitigation technologies in Vista. Oh and getting really crazy for a minute – even if the shellcode did manage to download something that tried to make itself persist reboots – Windows Defender would detect the change and alert the user and allow them to undo the change.
It’s going to be an interesting month – hope you’re using IE7 on Vista with DEP enabled. 🙂
UPDATE: I forgot to mention this on my original post – but on IE6 / IE7 on Windows XP – if an attempt to exploit this vulnerability fails – it’s likely IE will just ‘disappear’ – you probably won’t see the IE Watson dialog box and thus you probably won’t be prompted to submit an error report. This happens because the stack will have likely been damaged to the point that any exception handlers that get called are corrupted and end up encountering an exception resulting in the operating system imediately terminating the process.
On Vista – due to an architectural change in the way we do error reporting – this is no longer the case and if an attempt is made to exploit this and it fails – you should still be prompted with the following dialog box and the Windows Error Reporting service should take care of sending an error report for you . . . As an added nice touch – IE will be re-started automatically. 🙂
You can view Windows Error Reports in Vista by typing ‘Problem Report’ in the start menu search box and clicking ‘Problem Reports and Solutions’ in the search results. When that applet comes up you can click ‘View Problem History’ to see a list of things the WER service has caught. Clicking ‘Check for Solutions’ prompts you to submit any un-submitted problem reports for analysis. This service was able to notify me that my ATI drivers were causing my intermittent bugchecks on my Vista x64 box – a problem which ATI has since resolved. I was even given the direct URL to the update in the response from the Online Crash Analysis service!