Jump to content

Time to Patch WinRAR - 19 year old vulnerability finally found and fixed


Recommended Posts

A vulnerability in WinRAR which has the potential to allow the execution of malicious code has recently been discovered and patched.  Affected versions of WinRAR are any older than version 5.7.0 Beta 1 (yes, unfortunately you must install a beta build to protect yourself from this vulnerability, sadly).  The root cause is in the once popular but now defunct ACE archive format which has long since been abandoned by its original creators.  This vulnerability, which the original ACE archive format's creators had previously patched in their own software years ago before stopping development, has remained unpatched in WinRAR since around 2005 (that's just after the release of Windows Vista just to give you an idea of how long it's been :P).

The latest betas of WinRAR versions 5.7.0 beta 2 and 5.7.0 beta 2 are available on the WinRAR download page located here.

For more details on this vulnerability, including how it was discovered and reported, as well as technical info on how exploits of this vulnerability function can be found here at BleepingComputer:

19-Year Old WinRAR RCE Vulnerability Gets Micropatch Which Keeps ACE Support

Stay up to date and stay safe!

Link to post
Share on other sites

Correct.  This vulnerability allows .ACE archives to run as executables rather than opening like normal archives, thus providing a means of launching a malicious executable in memory.  It's really not that bad of a vulnerability as it's not like something that allows arbitrary code in memory or process injection or anything like that; basically it's on the same level as run-of-the-mill Trojans that disguise themselves as PDFs and other non-PE file types via icons and/or double-extensions.

Link to post
Share on other sites

By Non-PE, I specifically mean things like Script files, DOS executables, Linux executables, JAR files, and so on. MalwareBytes doesn't scan those, but just because a dormant threat can't affect your current system does not mean it can't affect other systems, especially on a business or development platform, or when using peer-to-peer file sharing.

I only even found out that MalwareBytes didn't try to scan DOS executables because of a file called PAPER.TXT/PAPER.EXE, a research paper (about itself) which was also an executable program. Early on in the paper, it mentioned that virus scanners may pick it up. I manually scanned it with MalwareBytes, and it didn't detect anything, but when I showed the paper to MalwareBytes staff they told me that it was because it was a DOS executable and would thus have little to no threat potential against a modern operating system. Or so they say... you can never be too careful, IMHO.

Link to post
Share on other sites

Actually, Malwarebytes does scan DOS executables (assuming you mean things like .COM files), .SCR files and several other non-EXE file types and containers (archives etc.).  If you're referring to a 16-bit DOS executable, then no, it isn't a threat in modern operating systems, at least as long as the OS is 64 bit as x64 operating systems aren't compatible/will not run 16-bit executables as they are only backwards compatible to x86/32-bit executables.

Scanning script files is beyond useless and the reason that Malwarebytes doesn't bother is because it's so easy to evade detection by altering them (since they're nothing more than glorified text files) that even I, not being a developer/hacker/coder could change a script file myself to make it evade detection by an AV.  Detecting such threats behaviorally in the context of how they are used in actual attacks is far more effective and is where Malwarebytes focuses their efforts, via components like their advanced heuristics engine (Shuriken) and their Exploit Protection component.

Refer to the information in this article to see what I'm referring to.  It's an old article but still relevant, and is the reason that even the top AV vendors generally focus more on behavior based detection of script based threats today rather than relying on the obsolete signature based detection techniques of the past (which Malwarebytes has never ascribed to for this very reason).

Link to post
Share on other sites

That still does you no good (read the article if you haven't already as it addresses this very thing) because what is written can be modified, encrypted or even built/written using a completely proprietary language/formatting that is only understood/interpreted by the malware overseeing the attack (like a binary/in-memory thread that interprets commands from the script and executes them, for example in cases like file-less malware that use Powershell and the like or threats that drop encrypted non-PE script files as .DAT and other nonsense formats that only they can read in temp folders etc. to slip under the radar of AV/AM engines that use traditional detection methods).

Sandboxing/simulation isn't a bad idea, but Malwarebytes Research already has these capabilities on the cloud side of things and they develop signatures and augment MB3's protection layers based on the results so it's already well covered (they parse out all the connections, databases, exploits, scripts, install patterns etc. that a threat/attack will use and harvest that data for enhancing their signatures, block lists and protection components to target anything they missed).

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
Back to top
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.