Bitdefender: UPX Unpacking Featuring Ten Memory Corruptions - Landave'…

This publish breaks the 2-year silence of this weblog, showcasing a collection of Memory Wave System corruption vulnerabilities in Bitdefender’s anti-virus engine. The aim of binary packing is to compress or obfuscate a binary, usually to save space/bandwidth or to evade malware analysis. A packed binary usually comprises a compressed/obfuscated information payload. When the binary is executed, a loader decompresses this payload after which jumps to the precise entry point of the (interior) binary. Most anti-virus engines assist binary unpacking a minimum of for packers (similar to UPX) which are very fashionable and that are additionally utilized by non-malware software program. This blog post is about UPX unpacking of PE binaries in the Bitdefender core engine. The next vulnerabilities are introduced within the control-move order of the UPX unpacker. Disclaimer: In the following, decompiled code from Bitdefender’s core engine is introduced. The naming of variables, fields, and macros is heavily impressed by the original UPX. For some snippets, a reference to the unique function is added for comparability.

It is probably going that some types are incorrect. After the UPX loader has been detected, the Bitdefender engine tries to detect whether the loader applies a specific kind of deobfuscation to the compressed information payload before extracting it. LEFT. If this deobfuscation is detected, then the engine iterates via the corresponding directions of the loader and parses them with their operands in order to be able to deobfuscate the data as well. Observe how the bound-check on the index variable i is performed. 16. Particularly, we can improve i from 15 to 17, after which we can overwrite the stack with completely arbitrary information. The debug break is as a result of stack canary which we've got overwritten. If we continue, we see that the return fails because the stack is corrupted. Obviously, this offsets must be checked before writing to it. Each checks check towards the sector dword10.

The sphere dword10, sitting on the calling functions’s stack body, isn't initialized. This makes the certain verify useless and introduces a fully attacker-managed heap buffer overflow. After the extraction, the engine makes an attempt to deobfuscate the extracted knowledge with a static XOR key. The bound examine is completely unsuitable. It should test towards the scale of the extracted knowledge buffer. Instead, it checks against a price that is beforehand set to the raw data size of the section we extracted the information from. These two sizes don't have anything to do with one another. Specifically, one may be much smaller than the opposite, or vice-versa. Because the operate doesn't return after the primary deobfuscation run, the memory corruption can be triggered up to 0x300 instances in a row. This permits us to bypass the limitation that in a single deobfuscation run we always XOR with the same byte. General, we then have XORed with C0 C0 C1 C1 C1 C2 C2 for fully arbitrary C0, C1, and C2.

We will basically XOR with such a sample of nearly arbitrary length, and switch the byte at most 0x300 instances. Needless to say, this vulnerability is a useful exploitation primitive because it enables very highly effective memory corruptions: XORing permits us to change selectively solely sure elements of data, leaving different elements (for example heap metadata or critical objects) untouched. A filter is an easy transformation on binary code (say, x86-sixty four code) that is applied earlier than compression, with the objective to make the code more compressible. After we have decompressed the info, we need to revert this filtering. Bitdefender helps about 15 different filters. Of the 15 filters, about eight appear to be affected by such a heap buffer overflow. I handled them all together as one bug (in any case, it isn't unlikely that they share code). The following memory corruption happens in a loop of the perform PeFile::rebuildImports (cf.