A fairly simple processing bug in WinRAR resulting in code execution with benign seeming interaction with an archive; unfortunately this one was seen being exploited in the wild to spread malware.

The normal flow when double clicking on a file inside of an archive inside of WinRAR is that the selected file will be extracted into a temporary directory and then it will be executed using a call to ShellExecuteExW which will look at the filename and open it using the default handler.

There is a potential issue is that when you double-click on a file, WinRAR may end up not only extracting the selected file but any file that starts with the same text. Seems like a weird behavior to me, but it also feels fairly intentional that it exists so I’m not sure this aspect is strictly speaking a bug. The end result though is that if you have a file named xyz.jpg and a directory names xyz.jpg/ if you double-click on xyz.jpg then that file will be extracted along with all the files under the directory. Though the actual xyz.jpg/ is not created, just the files extracted.

The primary issue is in this extraction process where the function that actually creates the output file will try to fix up the filename a bit, if the filename inside of the archive ends with a ` ` or some other characters, the dangling characters will be trimmed from the output filename. On its own this isn’t too bad, but the rest of the system isn’t informed that the filename changed, so later when ShellExecuteExW is called, it is called with the filename that has not been trimmed. If there is another file in the same directory that does start with that non-trimmed filename, it will be executed instead.

So the attack relies on a archive structure similar to the follow:

• example.png
• example.png /example.png .cmd

In this case, double-clicking on example.png will result in two files being extracted into the temporary folder. example.png (the trailing space will be trimmed) and example.png .cmd. Then when ShellExecuteExW is set to execute the example.png file it will match the .cmd file instead of the .png resulting in whatever code inside of the .cmd file being executed.

While the bug does take user-interaction limiting its impact severely the fact that the actual user interaction is seemingly benign and is a fairly common action makes this seem like a reasonably likely scenario. Adding to that this sort of last-minute filename sanitizing/changing is a bug that can creep up in many places and is a bit of a code-smell to keep an eye out for. It won’t always lead to code execution but file-confusions are an interesting primitive to have in any environment.