Why It Makes Sense To Micropatch a Vulnerability When Official Fix Is Available
by Mitja Kolsek, the 0patch Team
Yesterday, Checkpoint published a detailed vulnerability report about a serious vulnerability in WinRAR (reportedly used by 500+ million users) which allowed a malicious archive, when extracted, to create an arbitrary file in a chosen location on user’s computer. This includes,for instance, user’s Startup folder where said file would get executed when the user logged in to Windows again.
Nadav Grossman, the researcher who found the vulnerability and wrote the report, nicely described
the flow of his analysis, including the problems he stumbled into, and tools he used to analyze the vulnerability. Anyone interested in analyzing vulnerabilities, or in details of this particular one, is advised to read his report.
The vulnerability (CVE-2018-20250) was present in WinRAR’s extracting of ACE archives, whereby said extracting was actually done using a dynamic library UNACEV2.DLL written by e-merge GmbH, maintainer of WinACE software. This DLL, interestingly, hasn’t changed since 2005 - which actually attracted Nadav’s attention.
At the time the report was published, WinRAR producer RARLAB was already offering a fixed version of WinRAR (7.50 beta 1) on their download page, and their fix was very simple: being unable to fix the vulnerability, they dropped support for ACE format. (You might remember Microsoft doing something similar with the 17-year old Equation Editor last year.)
To Micropatch Or Not To Micropatch?
For us at 0patch, a vulnerability like this is inherently interesting: it allows for a remote code execution, it potentially affects millions of users, and the product doesn’t auto-update so it is likely to be present for a long time. And while we’ve micropatched a bunch of 0days lately, 0patch is primarily meant to bridge the security update gap by fixing vulnerabilities that may already have an official fix.
In deciding whether to micropatch this one, we came up with the following supporting arguments:
- This vulnerability is a perfect candidate for malicious phishing campaigns. "Please review the attached purchase order PO.rar."
- WinRAR is a really widely used product. Maybe it doesn’t actually have 500 million users but still.
- No auto-update means that most users will never update it. In fact, unless one has actually read about this vulnerability (surely most users haven’t) and feels threatened by it, why would one take the time to update?
- Some users may actually need the ACE format support. Granted, there is still WinACE, but in contrast to WinRAR, its maintainer seems long gone.
- From defensive perspective, blocking exploits of this vulnerability is not as simple as rejecting files with .ace extension, as a malicious file can also be renamed to .rar or .zip (or likely any other supported extension) as long as it’s extracted with WinRAR. The user can’t even tell that a ZIP file is actually an ACE file.
- Some of 0patch users are probably also users of WinRAR. By creating a micropatch, we will protect them without them even being aware of this WinRAR vulnerability, or the fact that we micropatched it. (Letting users not worry about patches and not disturbing them with patching is a core concept of 0patch.)
- Admins with multiple 0patch Agents on users’ computers would like the fact that whichever version of WinRAR, even if old and vulnerable, their users use or “temporarily” install, they will be protected against this issue.
As you suspected, we decided to go ahead.
Fortunately, Nadav’s analysis provided most of the details we needed (big thanks, Nadav!) and a potential solution was fairly obvious. If you look at Figure 15 in his report and the accompanying text, you’ll see that the exploit causes the execution through a branch that allows the malicious file path to remain a relative path by prepending it with… well, an empty string. So the idea was to always force the execution through the other branch, which prepends the malicious path with the target directory.
This way, instead of allowing malicious paths like:
to pass unmodified, they would become (when extracted to C:\temp):
These are both invalid paths and an application can’t create a file using them.
One question remained open, however: Do any legitimate use cases need the code branch we were planning to “amputate”? Such use case would include intentionally extracting a file to a location specified with full path on user’s computer; which would be considered a vulnerability of equal severity than the issue we’re fixing here. So we concluded that removing this branch is an acceptable approach, and wrote this single-instruction micropatch:
JUMPOVERBYTES 10 ; We remove mov and call
mov eax, 0 ; making sure to proceed via the “absolute path” branch,
; not the “empty string” branch
When the micropatch is applied, extracting a malicious ACE archive results in a number of warnings as shows below, and files aren’t extracted.
By micropatching this vulnerability in a 14-year old closed-source DLL we demonstrated how suitable in-memory micropatching is for quickly fixing a critical vulnerability, even when fixing it in source code is literally impossible.
As always, if you have our Agent installed and registered, this micropatch is already on your computer - and applied to WinRAR whenever it loads UNACEV2.DLL (enable popups via 0patch Console to see when that happens). Otherwise, you can register a free 0patch account and install 0patch Agent to get this micropatch applied to your WinRAR.
Nevertheless - if you don’t need support for ACE format in WinRAR, we recommend you update WinRAR to a fixed version (currently 5.70 beta 1). There may be other vulnerabilities there in UNACEV2.DLL which are more likely to be found now that it’s been put in the spotlight.