Posted on by Vulnerability Analysisin
Hi, it's Will. In this post I will discuss the risks of using forensics software to process untrusted data, as well as what can be done to mitigate those risks.
In my last blog post, I mentioned the increased risk of using Microsoft Exchange features that utilize the Oracle Outside In libraries. Outside In is a document-parsing library that supports a large number of file types, and subsequently has a large attack surface. Vulnerabilities can be found pretty easily by using a fuzzer like the CERT Failure Observation Engine (FOE). In the case of Microsoft Exchange, the risk can be mitigated by either turning off WebReady or at least running Exchange on a platform that supports address space layout randomization (ASLR).
But what about other software that uses Outside In? If you look at the Vendor Information section of the last Outside In vulnerability note that we published, you'll notice we've confirmed there are quite a few vendors that use Outside In. Of particular interest are the forensics software vendors Guidance (EnCase) and AccessData (Forensic Toolkit, or FTK).
Forensics software is used in pretty important circumstances, so the soundness of the software is critical. How seriously are Guidance and AccessData taking the security of their software? Two simple ways of minimizing the risk of using software that is known to contain flaws are to use
First, let's look at Guidance EnCase 7.07 on Windows 7:
EnCase.exe process, which hosts the Outside In libraries, runs with the privileges of the logged-on user and does not utilize ASLR (is not linked with /DYNAMICBASE). In other words, an exploit for a vulnerability in Outside In can use ROP to achieve code execution with the privileges of the user running EnCase.
What about EnCase on Windows XP?
It's pretty clear that EnCase doesn't opt in to using DEP on this platform. This makes it quite easy for an attacker to exploit EnCase when it is running on Windows XP. When DEP isn't enabled, an exploit can simply jump directly to shellcode anywhere in memory. No tricky ROP chains are required.
How would a vulnerability in Outside In be triggered in EnCase? I haven't investigated all of the attack vectors, but I have confirmed that simply selecting the "Doc" view tab for a file will suffice:
Now let's look at AccessData FTK 5.0:
As with EnCase, the FTK process runs with the privileges of the logged-on user and does not opt in to using ASLR, opening up FTK to simple ROP attacks. And with FTK, triggering an Outside In vulnerability requires even less user interaction. Simply clicking on a file to select it will render a preview of it using the Outside In library:
Note that the above screenshot is from an older version of FTK.
I have been able to demonstrate execution of
calc.exe with both EnCase and FTK. But
calc.exe isn't terribly exciting. What about...
There are a few things that we know about software vulnerabilities in general:
/DYNAMICBASElinker flag, and SafeSEH, by using the
So what can we do about this? If you've been reading any of the recent blog entries here, the answer should come as no surprise to you: Microsoft EMET on a Windows Vista or newer platform. Older platforms still get protection from EMET, particularly with the ROP mitigations. However, the lack of ASLR on older Windows versions is a significant weakness.
With EMET, you are no longer at the mercy of your software vendors. If they did not bother to enable mitigation features like DEP and ASLR, EMET can do it for you. Just add
ftk.exe, or whatever other application you'd like in order to have extra protections beyond the system-wide protections that EMET gives you.
You may also wish to contact your software vendor to determine what steps they are taking to protect against software exploitation.