Hi there,
This is Mike of the MSRC,
The case of the MDB attack vector
The MSRC on Friday afternoon posted an advisory about limited, targeted attacks using JET database files, commonly referenced as file type MDB. Many of you probably remember that MDB files are on the unsafe file type list (http://support.microsoft.com/kb/925330), and are blocked from being opened by Outlook, are commonly removed from incoming email by Exchange, and trigger scary prompts similar to EXEs when clicked on with IE. So why the hubbub?
First – let me describe the attacks we’ve seen:
We have seen two malicious JET database files sent in by anti-virus companies. These files make it clear that some attackers have figured out a way to workaround the mitigations built into Outlook.
These new attacks, discussed in Friday’s security advisory, use the exact same vulnerability as was posted in a November 2007 full-disclosure posting by cocoruder. In fact, very little was changed about the file compared to cocoruder’s POC file which launched calc.exe. It uses the same column number overflow. Even as far back as March 2005, HexView posted a similar vulnerability in msjet40.dll column handling. You’ll notice that both the HexView and the cocoruder posting mention that they first submitted their samples to the MSRC, but the MSRC replied back that they would not address the issues via a security bulletin because any attempt to attack customers using these issues was heavily mitigated by the blocking mentioned earlier in this post.
So how is this new JET database file attack different than the previous JET database file issues?
Everything changed with the discovery of this new attack vector that allowed an attacker to load an MDB file via opening a Microsoft Word document. The previous guidance does not work against this new attack. The attack sequence is not the dangerous multi-step process of requiring a customer to first change their Outlook and Exchange settings from the secure default of blocking MDB files and then opening the MDB file. Instead, it could occur by having a customer save two DOC files to the hard drive and opening one of them. So that’s why we alerted customers to these attacks and are re-investigating JET parsing flaws – this is a new attack vector discovered that we didn’t know about previously.
So now what are we going to do about JET database files?
Well, a lot of this is still under investigation as part of the SSIRP process. We’re investigating if we can ship a security update that prevents Word documents from loading MDB files without prompting. This would block this new vector and would be a great solution if we can find a way to make it work without affecting custom applications. Also, we already have a new version of msjet40.dll that fixes the known attacks. In fact, we have already shipped it in Windows Server 2003 SP2, Windows Vista, and it is included in beta versions of Windows XP SP3. We’re investigating what it would take to release those fixes as part of the security update as a defense-in-depth change.
Even after we determine a fix plan for these issues, JET database files (filetype MDB) will remain on the unsafe filetype list because they can run code by design. MDB files opened by Access can run arbitrary VBA script code specified in the MDB file – that’s why they’re marked as unsafe and blocked by Outlook, Exchange, etc. So even if we tried to, we could not secure this file format – it will always present attackers an opportunity to run code. We currently do not plan to turn off the VBA functionality present as part of opening an MDB files as many customers use that feature in their applications and wouldn’t apply the security update anyway. So we will continue to recommend that you never, ever open MDB files received unexpectedly.
So what should customers do in the meantime?
Well, first, I recommend you read the security advisory. There’s some solid guidance in there, for example, enterprise administrators can block JET files, even those renamed from MDB, at the gateway. We’ve even shared samples with folks in the MSRA. For end-users, we will continue to recommend that you never, ever open attachments received unexpectedly. Finally, I’d recommend that you continue to monitor this blog and the MSRC blog as we’ll update you on the results of our investigation through each of those.
Mike Reavey
*This posting is provided “AS IS” with no warranties, and confers no rights.*