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.
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.
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?
And from the linked advisory:
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.