URI Security Exploit: Severity of the threat, precautionary steps

Yesterday the Secunia group released a statement implying that Apple's recent Security Update 2004-05-24 did not plug all of the potential security holes that fall under the URI (uniform resource identifier) umbrella:

"Two methods have been discussed, allowing malicious websites to execute code from mounted disk images:

"1) A disk image or a volume (e.g. AFS, SMB, FTP, or DAV) can register arbitrary URI handlers, which will execute code placed on the disk image when accessing the URI.

"2) A disk image or a volume can change an unused URI handler (e.g. TN3270) to execute code placed on the disk image when accessing the URI.

"This problem is escalated due to the fact that it by default is possible to silently download and mount disk images using two known methods (silent download and execution of "safe" files and the "disk" URI). Furthermore, it is reportedly also possible to mount volumes using other methods such as SMB, AFS, FTP, DAV and others.

"This vulnerability has been confirmed on a fully patched Mac OS X system (including the patch 'Security Update 2004-05-24 for Mac OS X' released by Apple, which fixes the 'help' URI handler vulnerability).

However, as pointed out by a number of readers, while the threat of a security exploit is real, Secuina may be overstating the potential for damage.

As has been discussed frequently in recent weeks, once malicious code has been placed on a user's system, the damage that can be done to Mac OS X is severely limited in comparison to the damage that can be done to some Windows systems with the same level of user access.

For instance, Windows XP comes with five Internet ports open, potentially allowing malicious code to perform damaging network activities - these include the ports for instant messaging and other purposes. In fact, some Windows users have had to use a third-party tool like ZoneAlarm Pro to lock down these ports. Mac OS X comes with all of these counterpart ports turned off and locked to casual access.

As pointed out in a recent Washington Post article, "Users get broad rights, but critical system tasks require entering a password. If, for instance, a virus wants to install a 'backdoor' for further intrusions, you'll have to authorize it. This fail-safe isn't immune to user gullibility and still allows the total loss or theft of your data, but it beats Windows' anything-goes approach."

Further, the nature of Mac OS X's permissions system allows only the root user access to critical system files - so even if malicious code were able to infiltrate a user's non-admin account, the damage that could be done would be limited to data deletion and some other less significant issues.

Still, a the notion of malicious code that could potentially delete personal files or wreak other havoc is less than comforting. So aside from applying Apple's security updates, what should you do?

Some users have suggested setting up a separate account without admin privileges specifically for Web browsing or using a haxie like Paranoid Android, which attaches code to running applications to block access to URI handlers. But John Gruber has posted an easier, and perhaps more fail-safe method to his Daring Fireball web log:

"Using RCDefaultApp [a Mac OS X 10.2.x or higher preference pane that allows a user to set the default application used for various URL schemes, file extensions, file types, and MIME types], set the following URI protocols to ?disabled?:

• afp:
• disk:
• disks:

"?afp:? defaults to the Finder; ?disk:? and ?disks:? to DiskImageMounter. These default settings are vulnerable.

"The ?ftp:? protocol is also assigned to the Finder by default. You should either assign it to another applications (e.g. Interarchy, Transmit, Fetch, FTPeel, etc.) or disable it. Do not leave it assigned to the Finder.

"These changes prevent web servers from being able to automatically mount server volumes on your Mac. [...] a mounted server volume could contain an application which registers a custom URI scheme with Launch Services, which in turn could be used by the web server to launch the application. [...] (Also) Using RCDefaultApp, disable the ?telnet:? URI protocol. In its default setting (assigned to Terminal) a ?telnet:? URI can overwrite the contents of any file for which you have write privileges."

Also, as noted in a previous MacFIxIt article, you should turn off Safari?s "Open 'safe' files after downloading? option on the application's "General Preferences" pane. Other browsers that have a similar option (Opera is one of the few that is immune to this vulnerability) should likewise have it disabled. And of course, make sure you have Apple's latest security updates installed.

Feedback? Late-breakers@macfixit.com.

Resources