|This could have been fixed in 2004|
In many previous articles I talked about a design flaw in Safari that is simple to unconditionally fix but would lead to an endless series of new vulnerabilities if Apple attempted to simply patch the symptoms.
It's almost two years since I first commented on this, and Apple is still patching the symptoms.
The wrong way to do it
Check for the type of a file in two places with two different pieces of code, and assume that if the first check has determined that the file is safe to open with the application it expects to be able to use to open it, that the file is safe to open.
The problem is that it's not the file that's safe to open, it's that there's an application that is designed to handle unsafe files of that type. If you can create a file that Safari treats as a "safe" type, but LaunchServices opens as an application, you can run arbitrary code on the victim's computer.
But you can't prevent people from running applications from the Finder!
The right way to do it
Provide an interface for applications to use when opening untrusted files. this interface (either an option to LaunchServices or an alternative "WebServices") would only contain applications that had explicitly registered themselves as being intended for use on untrusted content. programs of this type tend to be viewers or browsers, and there are few enough that it's no great burden to ask the publishers to add a call or plist entry to register them as "web safe".
In some cases you might actually have different applications in this database... for example, a "word viewer" rather than the full blown "Word". The result would be a system that was both more secure and more convenient for the user, the alternative is to end up with a security problem as bad as Microsoft Windows and Internet Explorer.
It's not just Safari
Any application that deals with untrusted documents (web pages, email attachments, music files) and uses LaunchServices to open them is potentially vulnerable.
For one example, Mail.app allows you to open attachments by double-clicking them... if it's going to do this at all it needs a secure way to do so. For another, the original "help:" exploit in 2004 worked for Firefox as well as Safari. Firefox is less exposed than Safari because it treats fewer files and URIs as 'safe', and appears to maintain its own list of applications and plugins to open untrusted files. The potential of another "trusting" URI handler, though, is still there.
It's not just Apple
Microsoft's file types in Internet Explorer and Windows Explorer are highly vulnerable (and have often been exploited), and even if they cleaned up the ActiveX mess they would still have to deal with this kind of attack. There are applications for UNIX like "run-mailcap" that have the potential of introducing the same avenue of attack, though so far as I know there have not been any recent exploits of this type.
This problem is closely related to the Unicode quoting attacks against IIS, the shell quoting attacks against web applications, SQL injection attacks, and other quoting or injection attacks. Whenever content is checked for security in one component and then re-interpreted in another there's the potential for an attack.
Checking for possible attacks can be made to work by aggressively restricting or editing the content, but only at a cost... previously working applications can be broken, and people with names like "O'Toole" find themselves locked out, so in general "sanitizing" the input should be used as a last resort.
Wherever possible, secure interfaces that don't re-interpret the content should be used, or the interface itself needs to implement the security. In UNIX, call a helper directly by "exec" rather than passing it to a command line interpreter with "system". For SQL, use prepared statements and bound parameters. In Mac OS X? Maintain your own table of safe applications, and call them explicitly rather than trusting LaunchServices to pick the right one...
And get on Apple's case about a secure interface for opening untrusted content... one that doesn't itself trust LaunchServices in turn.
Update, May 2006: More bugs created or turned into security holes by the same design flaw.
|Lynx-enhanced by <peter at taronga.com> (Peter da Silva)|