WinRAR: disclosed self-extracting archive vulnerability is none
A security vulnerability found in the latest version of popular compression program WinRAR puts users of the software program at risk according to security researcher Mohammad Reza Espargham.
Attackers can exploit the vulnerability to execute code remotely on target machines requiring little user input in the process.
The vulnerability takes advantage of WinRAR's self-extracting archives capability. This feature enables you to create archives that extract when they are executed so that compression software such as WinRAR is not required on the system the contents of the archive need to be extracted on.
It offers a convenient way to distribute compressed files, run commands before or after extraction, display license information or text and icons to the user extracting the contents.
And it is this text and icons feature that attackers can exploit to run code remotely on the system. This is done by adding specially crafted HTML code to the text part which in turn will executed code on the target system when the user runs the self-extracting archive on the system.
Successful exploits enable attackers to run code on target systems, for instance to create new user accounts, install software or manipulate system settings.
WinRAR's response suggests that the reported vulnerability is in fact none. The main reason for the statement is that self-extracting archives are executable files which end users need to run on their system.
Attackers could add payloads to the executable file itself as well or simply create a file that looks like a self-extracting archive, or, and this is without doubt another important argument, run any files included in the archive on the target machine automatically.
WinRAR self-extracting archives can be configured to run run files without user interaction which is even easier than having to add specially crafted HTML to the text component of the self-extracting archive.
Basically, what the folks at WinRAR are saying is that it makes no sense to limit the HTML capabilities of the program as there are simpler means to run malicious code on user systems.
The take away for users is that executable files can be harmful when they are run on machines. There are several ways to improve safety when it comes to running untrusted executable files on Windows PCs, for instance by using Sandboxie, a sandboxing program, or running these files in a virtual environment.
Now You: How do you handle untrusted files on Windows?
More info: this is vulnerability in OLE component of IE, and only works for unpatched machines.
via http://habrahabr.ru/company/defconru/blog/267983/#comment_8597139
I’ll translate:
To author of this thread: lukasafonov! obviously, seasoned hackers of DefconRu could not understand that it it not exploit, but script-kiddies ripped bullshit.
Firstly, this is not a vulnerability, it’s feature of Winrar to embed arbitrary HTML code. Second, the “exploit” is a remake of the CVE-2014-6332 / MS14-064 (decode the payload code from base64). Proof â„–1:
https://github.com/rapid7/metasploit-framework/blob/3347b90db7e6ebc143aa9b4a46ac0da10240db17/modules/exploits/windows/browser/ms14_064_ole_code_execution.rb.
Here another script-kiddie R-73eN declares that he is the real author of this steep «exploit»: http://www.darknet.org.uk/2015/10/winrar-vulnerability-is-complete-bullshit/#comment-164931
In fact, the real author of the vector – Chinese researcher yuange. This RCE for Microsoft Internet Explorer Windows OLE Automation Array he researched back in 2009. Proof â„–2:
https://twitter.com/yuange75/status/532407606644457472.
For those who still do not understand the essence, I try to explain on the fingers:
1) The problem is not directly connected with WinRAR – it is a bug OLE component MSIE.
2) Vulnerability CVE 2014-6332 works only on non-patched boxen.
3) With the same success tons of foolish exploits can be washed in for most programs that use standard component of a Web browser (any software that is written using such IDEs as the Delphi, Visual C ++ Builder, etc).
LTR; DR.
@Decent60. All browser functions defaults to sandbox.
WinRar staff is partially right. From a point of view, it is a flaw that WinRar routine allows to put executable instructions where only text and icon data should be found – even if it is partially a Windows executable’s flaw not having data and code separated in a more robust way.
On the other side, once the user trust and run an executable (and this is correct in WinRar team response) one can simply put the malicious payload in the executable itself rather than resorting in hiding it somewhere – anyway the damage is already done once the users click the exe!
Personally I’m more confident in open source software alternatives, as 7-Zip (or the less known PeaZip), any time I must trust a program to handle my dearest data.
I agree with WinRAR. HTML is a feature. No sense limiting it when it’s easier to run a real executable that’s malicious.
@CuriousGeorge just the basic firewall with all rules set to custom.
Thanks much!
@LogicDaemon. Winrar or whatever, no access to internet or registry unless I click OK on Comodo.
@Dante, so you have to approve every time a webpage is loaded or every time a new http connection is made through a web browser?
If not, then this vulnerability will bypass that firewall if you have a web browser open, since it’ll use the HTML coding and your default browser to execute the code, not WinRAR.
@Dante. Which Comodo solution are you using to accomplish that?
What exactly is the vulnerability, again? Running code after user manually executes some .exe?! FFS! (resurrecting some facepalm meme)
@Dante it has nothing to do with winrar, it’s about SFX module (which is completely separate executable and can come in many different forms).
Well, technically, it’s vulnerability. But it’s usability is 0 (zero).
@Nebulus maybe it’s not a bug, maybe it’s “by design” (because their sfx is badly documented anyway).
To add to this nonsense:
Windows has larger extreme vulnerability: it can load and execute files! This bug must be fixed once and for all. This will also prevent any vulnerabilities like this with WinRAR.
“Windows has larger extreme vulnerability: it can load and execute files! This bug must be fixed once and for all. This will also prevent any vulnerabilities like this with WinRAR.”
Haha! Well said LD. :D
“Windows has larger extreme vulnerability: it can load and execute files! This bug must be fixed once and for all. This will also prevent any vulnerabilities like this with WinRAR.”
Exactly, usually the bug isn’t the software or the computer, it’s the user who decides to run or install a questionable file without any precautions.
My firewall has always blocked programs like winrar from accessing internet.
Hehe such people are always the easiest target as they are sure of their safety and skills :D
As it has been mentioned, it has nothing to internet. At least at the first stage ;)
And the firewall is as good as rules created.
But if you are sure you are behind the iron wall that is great ;)
This has nothing to do with the Internet, and everything to do with a vulnerability in WinRAR’s “display HTML text on extraction” capability.
And what, pray tell, is the vulnerability? If you’re brain dead enough to run an untrusted EXE, no-one can help you. The fact that the SFX can run another EXE is a feature and can be triggered in various ways (see RAR SFX comment scripting for more). tl;dr: Ain’t no problem here unless user lacks common sense, or a functioning brain.
Actually, the vulnerability does exist and WinRAR need to fix their code. It doesn’t matter that “Executable files are potentially dangerous by design” (as WinRAR correctly notice), a found bug has no place in their code and downplaying it doesn’t make anyone more confident.
Actually, no vulnerability exists and WinRAR code needs no fixing (not for this particular bit of nonsense news).
The HTML part should be fixed, however, it doesn’t make it any less dangerous than any other *.exe file.
One thing to note is that the person who setup the *.sfx.exe file can just have a virus run at the start of the execution to begin with.
While that part would more-than-likely be detected by the antivirus at the start of the execution (hopefully, at the time of the download) the HTML part might not get picked up right away, especially if it uses a secondary vulnerability, like something in Adobe Flash.
It is still would be nice for them to acknowledge that it can be abused and work on a way to fix it.