Two months ago, a cybersecurity researcher who calls himself LANDAVE, or just Dave for short, found a security vulnerability in the handy, popular, free utility 7-Zip.
7-Zip is a sort-of Swiss Army Officer’s Knife of file decompression tools that many users install as one of their main add-on Windows apps.
It not only supports its own brand of mega-compressed archive files with the extension .7z, but also knows how to extract data from most other archive formats, too.
Conventional ZIPs, gzip and bzip2 files, Unix tar and cpio archives, Windows CAB and MSI files, Macintosh DMG files, CD images (ISOs), and many more, along with an optional two-pane file management interface that’s perfect for old-school fans of Midnight Commander.
7-Zip also includes support for RAR files, and that’s where the vulnerability came from, apparently inherited from open source code from the standalone UnRAR utility.
Now that 7-Zip has been patched against this bug, dubbed CVE-2018-10115, LANDAVE has published the details of how he found it, and what was involved in figuring out how severe the bug might be.
According to Dave, the problem arose from an all-too-common conflict between complexity and security.
The UnRAR code is complex because it supports many different varieties of compression level and format, including a special sort of compression system that strings multiple files together before compressing them, which often squeezes more bytes out of the compressed data than squashing each file independently.
The RAR file format includes this so-called solid option because it can improve compression by allowing repeated strings of characters to be matched even if they’re in two or more different files, instead of restricting all repeated data fragments to one file. When you have many small but similar files in an archive, for example, this often results in many more repeated string matches being found, thus boosting the compression ratio.
What Dave discovered is that the UnRAR decompression code, as used by 7-Zip, didn’t bother to configure itself safely when you started using it – in other words, your software could innocently lead to a catastrophic failure in the RAR code itself.
That’s a bit like a car rental company hiring out its vehicles in a completely unknown condition each time, relying instead on every driver doing a full and complete check of their own, and correctly fixing any faults, before driving off.
Simply put, a raft of uninitialised variables in the UnRAR code opened the door to the possibility of creating a booby-trapped archive file that would trick the UnRAR code into executing code hidden in the data part of the booby-trapped file.
Remote code execution
Code that sneaks in by masqeurading as data is known as shellcode.
Bugs that allow shellcode to be executed are known as remote code execution vulnerabilities (RCEs), because a crook can use a malicious file, sent in from outside, to run malware on your computer even if all you do is to open the booby-trapped file and look at it.
No download dialogs, no pop-up warnings, no “Are you sure?” prompts.
To cut a long story short, Dave didn’t just figure out a vulnerability that was theoretically exploitable, he also created a proof-of-concept (PoC) exploit that showed how to create a RAR file that, when opened, would sneakily and unexpectedy launch the Calculator app.
Generally speaking, if a PoC can pop up CALC.EXE without asking, it could be modified to run any other command, including malware, invisibly to the user.
ASLR would have helped
Dave’s task of building a working exploit was made much easier because the apps that ship with the 7-Zip software had been created without support for address space layout randomisation (ASLR).
That means the 7-Zip tools would always load into the same memory addresses, simplifying exploits because attackers could predict in advance which handy fragments of executable code would already be loaded, and where, every time you ran the software.
The good news is that Dave managed to persuade the creator of 7-Zip not only to patch the uninitialised variable vulnerability (CVE-2018-10115) in the product, but also to build the updated version with ASLR enabled.
Those changes came out about a week ago in 7-Zip verion 18.05.
What to do?
- If you’re a 7-Zip user, make sure you have the latest version installed.
- If you’re a Windows programmer, don’t ship any software that doesn’t support ASLR. (Using Visual Studio, compile with the
/DYNAMICBASEoption.) - If you’re a programmer of any sort, don’t leave anything to chance when creating new objects – initialise all data fields with safe and sensible values.
For advice on what mitigations to compile into your Windows C and C++ code, take a look at Microsoft’s own Security best practices for C++ (Visual Studio 2015 and later).
Building all the recommended safeguards into your code won’t help you avoid bugs and security vulnerabilities in the first place.
You’ll still need to make every effort to program securely, of course – but the safeguards will help to reduce the exploitability of any vulnerabilities you might overlook.