Safari Issues:
With the release of Mac OS X v10.7, Apple made Safari run sandboxed. According to Apple:
"Sandboxing
All the websites and applications you use in Safari are sandboxed, so they don’t have access to information on your system. If a website contains malicious code intended to capture personal data or tamper with your computer, sandboxing provides a built-in blocker that restricts the code from doing harm."
-- http://www.apple.com/macosx/whats-new/features.html#safari
In today's security update, Apple is fixing in two security issues I reported that could lead to capturing personal data and launching of arbitrary files or commands to tamper with your computer. These security holes do not break the Mac OS X sandboxing technology. Instead they function despite the sandboxing due to the way sandboxing for Safari was implemented.
I believe these are the first security holes in Apple software that have been made public that achieve file theft and command execution against Safari on Mac OS X v10.7 since sandboxing was added. Of course this excludes the many, many, many holes in Flash and Java and other third party software one may have installed.
The first issue allows a malicious website to run arbitrary commands by getting Safari to launch a URL directly to the system. This issue is tracked as CVE-2011-3230.
Write up: http://vttynotes.blogspot.com/2011/10/cve-2011-3230-launch-any-file-path-from.html
The second issue allows a malicious website to steal files accessible to the sandbox (several of which contain personal data) and execute Javascript in the context of Safari's extensions, which can be used to persistently alter their behavior or to steal data. This issue is tracked as CVE-2011-3229.
Write up: http://vttynotes.blogspot.com/2011/10/cve-2011-3229-steal-files-and-inject-js.html
Mac OS X Issues:
Two other issues in Mac OS X were fixed as well.
The first will not get its own write-up, because it is really straight forward and rather minor. When using QuickTime to "Save for Web", the HTML that is produced includes a script from Apple's website served over HTTP. An MITM attack on the loading of this script when the files are viewed locally could be used to steal files from the local system using XMLHttpRequests or abuse the power of local files in Safari to inject malicious Javascript into any other website. Note that the files are intended to be loaded locally, as they contain instructions on how to place QuickTime content on your website. This issue is tracked as CVE-2011-3218.
The second issue is a MITM attack Brian Mastenbrook and I found that leads to execution of arbitrary code. When viewing help in the Mac App Store, an update check is performed by talking to an Apple server. This update includes AppleScript and Python code that are served over HTTP, and can be replaced by an attacker with the ability to alter the victim's network traffic. When updating, these files are executed. If Mac App Store help has ever been viewed before, this update check can be triggered on demand by an attacker using a "help:" URL in a web page. Additionally, even when a network attacker is not present, the update process insecurely accesses files in "/tmp" leading to a traditional Time of Check vs Time of Use condition that could lead to local attacks such as privilege escalation. These issues do not affect Mac OS X v10.7 Lion, presumably because they were reported to Apple prior to its release. These issues are collectively tracked as CVE-2011-3224.
Write up: http://vttynotes.blogspot.com/2011/10/cve-2011-3224-mitm-to-rce-with-mac-app.html
I hope the detailed information on these security holes is useful. If you have any questions feel free to post them.
No comments:
Post a Comment