As the fallout from The Hacking Team compromise continues, another zero-day in their possession has come to light. This one consists of a kernel vulnerability that not only provides privilege escalation, but also remote code execution.
It’s serious enough that Microsoft released an out-of-band patch for it earlier this week. Microsoft rarely issues out-of-band patches (anymore), which speaks to the wide prevalence and potential impact of this vulnerability. The vulnerability affects all current versions of Windows, and there are multiple possible vectors an attacker could use to leverage it. In addition, proof-of-concept code that demonstrates the vulnerability has been released, meaning it won’t be long before we start seeing this vulnerability leveraged in more attacks.
Knowing how difficult it is in many organizations to effectively patch monthly, along with the fact that Microsoft has EOL’d Windows 2003 and XP (meaning we shouldn’t expect a patch on those platforms), we looked to find a way to mitigate this threat using Bit9.
It turns out that Microsoft’s recommendation for those unable to patch is to simply rename the vulnerable dll, preventing its use and, by extension, its ability to be leveraged in an attack. While this, of course, could be done via scripts and pushed out using management tools, it is much simpler and safer to write a custom rule in Bit9 to block the loading of the vulnerable dll.
The dll in focus here is ATMFD.dll. This is Adobe’s OpenType module manager, used to allow applications to display their own custom fonts. To try and learn a bit more about how this file is used in a real-world environment, we did a search in Carbon Black to see what uses the dll.
This is easily done by navigating to the process search page and entering modload:atmfd.dll in the query box. We got back a fairly large number of results, showing the vast majority of processes (at least in our environment) loading this dll happened to be the kernel itself. This makes sense, as it is a kernel vulnerability, which also makes the vulnerability much more concerning.
Implementing the rule in Bit9 is straightforward. Navigate to the rules menu, and select “Software Rules.” From there, select the custom tab and click the button for “Add custom rule.” Then, all we need to do is to create the rule that will block the execution of this dll.
It should look something like this:
Note that you can scope this to a particular policy—for example, one that only includes systems for which a patch is unavailable. We use the macros <System> and <Systemx86>, as placeholders for \Windows\System32 and the 32-bit equivalents on 64-bit systems \Windows\SysWOW64. This ensures we cover all possibilities for 32- and 64-bit platforms.
After creating the rule and ensuring that it is enabled, it will be pushed down to the agents for immediate enforcement. Unfortunately, because the vulnerable dll might already be loaded in the kernel, a reboot is likely necessary to ensure protection. After the reboot, the dll will not be allowed to be loaded, and attackers will be unable to leverage the vulnerability.
As MS mentions, this may, in fact, break some apps that rely on these types of fonts. MS itself has stated it doesn’t use this dll, so hopefully any negative consequences will be minimal. The good news is this workaround can be easily backed out after all your systems have been patched. Simply disable the rule and the dll will again be able to be properly loaded.
As usual, this is not intended to be a substitute for patching, but should help mitigate your exposure while you scramble to install the out-of-band patch, or if you’re in a situation where you need to run Windows 2003 or XP systems and a patch is not available.