A high-severity vulnerability has been fixed in WinRAR, the popular file archiver utility for Windows used by millions, that can execute commands on a computer simply by opening an archive.
If I ever use windows, I use 7zip.
7zip has been my go to for awhile. It also has the nice bonus of not having nagware asking for money. :)
Forgive my ignorance, but hasn’t this vulnerability existed pretty much as long as archive filetypes have? For as long as I can remember it’s been standard practice to distrust any archive file I didn’t create myself or get direct from a trusted source, I thought for this very reason.
Or is the actual headline that this vulnerability is finally addressed in WinRAR?
The flaw is tracked as CVE-2023-40477 and could give remote attackers arbitrary code execution on the target system after a specially crafted RAR file is opened.
And from the linked advisory:
The issue results from the lack of proper validation of user-supplied data, which can result in a memory access past the end of an allocated buffer. An attacker can leverage this vulnerability to execute code in the context of the current process.
What’s going on is the specially crafted RAR, when opened, creates an unchecked buffer overflow. This dumps a shell to the process, and a payload can be executed in that shell, hiding from the user behind that process. This is different than the normal behavior you describe, where extracting a RAR can autolaunch executable code contained in the RAR in its own separate process, visible to the user (in task manager, for example), and running in the user context.
In Windows, if you have run WinRAR with admin rights, and confirmed with the User Access Control (UAC) dialog, the attacker code would also run with admin rights, without any additional UAC warning. In the “normal” behavior, you would get a second UAC warning when the autorun executable tried to run.
Pretty much whenever you see the phrase “arbitrary code execution,” this is the kind of thing that’s happening. Some of those are more serious than others, depending on the flaw. Certain kinds of flaws can return a shell in the SYSTEM context, which has even more permissions than admin.
How does an unchecked buffer overrun result in dropping to a shell inside the containing process though?
I’m not super clear on that, and I’m eager to have someone inform/correct me, but here’s my understanding:
It’s like a crash. The running program tells the system to address memory that is not available to be addressed, and the system goes “Uh, what?” and drops into a state where it has stopped following the code from the initial thread (which I am sure is not the right terminology) and waits blankly for new code to be received.
Then the still running-but-“hung” process delivers that “arbitrary code,” and the system dutifully executes it.
I think you’re talking about the tar bomb or zip bomb. This new one is far worse.
My bad, guys. If I’d paid for winrar, they would have had the resources to prevent this.
WinRAR 6.23 fixes the issue.
The thing is, you only need WinRAR if you were creating an archive. You never need it for extracting archives. For that, you just use pretty much any other archiver.
