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

[exile360]

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 ).

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!

[Smarion1]

I was gonna be a smarta** but all I can do is smh at the idiots that didn't catch this.. thanks for the heads up. I've use winRaR alot.. 

[exile360]

Yeah, that's a pretty long time to leave a vulnerable component in their product like that.  I'm just glad they finally got around to fixing the issue.

[Firefox]

Does that mean that it only affects you if you try to open an ACE zipped file?

[exile360]

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.

[Amaroq_Starwind]

MalwareBytes really needs to add scanning of non-PE filetypes >.<

[MaaarscW]

oh, its already there

 

re: non-PE file type
 

Hats off to Aahh Starwind STAR KID !

[Amaroq_Starwind]

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.

[exile360]

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).

[Amaroq_Starwind]

What I meant by scanning scripts is to run them in an online simulation as a means of testing their threat level, and trying identify patterns in the way they're written.

[exile360]

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).