Message-ID: <002301ca3683$c03624f0$40a26ed0$@com>
Date: Tue, 15 Sep 2009 21:11:21 -0700
From: "Inferno" <inferno@...urethoughts.com>
To: <bugtraq@...urityfocus.com>
Subject: Exploiting Chrome and Opera's inbuilt ATOM/RSS reader with Script Execution and more

Exploiting Chrome and Opera’s inbuilt ATOM/RSS reader with Script Execution
and more
----------------------------------------------------------------------------
---------
For complete post (with images), please visit -
http://securethoughts.com/2009/09/exploiting-chrome-and-operas-inbuilt-atomr
ss-reader-with-script-execution-and-more/

=============================================
SECURETHOUGHTS.COM ADVISORY
- CVE-ID	    : CVE-2009-XXXX (Chrome) {Pending}
- Release Date	: September 15, 2009
- Severity	    : Medium to High
- Discovered by	: Inferno
=============================================

I. TITLE
-------------------------
Exploiting Chrome and Opera’s inbuilt ATOM/RSS reader with Script Execution
and more

II. VULNERABLE
-------------------------
Chrome all versions – 2 and 3 (< 3.0.195.21)
Opera all versions - 9 and 10.

III. BACKGROUND
-------------------------
Back in 2006, there was interesting research done by James Holderness[1] and
James M. Snell[2] which uncovered a variety of XSS issues in various online
feed aggregator services (e.g. Feed Demon). The vulnerability arises from
the fact that it is not expected of RSS readers to render scripted content.
I want to extend that research by doing threat analysis on inbuilt feed
readers offered in most modern browsers. I have found Google Chrome (v2,3)
and Opera (v9,v10) to be vulnerable, while Internet Explorer(v7,8), Firefox
3.5 and Safari 4 are resilient to the exploits mentioned below.

IV. DESCRIPTION
-------------------------
Google Chrome and Opera’s inbuilt RSS/ATOM Reader renders untrusted
javascript in an RSS/ATOM feed.

Exploit Scenarios
   1. Scenario 1 –
         1. Attacker social engineers a victim user to visit a rss/atom feed
link pointing to his or her evil site.
         2. Victim uses Google Chrome / Opera browser to view the feed.
         3. Malicious javascript gets executed on victim’s browser. Examples
               1. Modifies into a phishing page and asks user credentials
for subscribing to Google Reader / My.Opera.com
               2. Searches user’s browser history for visited url list [3]
               3. Scans user’s internal network with/without javascript [4] 
   2. Scenario 2 –
         1. Both attacker and victim user have an account to a trusted
website.
         2. Either
               1. The trusted web site lets the attacker inject JavaScript
content into any section of the site’s RSS or an Atom feed.
         3. OR
               1. The trusted website uses blacklist to block known
executable file types for scripted content. E.g. html, jsp, etc.
               2. Attacker uploads a file with extension .rss/.atom/arbitary
extension preceded by .rss/.atom [e.g. .atom.tx]. Most widely used Apache
web server passes Content-Type as “application/{atom/rss}+xml” for all the
three cases automatically in default configuration.
               3. Attacker convinces victim to visit the direct link to
uploaded file.
               4. Victim’s cookies and other sensitive data gets sent to
attacker’s site.
               5. Note: For Internet Explorer (v7,8), the task is easier
because it does automatic mime type detection. So, you can execute
javascript content in any file extension. E.g. click
http://securethoughts.com/security/rssatomxss/anyfile.tx. However, for other
browsers, Firefox 3.5, Safari 4, Opera 10 and Chrome 3, they don’t support
this functionality (perhaps for security reasons). So, using such extensions
mentioned above can be used as a workaround for script execution in Opera
and Chrome browsers.
   3. Scenario 3 –
         1. Similar to Scenario 1, but exploit can be used for complete
control over feeds in the Opera browser.

V. PROOF OF CONCEPT
-------------------------
   1. Exploit Scenario 1 [Testcases - 18 XSS for Chrome, 38 XSS for Opera] –
         1. Chrome:
