Tuesday, January 16, 2018

Micropatching Brings The Abandoned Equation Editor Back To Life

How We Security-Adopted a Terminated Software Product

by Mitja Kolsek, the 0patch Team




Intro

A few days ago Microsoft's update removed Equation Editor from Microsoft Office, the official reason being "security issues with its implementation." Most Office users couldn't care less about this removal, but if you've been happily using Equation Editor to edit Word documents with mathematical formulas just days ago, you suddenly can't do that anymore. You will still see your formulas in the document but you won't be able to edit them. Instead you'll get this:





We have no idea how many users are affected, but Twitter user @glyph raises an interesting point that those who work with Equation Editor may be tempted to forego this Office update - and by extension all future Office updates -, which will leave them vulnerable to exploits published in the future.   



Worse even, affected users may decide to migrate back to unsupported versions of Office that don't receive security updates at all. This user, for instance, reports going back to Office 2000 on his Windows 10 computer. Office 2000 stopped receiving security updates in 2009.

Microsoft suggested affected users can "edit Equation Editor 3.0 equations without security issues" with Wiris Suite's MathType, a commercial application that costs $97 ($57 academic). They did not specify the basis upon which the phrase "without security issues" was provided, but MathType seems to have a clean public security record so far. Which doesn't say much as that was also true for Equation Editor until someone opened its hood.

We haven't tested MathType and can't tell how easy it is to start using it instead of Equation Editor with existing Word documents, but we don't particularly like the idea of suddenly deleting from users' computers a tool they might be using, and sending them to a store to buy a replacement.

Microsoft's unwillingness to continue supporting Equation Editor is understandable. Their manual patching of its recently discovered vulnerability reveals that, for whatever reason, their standard patching process cannot be applied to Equation Editor, and a deviation like that can be expensive. Furthermore, while they aren't new to manually patching executables, such patching can sometimes be fairly difficult to do. When you patch executable files directly, you may have to come up with a different clever space-saving hack for each patch, which can sometimes be very difficult and time-consuming. For instance, Microsoft's manual patches of Equation Editor required the patch author to invent a way to get some free space in the code for additional patch logic by de-optimizing a memory-copying routine.

So when Microsoft was faced with 8 (eight!)* new vulnerabilities in Equation Editor reported after their manual patch (one also reported by us), they gave up on the idea of continuing manual support for it.

We, on the other hand, haven't.

You see, it's much easier for us to create and support binary patches for a given executable module than it is for Microsoft. Why? Because we have a micropatch delivery agent (0patch Agent) that not only instantly downloads micropatches, but also injects them into running processes on the computer while automatically making room for the added code. So we don't have to invent a new way of making room for every micropatch we make, and can therefore focus on the patch itself. We also deliver our micropatches to agents every hour, and they are as trivial to revoke and un-apply as they are to apply. As much as we hate to repeat ourselves, this is how we believe security patching should look like in this century.

That said, we've already issued our micropatch for CVE-2017-0802, and it's been applied to all computers running 0patch Agent where the latest version of Equation Editor is still present. We're also teaming up with other security researchers who have found vulnerabilities in Equation Editor to micropatch those issues too. We urge everyone who finds additional security issues in Equation Editor to share their findings with us and help up create micropatches for them.


Bringing Equation Editor Back To Life


So you've installed Office Updates from January 9th 2018 and Equation Editor got removed from your computer. Specifically, the update deleted five files (including EQNEDT32.EXE) from the EQUATION folder, leaving the 1033 subfolder and EEINT.DLL inside it intact. It also unregistered Equation Editor as a local COM server by deleting CLSID {0002CE02-0000-0000-C000-000000000046} from registry. Note that Office 2016 still has several files in the EQUATION folder after the update, and in some cases, a 0-byte EQNEDT32.EXE file is left on the system.

The location of the EQUATION folder depends on both the Office version and whether it's 32-bit or 64-bit Office. These are the default locations:

  • 32-bit Office 2007, 2010 and 2013 on 32-bit Windows: C:\Program Files\Common Files\microsoft shared\EQUATION
  • 32-bit Office 2007, 2010 and 2013 on 64-bit Windows: C:\Program Files (x86)\Common Files\microsoft shared\EQUATION
  • 64-bit Office 2007, 2010 and 2013: C:\Program Files\Common Files\Microsoft Shared\EQUATION
  • 32-bit Office 2016 and 365 on 32-bit Windows: C:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\EQUATION
  • 32-bit Office 2016 and 365 on 64-bit Windows: C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\EQUATION
  • 64-bit Office 2016 and 365: C:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\EQUATION

The following images depict the before-and-after of the EQUATION folder when applying the January 2018 Office update.


Office 2010: Content of the EQUATION folder before the update


Office 2010: Content of the EQUATION folder after the update



In order to get Equation Editor back while continuing to receive future Office security updates you need to do two things:

  1. Restore deleted Equation Editor files.
  2. Re-register Equation Editor as a local COM server.
  3. Install free 0patch Agent to keep Equation Editor patched against known vulnerabilities.

Obviously, you don't technically need the last step to get Equation Editor working again, but you don't want to be vulnerable to trivial inexpensive attacks that can be delivered in any Word document you ever receive. So just to be clear, we don't recommend performing steps A and B if you don't also perform step C.


A. Restore deleted Equation Editor files

