(Sorry for the poor quality of the video, blogger seems to mess these up. Maybe I need to just find a new place for this blog.)
Found by: Aaron Sigel
Safari is vulnerable to a directory traversal issue with the handling of "safari-extension://" URLs.
Attackers can create malicious websites that trigger Safari to send files from the victim's system to the attacker.
Safari 5.0 and later on Mac OS X and Windows
First, Apple's description of Safari Extensions:
Another quote from Apple's Developer documentation on what scripts can do:
"Your injected scripts can access resources—images, HTML, and other scripts, for example—within your extension folder. Relative URLs are relative to the webpage your script is injected into, however. If you need to access local resources, use safari.extension.baseURI + “relative path and filename”. You cannot access resources on the user’s hard drive outside of the extensions folder."
Safari Extensions access their internal resources (images, scripts, etc) by prepending filenames with the value of safari.extension.baseURI, which is a dynamic path that changes every time Safari loads the extension. The format of full safari-extension URLs is:
Due to a directory traversal vulnerability in the handling of these URLs, any file readable by Safari's sandbox can be accessed by attackers. In these URLs, the only component that is not generally known to attackers is the dynamic value. The dynamic value is a 32bit number represented as a lowercase hex string. While there are attacks that could attempt to guess this value, more effective routes to exploit this issue have been found.
These URLs may be used by content injected into web pages, exposing the dynamic value by reading the DOM. The method and exploitability depends on the code in the extension, but proof of concepts have been generated that work against the 1Password, ClickToFlash, and several other extensions. This should not be considered a security vulnerability in those extensions. They are following the guidelines provided by Apple for what should be a safe operation.
The vulnerability here is that safari-extension URLs, with the help of directory traversal, have the ability to access local resources anywhere the system will allow the process to read.
Exploiting this bug:
The steps I used to exploit this bug are:
1. Find the dynamic part of the safari-extension URL
2. Find a way to access my payload from inside the Safari sandbox
Some details of how my proof of concept accomplishes this:
Once the attacker has this value, arbitrary paths to files readable by Safari's sandbox are reachable. Additionally useful to the attacker is that no usernames have to be guessed in order to access files in the user's home directory. This is because paths to files in the URL are relative to:
What can be done on Mac OS X:
* Access to the safari object in the web content, exposing the SafariContent classes
* Full SQL access to extensions' client-side databases
* Access to any files that WebProcess.app, Safari's sandboxed process can read, which includes,
* Files opened by Safari during this process's life
* Local files in loaded extensions
* Other files being downloaded by Safari
* Safari's Cache database
* Safari's Local Storage databases
* Safari's HTML5 Offline Applications
* User Keychain files
* Quarantined application event logs
* DYLD shared cache/maps
What can be done on Windows:
Apple's Safari Extensions website claims that they are sandboxed. This was verified when accessing the site with Safari for both Mac OS X and Windows 7. However unlike Mac OS X, successful exploitation on Windows can access files wherever the user can read. It seems that sandboxing is either not implemented for Safari on Windows 7 or that the sandboxing does not limit file reading.
What this means:
* On Mac OS X, Safari's sandbox still allows access to a bunch of sensitive and useful data
* On Windows, sandboxing does not limit the files accessible to the attacker (if sandboxing occurs at all)
* Sandbox limits the badness that can be done with Safari exploits on Mac OS X. Hopefully Safari will adopt more process separation to further limit the damage possible from vulnerabilities.
cstone, cykyc, Nitesh Dhanjani, jduck, KF
* Apple's advisory:
* Previous Safari file stealing vulnerability, Safari ErrorJacking:
* Apple's documentation on accessing resources inside Safari Extensions: