Tuesday, May 15, 2018

Windows Updates Broke Your Networking? Free Micropatches To The Rescue (CVE-2018-8174)

A Single-Instruction Micropatch For a Critical Remote Execution Issue

by Mitja Kolsek, 0patch Team

Last week, Microsoft issued an update resolving (among others) a critical remote code execution issue in VBScript Engine named CVE-2018-8174, exploit for which has previously been detected in the wild.

Unfortunately, Microsoft's update breaks networking on some computers (details below), prompting users to avoid their application. Windows updates are "all or nothing" these days, so users can't just remove a defective KB and enjoy the protection provided by other KBs issued on the same Patch Tuesday. Fortunately, micropatching provided by 0patch is the exact opposite of that, addressing each vulnerability individually. Let's start with the exploit and the underlying vulnerability.   

It appears the exploit has been caught by at least two security firms, Kaspersky and 360, and they both issued detailed analyses of the infection chain and, more importantly for us, the vulnerability itself [Kaspersky's analysis, 360's analysis]

The vulnerability is triggered by this simple proof-of-concept provided by Kaspersky:


Dim ArrA(1)
Dim ArrB(1)

Class ClassVuln
    Private Sub Class_Terminate()
        Set ArrB(0) = ArrA(0)
        ArrA(0) = 31337
    End Sub
End Class

Sub TriggerVuln
    Set ArrA(0) = New ClassVuln
    Erase ArrA
    Erase ArrB
End Sub

TriggerVuln


By simply saving the above code to poc.vbs and double-clicking it on a Windows computer without May 2018 updates installed, we trigger the vulnerability and get wscript.exe to crash in oleaut32.dll's VariantClear function .


Access Violation in OLEAUT32.DLL's VariantClear due to accessing an unallocated memory address

 

Let's see what goes on here. We create two fixed-size arrays ArrA and ArrB with one element each.
A ClassVuln object is created and assigned to the first element of the ArrA array, then the ArrA array is erased. There is just one element in the array, namely the ClassVuln object, and Erase sets ArrA(0) to Nothing, which removes all references to the object and triggers its destruction.

Our object has a weird method called Class_Terminate. This is a class event that's not officially supported in VBScript anymore but apparently still works and gets called upon object's destruction. (If you're wondering why unsupported functionality still works it's probably because removing it would break an unknown number of production scripts that are using it, and cause much more headache than keeping it and removing it from documentation.)

In our Class_Terminate, the first element of ArrB is set to ArrA(0) - but wait, ArrA(0) is the very object being destroyed, and you can imagine where this is heading. This assignment increases the reference ("lock") count for the object, but the following instruction (ArrA(0) = 31337) decreases the same reference count, which will lead to the object being actually destroyed.

However, after being destroyed, there will still be a reference to this object in ArrB(0), which is called a "dangling pointer," i.e., a pointer to a memory block that has already been freed. In this case the object was allocated on the heap, so now ArrB(0) has a reference to some location on the heap, and those versed in exploiting "use after free" issues have a nice starting point to make use of this reference.

We're not interested in exploiting this issue, however, but in patching it. To do that, we first need to understand the vulnerability.

Kaspersky researchers pointed their fingers at the VBScriptClass::Release function, which only checks the object reference count before calling VBScriptClass::TerminateClass (this executes our Class_Terminate code), and doesn't account for the case where Class_Terminate would increase the object reference count. So even though the reference count was increased (by Set ArrB(0) = ArrA(0)), the object still gets destroyed.

We're not sure that this is the (entire) root cause, although we would probably try to fix the issue using this avenue if we didn't have Microsoft's official patch that contains information on how they fixed it.

After applying the May 2018 Windows updates, executing the PoC has a different result:


Patched Windows show a runtime error

The error states: "Object required: 'ArrA(...)'" in line 6, indicating that the assignment of ArrA(0) is not possible as ArrA is not an object (anymore).