(Disclaimer: The following is not an official Microsoft-supported procedure and is not guaranteed to work or to not have unwanted side effects. In addition, future Office updates may bring additional blocking of Equation Editor and disable its use. You're doing this at your own risk.) 

Unfortunately uninstalling the Office security update that removed Equation Editor doesn't bring the deleted files back. This leaves you with two options: (a) find a copy of Office you haven't updated yet, or (b) reinstall Office from your original media and apply all updates up to and including November 2017 updates. Once you do any of these, you will find these files in the EQUATION folder (possibly along some other files in Office 2016):

  • EQNEDT32.CNT - help file index
  • EQNEDT32.EXE - Equation Editor executable
  • eqnedt32.exe.manifest - Equation Editor manifest file
  • EQNEDT32.HLP - help file
  • MTEXTRA.TTF - MathType font file

Make sure you have EQNEDT32.EXE version 2017.8.14.0, which is the latest version provided by Microsoft.

What you don't want to do is download the missing files from the Internet, as that is not only a potential violation of your license, but also a great way to get malware on your computer. So don't do that.

Once you have the above Equation Editor files at hand, copy them to the EQUATION folder from which they have been removed on a computer with all updates (including the January 2018 Office update) installed. You will need to have administrative permissions for this, and you may be prompted to overwrite an existing 0-byte EQNEDT32.EXE, which seems to be left on some systems.


B. Re-register Equation Editor as a local COM server

Registering a local COM server requires creating a valid CLSID registry key with required subkeys and values. To make it easier for you, we prepared a template .REG file that you can edit and import in your registry. To do so, follow these instructions:

  1. Download EquationEditor.reg.
  2. Edit EquationEditor.reg, find in it the path to EQNEDT32.EXE, and change it to the actual path on your computer.
  3. Import the modified EquationEditor.reg to registry.

Voila, if everything went well, you can now edit your equation objects in Equation Editor again, and save them back to Word files. Note that it sometimes takes up to a few minutes for this registry change to come into effect; until it does, opening an equation object will result in the "Microsoft Equation is not available" error.

If Equation Editor complains that it's missing a font, reinstall MTEXTRA.TTF.

But you're not done yet! Now you have to get your Equation Editor patched. On to step C.


C. Install 0patch Agent

0patch provides free micropatches for Equation Editor (and many other software products). To install it, download and launch the installer, create a free 0patch account and register the agent to that account. You will immediately receive all Equation Editor micropatches - currently just one for CVE-2018-0802, but as we receive details on the other vulnerabilities, we'll issue additional micropatches.


Expected Questions

These are some of the questions we anticipate and would like to answer in advance.


Q: Why are you doing this? Equation Editor is a 17-year-old pile of insecure code and should die!

In today's "Move fast and break things" world we're accustomed to the idea that software must be perpetually and frequently replaced with new versions. In fact, much of the global software business is built on "incentivizing" users to buy a new version of a product that works just fine for them. Of course the underlying hardware is improving, and new attacks are being invented, so software code effectively does get worse in time even if it doesn't change a bit, but let's hold back for a moment.

"17-year-old code" sounds borderline outrageous to many, but we often forget that there are products we want to keep for 20 years or more. Say, medical devices. If an MRI machine running a  reasonably new, well tested operating system costs $500k, and its hardware can be serviced for 20 years, do we really want to throw it out after 10 years because it stops getting security updates from the OS vendor? Heck no. What we actually want is for it to remain immutable as much as possible for 20 years, and not get any software changes that aren't necessary for its function and security. This is hard to grasp if you're used to replacing half of your operating system every month.

Clearly, Equation Editor is not a life-critical piece of equipment and seems relatively cheap to replace. It does, however, allow for a nice demonstration how an abandoned software product can be "security-adopted" by a 3rd party, allowing its continued use without exposing one's environment to cheap public exploits.


Q: Isn't Equation Editor full of vulnerabilities and risky to use even if you patch the publicly known issues?

It's impossible to say whether any software product is "full of vulnerabilities" or not without thoroughly inspecting it. The fact that nine vulnerabilities have been recently found in it is easily explained by the fact that before Embedi decided to look under the hood, Equation Editor was shielded by a veil of obscurity. Once they've pointed out how its attack surface can be reached from a Word document, it became an easy toy to play with and apparently attracted many researchers. The additional eight vulnerabilities were most likely all low-hanging fruit, i.e., easy to find. But once we patch them, will it be easy to find the next one? No one knows, and if anyone claims to know, kindly ask them for evidence.  


Q: How long are you planning to provide patches for Equation Editor?

With the details we currently have about the known vulnerabilities in Equation Editor, it seems it should be easy for us to micropatch them. Should anyone find additional vulnerabilities in it (and since it's been removed from Office, very few will bother searching), we'll try to micropatch that too. It could happen, although unlikely, that a design vulnerability is found which would be extremely difficult to micropatch, or would require an unreasonable amount of effort on our part. In such case we too will abandon our security support. We hope this will not happen.


Q: How will we receive subsequent micropatches for Equation Editor?

As long as 0patch Agent on your computer has access to the Internet, all subsequent micropatches for Equation Editor will be automatically delivered to your computer and immediately, automatically applied to Equation Editor when it gets launched. If you happen to be using Equation Editor when a new micropatch arrives, the micropatch will get applied to it without disturbing you (i.e., you won't even have to relaunch Equation Editor). 


Outro

There you go. Let us know how this works for you - share your experience, questions and possible concerns in the comments below.

Note that we can only provide support for our micropatches (email to support@0patch.com) and not general technical support for Equation Editor. If you encounter any issues with Equation Editor that you haven't seen before, first disable 0patch Agent and see if the issue is still there. If disabling the Agent resolves the issue, please report it to us, otherwise contact Microsoft.


Cheers!

@mkolsek
@0patch


* The initial public perception after the January Patch Tuesday was that Equation Editor had a single reported vulnerability (CVE-2018-0802) when in fact it was eight of them. However, there have been no public details available on these additional issues as of this writing.




Thursday, January 11, 2018

The Bug That Killed Equation Editor - How We Found, Exploited And Micropatched It (CVE-2018-0802)

One of the Seven Stories Behind an Epic Bug Collision

by Mitja Kolsek, the 0patch Team

[Update 1/16/2018: The "killed" Equation Editor can be brought back to life with instructions provided in our subsequent blog post, and protected from known vulnerabilities with our free micropatches.]

Last November, Microsoft manually patched a remotely exploitable security bug in Equation Editor reported by Embedi. While waiting for Embedi to release their proof-of-concept, we tried to create one ourselves based on then-public information. And indeed, just one day before Embedi published their PoC, we created a Word file that crashed Equation Editor using an excessively long font name.

Then we applied Microsoft's update for this issue.

And then our Word file still crashed Equation Editor.

What?

Naturally, we first assumed that we didn't properly apply the update, but it turned out the update blocked Embedi's PoC while ours was still working. This started a short episode in which we created an exploit for a new vulnerability, wrote a micropatch for it, manually patched EQNEDT32.EXE to fix it, and reported this all to Microsoft. (Who then ruined it all by obliterating Equation Editor from Office.)

Apparently Microsoft got seven (!) reports for this issue, which is quite a bug collision. CheckPoint and Qihoo 360 posted their own analyses online.


The Vulnerability

Our PoC used a similar attack vector as Embedi's PoC (namely, font name), but it turned out that although Microsoft's original patch truncated our font name to 256 bytes (which fixed Embedi's buffer overflow), the truncated font name was still too long for some subsequent strcpy which copied it to a 32-byte buffer on stack.

Specifically, a long font name was able to overflow the 32-byte lfFaceName buffer in a LOGFONTA structure allocated on stack by function sub_421774 and passed as a pointer to function sub_421E39 (which is exactly the same issue Qihoo 360 found). So we had 224 bytes to turn a well-formed Windows process into a weird machine that reliably launches the calculator. And so we did.


The Exploit

When I say "we", it was really my colleague Luka Treiber who did all the work here. Not only he created the initial PoC from scarce details, but he also turned it into a calc-spawning Word document. And mind you, his job was much harder than Embedi's: they did not have to deal with ASLR, while the updated Equation Editor had ASLR enabled so simply returning to a fixed address was off the table. We're not going to release more details at this point as the main purpose of the exploit was to demonstrate to Microsoft that the bug was exploitable, and to serve as a test case for our micropatch.


The Micropatch

Our micropatch is trivial, and logically identical to those Microsoft has manually inserted in several places in the previous iteration of Equation Editor patching. Here is its source code.


; Post-CVE-2017-11882 patch for Equation Editor EQNEDT32.EXE 2017.8.14.0 
MODULE_PATH "C:\Program Files (x86)\Common Files\microsoft shared\EQUATION\EQNEDT32.EXE"
PATCH_ID 312
PATCH_FORMAT_VER 2
VULN_ID 3276
PLATFORM win32

patchlet_start
 PATCHLET_ID 1
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0x00021E5B

 code_start

  cmp     ecx, 21h ; is font name length >= 32?
  jb      skip
  mov     ecx, 20h ; if so, cut it down to 32
  call PIT_ExploitBlocked ; and alert the user of the exploit
  skip:

 code_end

patchlet_end

patchlet_start
 PATCHLET_ID 2
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0x00021E67

 code_start

  xor eax, eax
  stosb ; zero-terminate the string

 code_end

patchlet_end


This micropatch has already been distributed to all 0patch Agents around the globe and is protecting Office users who haven't removed the Equation Editor yet.

The following video shows how our exploit works against a fully patched (as of January 8, 2018) Microsoft Word, and how our micropatch instantly and elegantly fixes the vulnerability.




What We Sent To Microsoft

Ordinarily, security researchers send the vendor only a proof-of-concept and the accompanying write-up to explain the vulnerability. But in the era of 0patch, we can do more than that: We sent Microsoft the PoC (RTF file) and the write-up (TXT file), but also our micropatch for this issue in form of source code (0PP file) as well as a compiled micropatch blob (REG file) that they could test in their own lab. It was our hope that they would try and see how elegantly micropatching works, and consider using it in the future. (We know a couple of billion users that would really appreciate that.)

Finally, since Equation Editor seemed to be patched manually these days, we also manually patched EQNEDT32.EXE and sent it to Microsoft so they could simply use our patched EQNEDT32.EXE, or copy-paste our patched code to their own version.



Our package for Microsoft



Timeline

November 24, 2017: Sent our package to Microsoft
November 25, 2017: Received Microsoft's receipt confirmation and case ID
November 27, 2017: Received Microsoft's notification that the product team was on the case
December 11, 2017: Received Microsoft's notification that they have successfully reproduced the issue
December 15, 2017: Microsoft confirmed that they "received a lot of reports regarding the issue"
January 3, 2018: Microsoft confirmed that this issue would be addressed in the January Patch Tuesday
January 9, 2018: Microsoft's update published, removing Equation Editor from Office
January 9, 2018: Our micropatch published, immediately distributed and applied to all 0patch Agents to protect users during their "security update gap" until they apply Microsoft's update (which sometimes means several months)


Our Call To Security Researchers

Fellow security researchers, we know you want the vulnerabilities you find to get fixed as quickly as possible (why else would you report them to vendors). So consider sharing your PoC privately with us after you've reported the bug to the vendor -  we'll make a micropatch and issue it at the same time as the vendor issues their update to protect users who can't quickly - or at all, for whatever reason - apply the official update.

This applies even more if you have a vulnerability that likely won't get an official patch at all - whether the vendor no longer exists or simply refuses to patch. Let's keep perfectly working products usable longer by closing security holes in them. If you want to, you can even create a micropatch yourself with 0patch Agent for Developers (installer and manual at the bottom of https://0patch.com/).


Cheers!

@mkolsek
@0patch

Wednesday, December 13, 2017

42 Days After Our Micropatch, The Office DDE Vulnerability Gets An Official Fix

Yes, It's Okay Now To Call This "A Vulnerability"

by Mitja Kolsek, the 0patch Team

Introduction

In October, a Dynamic Data Exchange-borne attack vector in Office was published by Sensepost and got quickly adopted by attackers. While Microsoft's official stance at the time was that DDE was behaving as intended and the issue was "considered for a next-version candidate bug," we at 0patch decided to create a micropatch that would prevent all supported versions of Word - and by extension, Outlook - from launching external applications via DDE field updates.

As real-world exploits became more prevalent, Microsoft issued a security advisory explaining how to disable auto-updating of DDE fields (echoing prior guidance from the community). The subsequent release of Windows 10 Fall Creators Update also brought the Attack Surface Reduction feature, which blocked some DDE-borne attacks (although not via Outlook).

Three weeks after we have released our micropatch, Microsoft updated various Office components (including wwlib.dll which we micropatched) for unrelated reasons, prompting us to re-issue micropatches for the modified modules.

Porting micropatches to new product versions (or old versions, for that matter) is a standard procedure with us, so it took us just a few hours from obtaining Microsoft's updates and having all Office versions covered with the new micropatches. Our users didn't notice anything, and that's how we believe vulnerability patching should work in this century.


Enter Vendor's Official Fix

Yesterday, 42 days after we have initially released our DDE micropatch, Microsoft issued an update for Word that provides registry-based configuration of DDE behavior. Users are now able to select whether:

  1. DDE is entirely disabled (this is the default);
  2. DDE works exactly as specified by Microsoft's documentation, i.e., it communicates with already launched applications, but doesn't launch applications itself (this is the behavior implemented by our micropatch);
  3. DDE works as before, allowing DDE-borne attacks.

So what happens on computers with 0patch Agent when this official Word update is installed? Elegantly, our micropatches stop being applied by design when executables they're patching are modified, because that changes their cryptographic hash. Microsoft's update modifies the target module for our DDE micropatches (wwlib.dll), resulting in (1) our micropatches becoming obsolete and (2) DDE getting disabled due to the default setting of the above-mentioned configuration.

We will not port our micropatch to this new Word update as there is no need for that: Office users who apply the latest Word update and want to keep using DDE without the fear of launching malicious executables can create a DWORD registry value AllowDDE under HKEY_CURRENT_USER\Software\Microsoft\Office\version\Word\Security and set it to 1 as described in Microsoft's advisory.

However, users who haven't applied the Word update yet or can't apply it for any reason, will remain protected by our micropatches. If you happen to be in such situation and don't have 0patch Agent yet, simply download, install and register it. It's free.

How does this Microsoft's DDE fix compare to our DDE micropatch?
  • Behavior: The behavior of Microsoft's fixed code is almost identical to our micropatch for AllowDDE value 1. (The former is actually a bit better as it doesn't even ask your permission to launch the application.) For AllowDDE value 0, DDE is completely disabled - our micropatch doesn't provide this option and we actually don't see any security value in it other than reducing the amount of code accessible by malicious documents. Then again, perhaps Microsoft is aware of some other DDE-related attack that this option blocks, or they're simply trying to steer users away from using DDE;
  • Timing: Our micropatch for the DDE issue was available 42 days before Microsoft's official fix;
  • Ease of installation: Installing Microsoft's update requires a computer restart (although the relevant changes are actually applied without that), while a micropatch is installed and applied without any disruption, even while the user is editing a document in Word; 
  • Ease of use: Microsoft's DDE configuration is done via registry, while our patch can be turned on and off either via registry or via 0patch Console's graphical user interface. Also, any user can configure DDE for themselves while only administrator can turn our micropatch on or off. (In other words, 0patch doesn't allow users to make themselves vulnerable again because they liked the way things worked before.)
  • Portability: It would be extremely expensive for Microsoft (not to mention undesirable in the business sense) to port this new DDE configurability to older versions (builds) of Office, especially the end-of-life versions. In contrast, it's trivial for us to port our micropatches to any previous version and build as needed by our users.

Conclusion

In conclusion, this 42-day exercise nicely demonstrated the value of 0patch and micropatching. We proved that a micropatch can be quickly developed for numerous product versions and distributed to all users without disturbance. We showed that when a micropatched product is modified by its vendor, we can quickly re-issue micropatches for it (by the way, there's lots of room for further improvement there). And finally, as this DDE issue was officially patched by the vendor and this fix applied on users' computers, our micropatches for it have reached their intended end of life. For those, however, who for any reason can't apply the Word update or must delay its application due to comprehensive testing requirements, our micropatch remains there for you, for free and for however long you need it. This is exactly how we intend to bridge the security update gap.

Keep your feedback coming! Thank you!

@mkolsek
@0patch

Thursday, November 23, 2017

Microsoft's Manual Binary Patch For CVE-2017-11882 Meets 0patch

by Luka Treiber, the 0patch Team

Last Monday evening Embedi published the PoC referred to in their report and on Tuesday we released a micropatch for the vulnerability. Here is the analysis.

The PoC is in form of an RTF file that, if opened in Microsoft Word, immediately pops up calc.exe. To accomplish this, Embedi overflowed a string buffer on the stack with an overlong font name applied to an equation text.

As shown in their WinDbg screenshot, the overlong font name contains a command string to be executed followed by padding A's until a trailing return address to a WinExec call at offset 2Ch that is supposed to execute the command string. Apparently the WinExec call address, located at font string offset that is already out of bounds of the designated buffer, replaces a legitimate return address on stack so when the vulnerable function returns, the payload gets executed instead.

What was Microsoft's official patch? As already said in our previous post, the diff of EqnEdt32.exe between versions 2017.8.14.0 and 2000.11.9.0 showed only 5 modified functions. Running the PoC with WinDbg attached showed that it executes one of the patched functions, sub_0041160F. There were 5 changed blocks of code in that function, but it turns out the relevant patch that blocks the PoC is the topmost one.


This patch consists of an added boundary check (top square on the left) and buffer truncation code (bottom square on the left)  to a vulnerable memcpy operation that overwrote a stack buffer as previously mentioned. The conditional is placed after counting bytes to be copied from arg_0 to var_28 and makes sure that if the source string is too long, only 0x20 bytes are copied and zero-terminated.

However, this is not the biggest difference applied to the vulnerable code block. The most code reorganization and, we believe, effort had to be put into the middle square where the developer replaced the compiler's memcpy implementation on the right with a more compressed alternative to gain space for injecting the aforementioned security check.

Based on all these findings we wrote our own micropatch:

; CVE-2017-11882 patch for Equation Editor EQNEDT32.EXE 2000.11.9.0
MODULE_PATH "C:\Analysis\CVE-2017-11882\EQNEDT32.EXE"
PATCH_ID 313
PATCH_FORMAT_VER 2
VULN_ID 3084
PLATFORM win32

patchlet_start
 PATCHLET_ID 1
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0x0001164C

 code_start

  cmp     ecx, 21h
  jb      skip
  mov     ecx, 20h
  call PIT_ExploitBlocked
  skip:

 code_end

patchlet_end

patchlet_start
 PATCHLET_ID 2
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0x00011661

 code_start

  xor eax, eax
  stosb ; zero-terminate the string

 code_end

patchlet_end

With this micropatch we did the same thing as Microsoft, only we had no hassle finding the space to inject our code. It is quite ingenious how they managed to compress the code around the patch offset in order to make room for the patch code that required additional 10 bytes. We too need space at the patch offset in order to inject a jmp to our micropatch, however, our technology takes care of automatically injecting these 5 bytes and relocating the original code somewhere else. There are certain requirements that the patch location has to meet (see our 0patch Developer Manual for details), but this is far less constraining than compacting code around the offset like Microsoft had to do.

Our micropatches for this vulnerability have been labeled ZP-313 and ZP-314 (there are two slightly different versions of EqnEdt32.exe) and cover all Microsoft Office versions from 2007 to 2016 and 365. As always, if you have 0patch Agent installed, these micropatches should already be present and applied on your system. If not, you can download a free copy of 0patch Agent to protect your system from CVE-2017-11882.

(By the way, ZP-313 and ZP-314 have replaced the now-revoked micropatch for this issue we had released on Tuesday because we wanted to add the zero-termination code and thus fully mirror the official patch. In case you didn't know how micropatch revocation works, it's just as seamless as everything else: the revoked patch simply stops being applied, and the new one starts getting applied instead. Again, users don't notice anything.)

It was a surprising and an interesting revelation that official software vendors/maintainers also occasionally resort to manual binary patching. Moreover, our analysis of the official patch has shown that in such cases it is harder to directly patch the binary than to use in-memory micropatching. Lastly it may even turn out to be infeasible to patch some bugs in binary files because the code may already be fully optimized for space and the technique seen in Microsoft's CVE-2017-11882 patch would require and unacceptable amount of effort. In cases like that micropatching can turn out to be more agile than traditional patching.

This being said, all that remains is the pleasure of presenting a video of our agile micropatch in action :)





Friday, November 17, 2017

Did Microsoft Just Manually Patch Their Equation Editor Executable? Why Yes, Yes They Did. (CVE-2017-11882)

And They Did an Absolutely Stellar Job

by Mitja Kolsek, the 0patch Team


[Update 11/21/2017]  Today Embedi published their proof-of-concept exploit, which allowed us to see where exactly Microsoft's manual patch blocks it. Contrary to this article's original claim that CVE-2017-11882 was patched in function 4164FA while six other buffer overflow checks we found were for some other attack vectors, it is actually one of those six checks that blocks Embedi's exploit. This article has been slightly corrected to reflect that. In addition, we were now able to create a micropatch for Equation Editor that also blocks all exploits targeting the vulnerability found by Embedi. All Internet-connected computers with a registered 0patch Agent running have already received this micropatch and have it automatically applied whenever Equation Editor is launched. [End update 11/21/2017]


A Pretty Old Executable

The recent Patch Tuesday brought, among other things, a new version of "old" Equation Editor, which introduced a fix for a buffer overflow issue reported by Embedi.

The "old" Equation Editor is an ancient component of Microsoft Office (Office now uses an integrated Equation Editor), which is confirmed by looking at the properties of the unpatched EQNEDT32.EXE:




We can see that File version is 2000.11.9.0 (implying being built in 2000), while Date modified is in 2003, which matches the time of its signature (signing modifies the file as the signature is attached to it.) Furthermore, the TimeDateStamp in its PE header (3A0ACEBF), which the compiler writes into the executable module when building it, indicates that the file was built on November 9, 2000 - exactly matching the date in the above version number.


We're therefore safe to claim that the vulnerable EQNEDT32.EXE has been with us since 2000. That's 17 years, which is a pretty respectable life span for software!

So now a vulnerability was reported in this executable and Microsoft spawned their fixing procedure: they reproduced the issue using Embedi's proof-of-concept, confirmed it, took the source code, fixed the issue in the source code, re-built EQNEDT32.EXE, and distributed the fixed version to Office users, who now see version 2017.8.14.0 under its properties.

At least that's how it would work for most other vulnerabilities. But something was different here. For some reason, Microsoft didn't fix this issue in the source code - but rather by manually patching the binary executable.


Manually Patching an EXE?

Really, quite literally, some pretty skilled Microsoft employee or contractor reverse engineered our friend EQNEDT32.EXE, located the flawed code, and corrected it by manually overwriting existing instructions with better ones (making sure to only use the space previously occupied by original instructions).

How do we know that? Well, have you ever met a C/C++ compiler that would put all functions in a 500+ KB executable on exactly the same address in the module after rebuilding a modified source code, especially when these modifications changed the amount of code in several functions?

To clarify, let's look at BinDiff results between the fixed (2017.8.14.0, "primary") and vulnerable version (2000.11.9.0, "secondary") of EQNEDT32.EXE:



If you're diffing binaries a lot, you'll notice something highly peculiar: All EA primary values are identical to EA secondary values of matched functions. Even the matched but obviously different functions listed at the bottom are at the same address in both EQNEDT32.EXE versions.

As we already noted on Twitter, Microsoft modified five functions in EQNEDT32.EXE, namely the bottom-most five functions listed on the above image. Let's look at the most-modified one first, the one at address 4164FA. The patched version is on the left, the vulnerable one on the right.



This function takes a pointer to the destination buffer and copies characters, one by one in a loop, from user-supplied string to this buffer. It is also the very function that Embedi found to be vulnerable in their research; namely, there was no check whether the destination buffer was large enough for the user-supplied string, and a too-long font name provided through the Equation object could cause a buffer overflow.

Microsoft's fix introduced an additional parameter to this function, specifying the destination buffer length. The original logic of the character-copying loop was then modified so that the loop ends not only when the source string end is reached, but also when the destination buffer length is reached - preventing buffer overflow. In addition, the copied string in the destination buffer is zero-terminated after copying, in case the destination buffer length was reached (which would leave the string unterminated).

Let's look at the code in its text form (again, patched function on left, vulnerable on right):

As you can see, whoever patched this function not only added a check for buffer length in it, but also managed to make the function 14 bytes shorter (and padded the resulting gap before the adjacent function with 0xCC bytes for style points :). Impressive.


Patching The Callers

Moving on. If the patched function got an additional parameter, all those calling it would have to change as well, right? There are exactly two callers of this function, at addresses 43B418 and 4181FA, and in the patched version they both have a push instruction added before the call to specify the length of their buffers, 0x100 and 0x1F4 respectively.

Now, a push instruction with a 32-bit literal operand takes 5 bytes. In order to add this instruction to these two functions while staying within the tight space of the original code (whose logic must also remain intact), the patcher did the following:

For function at address 43B418, the patched function temporarily stores some value - which it will need later on - in ebx instead of a local stack-based variable, which releases enough bytes for injecting the push call. (By the way, addievidence of manual patching is that while the local variable is no longer used, space for it is still made on the stack; otherwise sub esp, 0x10C would turn into sub esp, 0x108.)





For the other caller, function at address 4181FA, the patched function mysteriously has the push instruction injected without any other modifications to the code that would introduce the needed extra space.


As you can see on the above image, the push instruction is injected at the beginning of the yellow block, and all original instructions in that block are pushed down 5 bytes. But why does this not overwrite 5 bytes of the original code somewhere else? It's as if there were 5 or more unused bytes already in existence just after this block of code that the patcher could safely overwrite.

To solve this mystery, let's look at the code in its text form.


Surprise, the vulnerable version actually had an extra jmp loc_418318 instruction at the end of the modified code block. How convenient! This allows the code in this block to be moved down 5 bytes, making space for the push instruction at the top.

Coincidence? Perhaps, but it looks an awful lot like this code block got manually modified before in the past, whereby it got shortened for 5 bytes and its last instruction (jmp loc_418318) was left there.


Additional Security Checks

What we've covered so far was related to Embedi's published research and CVE-2017-11882, but is not what blocks Embedi's exploit. The new version of EQNEDT32.EXE has two additional modified functions at addresses 41160F and 4219F0. Let's have a look at them.

In the patched executable, these two functions got a bunch of injected boundary checks for copying to what appear to be 0x20-byte buffers. These checks all look the same: ecx (which is the counter for copying) is compared to 0x21; if it's greater than or equal to that, ecx gets set to 0x20. All these checks are injected right before inlined memcpy operations. Let's look at one of them to see how the patcher made room for the additional instructions.



As shown on the above image, a check is injected before the inlined memcpy code. Note that in 32-bit code, memcpy is typically implemented by first copying blocks of 4 bytes using the movsd (move double word) instruction, while any remaining bytes are then copied using movsb (move byte). This is efficient in terms of performance, but whoever was patching this noticed that some space can be freed by only using movsb, and perhaps sacrificing a nanosecond or two. After doing so, the code remained logically identical but now there was space for injecting the check before it, as well as for zero-terminating the copied string. Again, an impressive and clever hack (and there was still an extra byte to spare - notice the nop?)

There are six such length checks in two modified functions, and just one of them is directly responsible for blocking Embedi's exploit. We believe that Microsoft noticed some additional attack vectors that could also cause a buffer overflow and decided to proactively patch the other five memcpys and the patched function we covered earlier.


Final Touches

After patching the vulnerable code and effectively manually building a new version of Equation Editor, the patcher also corrected the version number of EQNEDT32.EXE to 2017.8.14.0, and the TimeDateStamp in the PE header to August 14, 2017 (hex value 5991FA38) - which is just 10 days after Microsoft acknowledged receipt of Embedi's report. (Note however that due to the manual nature of setting these values it's possible that code has been modified after that date.)

[Update 11/20/2017] Another thing Microsoft also patched in EQNEDT32.EXE was the "ASLR bit", i.e., they set the IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag in the PE optional header structure:







This is good. Enabling ASLR on EQNEDT32.EXE will make it harder to exploit any remaining memory corruption vulnerabilities. For instance, Embedi's exploit would not work with ASLR because it relied on the fact that the call to WinExec would always be present at the same memory address; this allowed them to simply put that address on stack and wait for the ret to do all the work.

Interestingly, Microsoft decided not to also set the IMAGE_DLLCHARACTERISTICS_NX_COMPAT ("DEP") flag, which would prevent code execution from data pages (e.g., from stack). They surely had good reasons, but should any additional vulnerabilities be found and exploited in EQNEDT32.EXE, the exploit will likely include execution of data on stack or heap. [End update 11/20/2017]


Conclusion  

Maintaining a software product in its binary form instead of rebuilding it from modified source code is hard. We can only speculate as to why Microsoft used the binary patching approach, but being binary patchers ourselves we think they did a stellar job.

This old Equation Editor is now under the spotlight, and many researchers are likely to start fuzzing it for additional vulnerabilities. If any are found, we'll probably see additional rounds of manual binary patches in EQNEDT32.EXE. While Office has had a new Equation Editor integrated since at least version 2007, Microsoft can't simply remove EQNEDT32.EXE (the old Equation Editor) from Office as there are probably tons of old documents out there containing equations in this old format, which would then become un-editable.

Now how would we micropatch CVE-2017-11882 with 0patch? It would actually be much easier: we wouldn't have to shrink existing code to make room for the injected one, because 0patch makes sure that we get all the space we need. So we wouldn't have to come up with clever hacks like de-optimizing memcpy or finding an alternative place to temporarily store a value for later use. This freedom and flexibility makes developing an in-memory micropatch much easier and quicker than in-file patching, and we believe software vendors like Microsoft could benefit greatly from using in-memory micropatching for fixing critical vulnerabilities.

Oh by the way, Microsoft also updated Office's wwlib.dll this Patch Tuesday, prompting us to port our DDE / DDEAUTO patches to these new versions. 0patch Agent running on your computer will automatically download and apply these new patches without interrupting you. If you don't have 0patch Agent installed yet, we have good news for you: IT'S FREE! Just download, install and register, and you're all set. 


Cheers!

@mkolsek
@0patch

P.S.: If you happen to know the person(s) who did the binary patching of EQNEDT32.EXE, please send them a link to this blog post. We'd like them to know how much we admire their work. Thanks! 










Thursday, November 9, 2017

0patching a Pretty Nasty Microsoft Word Type Confusion Vulnerability (CVE-2017-11826)

by Mitja Kolsek, the 0patch Team

In September 2017, Qihoo 360 Core Security detected an in-the-wild attack that leveraged an Office 0day vulnerability now known as CVE-2017-11826. The attack employed an RTF document with embedded DOCX Word documents, whereby one of them exploited the vulnerability to cause type confusion in the OOXML parser, Microsoft's parser for Office Open XML File Formats. Additional noteworthy analyses of this vulnerability subsequently came from McAfee and Kaspersky.

Yang Kang, Ding Maoyin and Song Shenlei of Qihoo 360 Core Security reported this issue to Microsoft, which fixed it in their October security update.

This vulnerability is particularly easy to exploit, as it only requires the user to open a malicious RTF document in Word (which is the default RTF editor when installed), and isn't mitigated by Word's Protected View. It is actually surprising that it's not getting exploited more widely, as attackers know very well that many organizations need weeks or months to apply software updates.

Once we got the exploit file* we could start the analysis. We first minimized the exploit file by removing unnecessary payload and effectively turning it into a crash PoC. Turning a working exploit (one that reliably executes malicious code) into a crash case is an important step for us because in contrast to malware analysts, we're not interested in what malware does when it gets control, but only how it gets control. Making an exploit crash instead of execute its code generally leads us closer to the vulnerability that gets exploited - and closer to writing a patch for it. It's also easier to test a patch, once you have one, with a simple and quick test case.

* Exercise caution with this exploit file - it may run malware on your computer. (Password is aiongnostes1004.)

Analysis

Opening the crash PoC in Word 2010 crashes immediately with a call to an illegal address:


This looks like a call to a vtable function, and since we already learned from Kaspersky above that we're dealing with a type confusion issue, it's likely that we're looking at a case of code processing an object of some expected type with the address at ecx+4 supposedly pointing to a valid function, while the object is actually of a different type.

Type confusion flaws are not the easiest kind to patch if you don't have the source code. While the fix is usually in the form "if type != EXPECTED_TYPE goto GET_OUT_OF_HERE", it's not trivial to figure out where the said type resides in the object without looking around the code where else the same type may be used. Once you have that figured out, it's relatively simple to determine the EXPECTED_TYPE by observing the type value with legitimate test cases and comparing that to the value when you process the PoC. Finding a suitable GET_OUT_OF_HERE location also needs some figuring out: you want the patched code to escape the flaw gracefully without leaving a corrupted state or cutting off some legitimate functionality. So sometimes this can get time consuming - but in this case, we had the official fix so we could peek into what Microsoft did to correct this flaw.

Diffing the patched wwlib.dll with the latest vulnerable one revealed very few changes. In fact, the only noteworthy change was in the exact function containing the above call that crashes. Let's look at the diff:




The patched function is on the left, the vulnerable on the right (click the image to magnify). It's easy to see that the patched function introduced a branch before the grey-marked code in the vulnerable function. And it looks exactly like "if type != EXPECTED_TYPE goto GET_OUT_OF_HERE": it starts with a check for a specific value, and if there is no match, execution is diverted to some new code (marked "Safe exit code" above), which avoids the call that crashed.

The only surprise is that instead of seeing a comparison of some type variable with some type constant (usually a small number, resulting from an enum clause in the source code), we see a comparison with a function address:

cmp ds:[eax+0x48], 0x31E94A4A


Note that 0x31E94A4A is actually an address of some function in wwlib.dll, which gets stored to the address pointed to by eax+0x48 a couple of blocks earlier in the same patched function. So what Microsoft's patch seems so do is check the validity of the object not by inspecting its type (perhaps there is no type ID in the structure at all), but by inspecting the address of a function pointed to by the object. Why not - as long as it works. No one in the world knows this code better than Microsoft's developers and if they thought this was the best possible fix, they're probably right.


Patching

Without further analysis, we can clone the same logic to the vulnerable code. The only thing we add is the "Exploit Attempt Blocked" dialog in case the object type is found to be incorrect. And here is the result:



What Do You Do Now?

We wrote a CVE-2017-11826 micropatch for 32-bit Word 2010's wwlib.dll version 14.0.7182.5000. While it's generally simple, and often fully automatable, to port a micropatch to other module versions, we prefer to do that on demand for now. So if you're running any affected Office version and for any reason can't apply Microsoft's official update (yet) but would like to be protected from this highly exploitable vulnerability, do let us know at support@0patch.com. We'll port the micropatch to your version and make it available for everyone else too.

If you are a security researcher and have a non-public proof-of-concept for some vulnerability, consider either writing a micropatch for it (using 0patch Agent for Developers) or sharing the PoC with us so we can create a micropatch together. You'll see it's almost as fun to thoroughly break someone's exploit as it is to write one ;)

Cheers!

@mkolsek
@0patch



Friday, November 3, 2017

Office DDE Exploits and Attack Surface Reduction

by Mitja Kolsek, the 0patch team


Windows 10 Fall Creators Update brought a powerful security capability: Windows Defender Exploit Guard. Among its many features and mitigations, the one that sounded most interesting to us was the Attack Surface Reduction (ASR) - especially for its announced ability to block DDE-based attacks:


DDE-based attacks have been very popular lately. They are misusing a DDE-related feature whereby Office gets tricked into launching a malicious executable via a DDE or DDEAUTO field, the latter only requiring the user to confirm one non-security notice.

You may also know that we have created a free micropatch for Word that prevents DDE fields from launching any executables - thereby enforcing the behavior specified in official Microsoft documentation, effectively blocking DDE attacks.

We therefore wanted to see how ASR does its magic. So we installed the Fall Creators Update and Office 2010, and followed Microsoft's instructions to enable the "Block Office applications from creating child processes" rule. We tested how DDE-based attacks are blocked, looked around a bit to see what could go wrong, and compared the said mitigation to our micropatch.

You can see the whole process in the video below, but the main takeaways are these:

  1. Most importantly, we confirmed that ASR does block DDE attacks in Word.
  2. Unfortunately, ASR only applies to Word, Excel, PowerPoint and OneNote, so Outlook-based DDE attacks are not blocked. (Perhaps Outlook will be added at a later time?)
  3. Also unfortunately, the ASR rule in question breaks some legitimate functionality. We found, for instance, that  it prevents Adobe Reader from being launched via Word's legitimate "Create PDF/XPS Document" functionality. There is another case (not shown in video) with Word being unable to launch "System Info" from the About dialog. Legitimate Word add-ins may want to launch processes too, and will be blocked.
  4. In comparison, a real fix (in this case, our micropatch) only blocks the dangerous process-launching while leaving all other functionalities intact; it also automatically works in Outlook. Naturally, an actual code fix is always better than a generic mitigation.
  5. Nevertheless, exploit mitigations have one big advantage compared to patches: they can stop or slow down attackers exploiting unknown vulnerabilities. A patch can only fix a known bug.

In conclusion, ASR (with all its rules) is a very powerful tool and while one must exercise caution with its blocking of potentially legitimate functionality, it can significantly limit the attacker. So by all means use it if you can, but also apply patches for known vulnerabilities!

You can't use ASR, unfortunately, on non-Windows-10 systems, or on Office 2007, which has just reached its end of support but is likely still used in many places. 






Stay safe!

@mkolsek
@0patch