Live data from Hacker News

F-Secure Anti-Virus: Remote Code Execution via Solid RAR Unpacking

landave.io

1–10 of 30 posts

Re: F-Secure Anti-Virus: Remote Code Execution via Solid RAR Unpacking

#2
Wow, this is a neat exploit. It breaks ASLR with a static payload, only employing some decompression tricks to combine randomized addresses with fixed ROP targets. I like the technique and I think it could be more generally applied to file exploits.

Re: F-Secure Anti-Virus: Remote Code Execution via Solid RAR Unpacking

#5
post #4

What are each of F-Secure RAR ASLR massage the heap (what heap, where) ROP chain RarVM etc.

An article about something assuming domain knowledge? Say it ain't so!

F-Secure: an antivirus

RAR: an ancient archival format

ASLR: address space layout randomization, a system which loads code at unpredictable locations to make exploits harder to write (as you don't know where to jump)

ROP chain: Return Oriented Programming. A way to circumvent non-executable memory protection and ASLR by manipulating the call stack to jump into to existing executable code segments (called gadgets) and chain them together as each returns to the next.

RarVM: an ill concieved mechanism allowing code to be embedded in RAR archives.

Re: F-Secure Anti-Virus: Remote Code Execution via Solid RAR Unpacking

#8
post #7

And MalwareBytes is still using 7zip 18.01

7-zip is licensed LGPL, so you should be able to replace the 7z support library with a newer version.

That is false. It's likely the end-user can update it, but the LGPL does not prevent it from being impossible.

The LGPL makes it perfectly legal for the closed-source antivirus component to not load any 7zip .so binary that is not signed by the antivirus vendor, of a known hash, or so on... and the code loading said shared-object need not be available or modifiable, just the code for the vulnerable .so they do ship.

Re: F-Secure Anti-Virus: Remote Code Execution via Solid RAR Unpacking

#9
post #8
post #7

Earlier quoted context omitted.

7-zip is licensed LGPL, so you should be able to replace the 7z support library with a newer version.

That is false. It's likely the end-user can update it, but the LGPL does not prevent it from being impossible. The LGPL makes it perfectly legal for the closed-source antivirus component to not load any 7zip .so binary that is not signed by the antivirus vendor, of a known hash, or so on... and the code loading said shared-object need not be available or modifiable, just the code for the vulnerable .so they do ship.

The LGPL clearly states that a Combined Work which includes the the Library must "1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version." as well as insisting that the terms of the license under which you distribute the Application "effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications" maybe!) you could make an argument that your shared library loader was legit while the code using that shared library loader was evil (though that clearly violates the intention of this license in a way that is so blatant I would be shocked if a judge or a jury didn't shake their heads at your claim), but then the rest of the anti-virus software wouldn't be able to be distributed under a typical commercial license as modifications and reverse engineering of that code would have to be allowed.
Post reply on HN