(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.)
CVE: CVE-2011-3229
Found by: Aaron Sigel
Summary:
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.
Arbitrary Javascript can be executed in the web context of the Safari extension.
Affected Versions:
Safari 5.0 and later on Mac OS X and Windows
Details:
First, Apple's description of Safari Extensions:
"Safari Extensions are a great way for you to add new features to Safari. Built by developers, Safari Extensions use the latest HTML5, CSS3, and Javascript web technologies. And they’re digitally signed and sandboxed for improved security. You can install extensions with one click — no need to restart Safari."
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:
safari-extension://name-of-extension-[version_specific_string]/[dynamic_value]/path-to-file
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
3. Load my payload, and use it to execute the Javascript in the context of the extension
4. This Javascript access any file accessible to the extension, or access resources available to the extension (think Javascript accessible databases).
Some details of how my proof of concept accomplishes this:
The first step in exploiting this issue is to obtain the 32bit id. For 1Password's extension I accomplished this with a Javascript that causes it to inject an iframe into the current page. The src attribute is readable via document.getElementById().getAttribute("src"), which contains this value.
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:
~/Library/Caches/com.apple.Safari/Extensions/[extension_name]/
Our goal is to start evaluating arbitrary Javascript with the privileges of the Safari Extension. After watching how Safari downloads files, I found that Safari's sandbox'ed process pokes a hole in the sandbox to allow read access on files while they are being downloaded. These are download bundles that have no unpredictable path components and are created in ~/Downloads. This meant that loading the attacker's Javascript was as simple as pushing a file download to Safari (Insert shout out to Nitesh Dhanjani whose Safari Carpet bombing technique still works in Lion and fully patched version of Safari) and loading it in an iframe. To make sure I could access the file while it was being downloaded, I just made a large file. At a couple of megabytes, the temporary download bundle reliably existed when and where I needed it to.
At this point the Javascript included in the download executed in the safari-extension zone.
What can be done on Mac OS X:
* Execution of arbitrary Javascript in the web context of installed extensions, which includes,
* 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.
Shout outs:
cstone, cykyc, Nitesh Dhanjani, jduck, KF
References:
* Apple's advisory:
* Previous Safari file stealing vulnerability, Safari ErrorJacking:
http://vttynotes.blogspot.com/2011/03/safari-errorjacking-cve-2011-0167.html
* Apple's documentation on accessing resources inside Safari Extensions:
http://developer.apple.com/library/safari/#documentation/Tools/Conceptual/SafariExtensionGuide/AccessingResourcesWithinYourExtensionFolder/AccessingResourcesWithinYourExtensionFolder.html
No comments:
Post a Comment