Apple’s macOS Finder is vulnerable to remote code execution, despite its desperate efforts to fix it.
In a security advisory published on behalf of researcher Park Minchan, the SSD Secure Disclosure program explained, the macOS Finder provides a visual interface for interacting with files, it is vulnerable to documents with the .inetloc extension.
The advisory says, “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.”
Theoretically, Apple’s macOS security mechanisms are Quarantined, for preventing the download from launching without user action, and Gatekeeper to enforce code signing. Yet users are able to execute commands when downloaded and double-clicked.
Researchers discovered the PoC file on macOS Big Sur (version 11.6), executed without any warning. Patrick Wardle said, the PoC code bypasses both of those mechanisms. Apple operating system software was affected by a similar flaw called CVE-2009-2811, more than a decade ago with the .fileloc extension in Mac OS X 10.5.8.The .inetloc file extension has been around since 2004 but it isn’t well documented. Even Apple’s own developer site does not recognize them and macOS views them as Internet locations.
The advisory suggests the .inetloc files serve as shortcuts to Internet resources like an RSS feed or a telnet location. The files may include a server address and possibly login credentials for SSH or telnet sessions. Also, they can be created by typing a URL in a text editor and dragging the text to the macOS Desktop if the format and drag-and-drop are supported within the app.
Example of a PoC inetloc.inetloc for lack of a better name, looks like.
[callout bg=’#f9f9f9′ color=’#000000′ border=’#000000′ font=’arial’ radius=’5′] <?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”>
According to the advisory, Apple told the SSD Disclosure Program that newer versions of macOS, from Big Sur onward, have blocked the file:// prefix with a check-in com.apple.generic-internet-location. Though Apple’s engineers evidently failed to consider upper and lower case variations, so alternative renditions of the file handler like File:// or fIle:// still bypass the check.
The advisory further said, “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.”