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

1. the principle of least privilege
2. both data execution prevention (DEP) and ASLR

First, let's look at Guidance EnCase 7.07 on Windows 7:

The 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...

• silent code execution without any noticeable symptoms
• hiding files within the current case
• arbitrary alteration of information provided for the current case
• modification of results of any future case investigated using the compromised machine

There are a few things that we know about software vulnerabilities in general:

• When a new third-party library version is released with fixed vulnerabilities, there is nearly always a delay before the vendor releases a new version of their software that incorporates the fixed library. In the case of both AccessData and Guidance, more than 100 days had elapsed between the release of the fixed library and the release of updated versions of FTK and EnCase, respectively.
• Vendors don't always opt in to using exploit mitigations. Even if all of the software that the vendor produces opts in to exploit mitigations, such as ASLR, they may use third-party software that does not. For example, both FTK and EnCase use a HASP (Hardware Against Software Piracy) DRM module that does not use ASLR or SafeSEH. In other words, the same software that protects the vendor's revenue stream also puts its customers at increased risk. Note that SafeNet has indicated that the licensing API binaries in version 6.4 and later opt in to ASLR, by using the /DYNAMICBASE linker flag, and SafeSEH, by using the /SAFESEH linker flag.
• We would like to have protection against vulnerabilities that are not publicly known. Reacting to individual vulnerabilities as unique, rare events does not make sense.

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 EnCase.exe, 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.