First we decided to compare code execution between the patched and the unpatched version using WinDbg's wt (trace and watch data) command. Fortunately symbols are available for oleaut32.dll so the traces looked fairly identical up to the point where the patched version "derailed" from the unpatched version's path towards crashing. It turned out the fork happened in function vbscript!AssignVar, executed as a result of assigning ArrA(0) to ArrB(0). In this function (which hasn't been modified by the patch), a test is being made on the vt (variant type) member of a VARIANT structure, which in our case denotes the ArrA(0) element. And it turns out on the unpatched computer, vt is 9 (VT_DISPATCH) while on the patched computer, it is 0 (VT_EMPTY).

This means someone must have changed the value of vt from 9 to 0 along the way. In order to find out who did that, we placed an access breakpoint to the address of vt sometime earlier in the execution where it was still 9 on the patched computer.

Bingo! We found a "mov word [rdi], bp" instruction in our old friend, the VariantClear function, which sets our vt to 0. (rdi points to the VARIANT structure, and ebp is 0 throughout the function.)

It was time for BinDiff. We compared the patched and the last unpatched version of oleaut32.dll (which is where the crash occurs), and looked at the modified functions. Unsurprisingly, VariantClear was slightly modified in several places (orange blocks on the image below). Three of these blocks set the vt (variant type) member of a VARIANT structure to 0, which means VT_EMPTY, or an empty object.



Left: unpatched code; Right: patched code





Our PoC executes the middle orange block, and that block contains - in its patched version - the instruction that sets vt to 0.

So we created a micropatch that injects a logically identical instruction to the vulnerable code. Since the vulnerable code uses rbx as the pointer to the VARIANT, this is what we needed to inject:

mov word [rbx], 0

And this is the source code for our micropatch:


; Patch for CVE-2018-8174 in oleaut32.dll version 6.1.7601.23775 64bit
MODULE_PATH "c:\windows\system32\oleaut32.dll"
PATCH_ID 321
PATCH_FORMAT_VER 2
VULN_ID 3568
PLATFORM win64

patchlet_start
 PATCHLET_ID 1
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0x000011bf

 code_start

  mov word [rbx], 0 ; Set VARIANT's vt to 0 (VT_EMPTY)

 code_end

patchlet_end


Sure enough, applying this micropatch stopped the wscript.exe from crashing and made its behavior identical to the officially patched version:

The old version with our micropatch has an identical reaction to our PoC as the new version.


Our micropatches for this vulnerability have been labeled ZP-320 and ZP-321 for 32-bit and 64-bit version of oleaut32.dll respectively, and are applicable on Windows 7 and Windows 2008 Server updated up to April 2018 Windows updates. Why only these versions? Well, updates KB4103718 and KB4103712 are reportedly causing networking problems on some computers, which prompts users to delay their application - remaining vulnerable to the issue we have micropatched here. We have reports of Windows 7 and Windows 2008 Servers being affected, but if you or someone you know is experiencing this issue on other Windows versions, just ping us and we'll quickly port these micropatches.

As always, if you have 0patch Agent installed, the above-mentioned 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-2018-8174 at least until Microsoft resolves the functional problems with their updates.
 

Cheers!

@mkolsek
@0patch



Friday, March 30, 2018

Security Patching is Hard - Survey Results 2017


https://0patch.com/files/SecurityPatchingIsHard_2017.pdf

by Stanka Salamun, 0patch Team

Are you tired of constant inflow of software updates that require your attention and time? Well, you are not alone. While timely security patching plays an important role in providing a secure enterprise IT environment, dealing with patches as they are released at an unmanageable rate, seems to be an overwhelming task. 

We are presenting our first Security Patching is Hard - Survey Results 2017, revealing struggles and obstacles companies and individuals deal with when they try to be up to date with security patching. The survey was inspired by security experts that opened a debate over their patch fatigue after the Equifax leak.

For the first impression on survey results check out the infographic of the key takeaways.



Security Patching is Hard - Survey Results 2017




There is one obvious message from our research: the process of software patching should be simplified. 

For a dive into the facts and numbers behind the security update gap, download the report.  It reveals the main reasons for the patching fatigue, the impact of legacy software and how the relationship with software vendors influences the pace of applying security updates.


https://0patch.com/files/SecurityPatchingIsHard_2017.pdf
 


Monday, February 19, 2018

Two Interesting Micropatches For 7-Zip (CVE-2017-17969 and CVE-2018-5996)

by Luka Treiber, 0patch Team

Based on the vulnerability report from Dave we developed micropatches for heap buffer overflow CVE-2017-17969 and insufficient exception handling CVE-2018-5996 in 7-Zip version 16.04.


CVE-2017-17969

By diffing source code of the patched version 18.00 and the vulnerable version 16.04 we found the following changes related to CVE-2017-17969 (highlighted lines mark patched code).


001: // ShrinkDecoder.cpp

163:     lastSym = sym;
164:     unsigned cur = sym;
165:     unsigned i = 0;
166:     
167:     while (cur >= 256)
168:     {
169:       _stack[i++] = _suffixes[cur];
170:       cur = _parents[cur];
171:       // don't change that code:
172:       // Orphan Check and self-linked Orphan check (_stack overflow check);
173:       if (cur == kEmpty || i >= kNumItems)
174:         break;
175:     }
176:     
177:     if (cur == kEmpty || i >= kNumItems)
178:       break;
179:



We disassembled 7z.dll version 16.04 and found the above changes affect two offsets - 0x000a5ab4 and 0x000a5abb (both marked in red):




We then created micropatch code resembling source code lines 173 - 174 and 177 - 178 by using two patchlets, the first one extending (piggybacking on) an existing conditional statement (the end of the while loop - jnb loc_100A5A9C) and the second one introducing an additional conditional statement:

; CVE-2017-17969 patch for 7z.dll 16.04 
MODULE_PATH "C:\0patch\Patches\7zip\16.4\7z.dll"
PATCH_ID 316
PATCH_FORMAT_VER 2
VULN_ID 3295
PLATFORM win32

patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x000a5ab4
JUMPOVERBYTES 5
N_ORIGINALBYTES 5

;piggybacking jnb 
;3D 00 01 00 00                       cmp     eax, 100h
;73 CE                                jnb     short loc_100AAF28
;if (cur == kEmpty || i >= kNumItems)
;    break;
code_start
    cmp eax, 100h
    jne skip1  ;cur != kEmpty?
    STC             ;set piggyback condition for jnb to NOT jump
    call PIT_ExploitBlocked
    jmp end
  skip1:
    cmp esi, 2000h
    jb skip2  ;i < kNumItems?
    STC             ;set piggyback condition for jnb to NOT jump
    call PIT_ExploitBlocked
    jmp end
  skip2:
    cmp eax, 100h ;original code
  end:
code_end
patchlet_end

patchlet_start
PATCHLET_ID 2
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x000a5abb
PIT 7z.dll!0xa5bc4
JUMPOVERBYTES 0
N_ORIGINALBYTES 5

code_start
    cmp eax, 100h
    je block        ; cur == kEmpty?
    cmp esi, 2000h
    jge block       ; i >= kNumItems?
    jmp skip
  block:
    call PIT_ExploitBlocked
    jmp PIT_0xa5bc4 ; break
  skip:
code_end
patchlet_end



CVE-2018-5996

The source code patch for CVE-2018-5996 introduced the following changes (highlighted lines mark patched code):


001: // Rar3Decoder.h
194:   bool m_IsSolid;
195:   bool _errorMode;

001: // Rar3Decoder.cpp

089: CDecoder::CDecoder():
090:   _window(0),
091:   _winPos(0),
092:   _wrPtr(0),
093:   _lzSize(0),
094:   _writtenFileSize(0),
095:   _vmData(0),
096:   _vmCode(0),
097:   m_IsSolid(false),
098:   _errorMode(false)
099: {
100:   Ppmd7_Construct(&_ppmd);
101: }

827: HRESULT CDecoder::CodeReal(ICompressProgressInfo *progress)
828: {
829:   _writtenFileSize = 0;
830:   _unsupportedFilter = false;
831:   
832:   if (!m_IsSolid)
833:   {
834:     _lzSize = 0;
835:     _winPos = 0;
836:     _wrPtr = 0;
837:     for (int i = 0; i < kNumReps; i++)
838:       _reps[i] = 0;
839:     _lastLength = 0;
840:     memset(m_LastLevels, 0, kTablesSizesSum);
841:     TablesRead = false;
842:     PpmEscChar = 2;
843:     PpmError = true;
844:     InitFilters();
845:     _errorMode = false;
846:   }
847: 
848:   if (_errorMode)
849:     return S_FALSE;
850: 
851:   if (!m_IsSolid || !TablesRead)
852:   {
853:     bool keepDecompressing;
854:     RINOK(ReadTables(keepDecompressing));
855:     if (!keepDecompressing)
856:       return S_OK;
857:   }

890:   return S_OK;
891: }

929:   catch(const CInBufferException &e) { _errorMode = true; return e.ErrorCode;}
930:   catch(...) { _errorMode = true; return S_FALSE; }


When developing a micropatch for this vulnerability, we had to patch the CDecoder class that had to be extended by a new member - the _errorMode variable. This was the first time we attempted something like that with 0patch. So we either had to make room for the new variable (increase the allocated object memory block) or find existing unused space within the object's memory layout. By searching for cross references to CDecoder member variables (in offset range around the m_IsSolid variable 1c6d - 1c7c) we found offsets 1C6Fh, 1C79h, 1C7Ah, 1C7Bh to be unused. Based on this we selected and assigned the first one of the available offsets - 1C6Fh - to the new _errorMode variable.

Our micropatch contains five patchlets that correspond to five code offsets in 7z.dll that had to be patched:

  • Patchlet 1: We micropatched offset 0x000a0388 (the CDecoder::CDecoder constructor) with code resembling line 195 of RarDecoder.h and line 98 of Rar3Decoder.cpp.





  • Patchlets 2 and 3: We micropatched offsets 0x000a25bf and 0x000a25de with  code resembling lines 845 and 848-849.



  • Patchlets 4 and 5: We micropatched  offsets 0x000a22ee and 0x000a22f6 with code resembling changes to lines 929-930.


This is the 0pp file implementing these patchlets:


; CVE-2018-5996 patch for 7z.dll 16.04 
MODULE_PATH "C:\0patch\Patches\7zip\16.4\7z.dll"
PATCH_ID 315
PATCH_FORMAT_VER 2
VULN_ID 3296
PLATFORM win32

; added variables:
;  _errorMode (this+1C6Dh)
;
patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x000a0388
JUMPOVERBYTES 0
N_ORIGINALBYTES 5

code_start
  mov [esi+1C6Fh], bl ; _errorMode=0 //ebx set to 0 at offset a030a
code_end
patchlet_end

patchlet_start
PATCHLET_ID 2
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x000a22ee
JUMPOVERBYTES 0
N_ORIGINALBYTES 5

code_start
  mov  [esi+1C6Fh], bl ; _errorMode=0 //ebx set to 0 at offset a2278
code_end
patchlet_end

patchlet_start
PATCHLET_ID 3
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x000a22f6
PIT 7z.dll!0x000A2452
JUMPOVERBYTES 0
N_ORIGINALBYTES 5

code_start
  cmp [esi+1C6Fh],bl ; _errorMode=0 //ebx set to 0 at offset a2278
  jz skip
  call PIT_ExploitBlocked
  jmp PIT_0x000A2452
 skip:
code_end
patchlet_end
patchlet_start
PATCHLET_ID 4
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x000a25bf
JUMPOVERBYTES 0
N_ORIGINALBYTES 5

code_start
  mov  eax, [ebp+08h]      ; catch(const CInBufferException &e) {
  mov byte [eax+1C6Fh], 1  ;  _errorMode = true;
                           ;  return e.ErrorCode;}
code_end
patchlet_end

patchlet_start
PATCHLET_ID 5
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x000a25de
JUMPOVERBYTES 0
N_ORIGINALBYTES 5

code_start
  mov  eax, [ebp+08h]      ; catch(...) { 
  mov byte [eax+1C6Fh], 1  ;  _errorMode = true; 
                             ;  return S_FALSE; }
code_end
patchlet_end
 

These two micropatches have already been published and distributed to all installed 0patch Agents. If you're using 32-bit 7-Zip version 16.04, you can download our free 0patch Agent, create a free 0patch account and register the agent to that account to immediately receive these micropatches and have them applied to your 7-Zip executable.

If you're using some other version of 7-Zip and would like to have micropatches for it, please contact us at support@0patch.com.



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

[Update 2/20/2018: We've just issued a micropatch for another Equation Editor vulnerability, CVE-2018-0798. Big thanks to the 360 Vulcan Team for their help with that!]


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 (right-click on it and select "Edit"), find in it the path to EQNEDT32.EXE, and change it to the actual path in the EQUATION folder on your computer where you restored the files in step A. IMPORTANT: The path should use double back slashes instead of single ones (just like in our sample reg file above), so make sure to duplicate all back slashes in your path.
  3. Import the modified EquationEditor.reg to registry by first launching the Registry Editor (regedit.exe) as Administrator, then selecting File-Import... in its menu and browsing to your EquationEditor.reg file.

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.

Important: you will be able to - and are highly encouraged to - keep applying official Office updates after completing this procedure to keep future vulnerabilities in other parts of Office patched. The whole point of this blog post is to help you keep Equation Editor while keeping your Office Applications updated.

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 - [Updated 2/20/2018] one for CVE-2018-0802 and one for CVE-2018-0798, 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. Nine vulnerabilities having been found in it in quick succession 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