http://securethoughts.com/security/rssatomxss/googlechromexss.atom [or .rss]
         2. Opera:
http://securethoughts.com/security/rssatomxss/opera10xss.atom [or .rss]
   2. Exploit Scenario 2 –
         1. Include all in Scenario 1
         2. Opera:
http://securethoughts.com/security/rssatomxss/opera10xss.atom.tx [Any
arbitary file extension at. E.g .tx, .tm]
         3. Chrome:
http://securethoughts.com/security/rssatomxss/googlechromexss.atom.tx [Any
arbitary file extension at. E.g .tx, .tm]
   3. Exploit Scenario 3 –
         1. Details and PoC will be released after patch is provided by
Opera Security Team in next minor release. 

For research purposes, you can try out the PoCs on these virtualized (and
vulnerable) versions of various browsers, without installing any bits on
your computer [5].

VI. FIX DESCRIPTION
-------------------------
Chrome: ATOM/RSS feed rendering is completely disabled by forcing a
text/plain MIME type [6]. If you need feed rendering, a good alternative is
FeedBurner which protects from any script execution attacks by blocking them
at time of the feed registration.

Opera: Scenarios (1) and (2) will not be fixed, as it is a design feature.
Scenario (3) will be patched in next minor release.

VII. SOLUTION
-------------------------
Chrome: Upgrade to latest version of Google Chrome (v3.0.195.21 or higher).
If you remain connected to the internet, this should be automatic.
Opera: Wait for upcoming patch for Scenario (3) in next minor release
(non-alpha/beta) of Opera 10 [Opera 9 users need to upgrade]. However, you
will still continue to be vulnerable to script execution.

VIII. REFERENCES
-------------------------
1. Attack Delivery TestSuite – James Holderness
http://intertwingly.net/blog/2006/08/09/Attack-Delivery-TestSuite

2. Feed Security – James M. Snell
http://www.snellspace.com/wp/?p=448

3. CSS History Hack – Jeremiah Grossman
http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html

4. Browser Port Scanning without Javascript – Jeremiah Grossman
http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.h
tml

5. Downloading Xenocode’s “sandboxed” applications – Wladimir Palant
http://adblockplus.org/blog/downloading-xenocode-s-sandboxed-applications

6. Google Chrome Fix Details
http://code.google.com/p/chromium/issues/detail?id=21238

IX. CREDITS
-------------------------
This vulnerability is discovered by
Inferno (inferno {at} securethoughts {dot} com)

X. DISCLOSURE TIMELINE
-------------------------
Sep 7, 2009 12:09 PM: Vulnerability reported to Google and Opera Security
Teams.
Sep 7, 2009 12:10 PM: Automated Response from Google Security Team.
Sep 7, 2009 03:49 PM: First Status update provided by Google Security Team.
Quick response for a Holiday.
Sep 8, 2009 01:09 AM: First Status update provided by Opera Security Team.
Vulnerability concluded as design feature.
Sep 8, 2009 03:28 PM: Vulnerability confirmed by Google Chrome Security
Team. Patch timelines provided.
Sep 9, 2009 07:39 AM: Second Status update provided by Opera Security Team.
Asked for exploit possibility for certain scenarios.
Sep 10, 2009 01:33 AM: Third Status update provided by Opera Security Team.
Vulnerability confirmed for new provided testcases.
Sep 15, 2009 01:31 AM: Final Status update provided by Opera Security Team.
Scenario (3) will be fixed, while Scenarios (1), (2) will not be.
Sep 15, 2009 03:04 PM: Patch released by Google Security Team in
v3.0.195.21.
Sep XX, 2009 XX:XX XX: Patch planned by Opera Security Team for next minor
release.

I would like to thank Chris Evans from Google Chrome Security Team and
Sigbjørn Vik from Opera Security Team for their prompt responses, engaging
in insightful discussions and getting the fix ready in a timely manner. It
was a pleasure working with them.

Powered by blists - more mailing lists