Friday, February 13th, 2009
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:
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://
Which resulted in the following being rendered by Safari:
<!– 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.
Proof of concept can be found here.
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.