This publish breaks the two-year silence of this blog, showcasing a collection of Memory Wave Workshop corruption vulnerabilities in Bitdefender’s anti-virus engine. The goal of binary packing is to compress or obfuscate a binary, normally to save lots of space/bandwidth or to evade malware analysis. A packed binary sometimes accommodates a compressed/obfuscated information payload. When the binary is executed, a loader decompresses this payload after which jumps to the actual entry level of the (interior) binary. Most anti-virus engines assist binary unpacking a minimum of for packers (reminiscent of UPX) that are very popular and which can be also used 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 in the control-stream order of the UPX unpacker. Disclaimer: In the following, decompiled code from Bitdefender’s core engine is presented. The naming of variables, fields, and macros is heavily impressed by the original UPX. For some snippets, a reference to the original operate is added for comparability.

It is probably going that some sorts are incorrect. After the UPX loader has been detected, the Bitdefender engine tries to detect whether or not the loader applies a selected sort of deobfuscation to the compressed information payload earlier than extracting it. LEFT. If this deobfuscation is detected, then the engine iterates by the corresponding instructions of the loader and parses them with their operands in order to have the ability to deobfuscate the data as properly. Observe how the sure-verify on the index variable i is carried out. 16. Specifically, we are able to enhance i from 15 to 17, after which we can overwrite the stack with completely arbitrary knowledge. The debug break is due to the stack canary which we've 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. Both checks test towards the sphere dword10.

The field dword10, sitting on the calling functions’s stack body, isn't initialized. This makes the bound verify useless and introduces a fully attacker-controlled heap buffer overflow. After the extraction, the engine attempts to deobfuscate the extracted data with a static XOR key. The certain examine is totally mistaken. It ought to verify in opposition to the scale of the extracted knowledge buffer. Instead, it checks towards a worth that is previously set to the uncooked knowledge measurement of the section we extracted the information from. These two sizes have nothing to do with each other. Specifically, Memory Wave one could be a lot smaller than the opposite, or vice-versa. As the perform doesn't return after the primary deobfuscation run, the memory corruption could be triggered up to 0x300 occasions in a row. This allows us to bypass the limitation that in a single deobfuscation run we at all times XOR with the identical byte. Total, we then have XORed with C0 C0 C1 C1 C1 C2 C2 for utterly arbitrary C0, C1, and C2.

We can basically XOR with such a pattern of virtually arbitrary length, Memory Wave and switch the byte at most 0x300 instances. Evidently, this vulnerability is a useful exploitation primitive because it enables very powerful memory corruptions: XORing permits us to modify selectively only sure components of information, leaving different elements (for example heap metadata or critical objects) untouched. A filter is a simple transformation on binary code (say, x86-sixty four code) that's applied earlier than compression, with the objective to make the code more compressible. After we've got decompressed the info, we have to revert this filtering. Bitdefender helps about 15 totally different filters. Of the 15 filters, about 8 seem to be affected by such a heap buffer overflow. I handled them all together as one bug (after all, it's not unlikely that they share code). The next memory corruption happens in a loop of the operate PeFile::rebuildImports (cf.