Exploiting Chrome and Opera’s inbuilt ATOM/RSS reader with Script Execution and more

Update: I missed pointing out the cutting edge research done by Robert Auger in this area back in 2006. [1,2]. Also, Michal Zalewski has written about the RSS and ATOM vulnerabilities in the comprehensive Browser Security Handbook. Definitely check these links out.

ADVISORY

VULNERABLE

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

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.

DESCRIPTION

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

Exploit Scenarios

Scenario 1 –

Attacker social engineers a victim user to visit a rss/atom feed link pointing to his or her evil site.

Victim uses Google Chrome / Opera browser to view the feed.

Malicious javascript gets executed on victim’s browser. Examples

Modifies into a phishing page and asks user credentials for subscribing to Google Reader / My.Opera.com

Searches user’s browser history for visited url list [3]

Scans user’s internal network with/without javascript [4]

Scenario 2 –

Both attacker and victim user have an account to a trusted website.

Either
The trusted web site lets the attacker inject JavaScript content into any section of the site’s RSS or an Atom feed.

OR
The trusted website uses blacklist to block known executable file types for scripted content. E.g. html, jsp, etc.

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.

Attacker convinces victim to visit the direct link to uploaded file.

Victim’s cookies and other sensitive data gets sent to attacker’s site.

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

Scenario 3 –

Similar to Scenario 1, but exploit can be used for complete control over feeds in the Opera browser.

PROOF OF CONCEPT

Exploit Scenario 1 [Testcases – 18 XSS for Chrome, 38 XSS for Opera] –

• Chrome: https://securethoughts.com/security/rssatomxss/googlechromexss.atom [or .rss]
• Opera: https://securethoughts.com/security/rssatomxss/opera10xss.atom [or .rss]

Exploit Scenario 2 –

Include all in Scenario 1

• Opera: https://securethoughts.com/security/rssatomxss/opera10xss.atom.tx [Any arbitary file extension at. E.g .tx, .tm]
• Chrome: https://securethoughts.com/security/rssatomxss/googlechromexss.atom.tx [Any arbitary file extension at. E.g .tx, .tm]

Exploit Scenario 3 –

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

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.

Google Chrome before fix –

Google Chrome after fix –

Opera before fix –

Opera After Fix –
Still the same. Only Scenario (3) will be fixed.

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.

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

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

CREDITS

This vulnerability is discovered by
Inferno (inferno {at} securethoughts {dot} com)

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 Teamfor their prompt responses, engaging in insightful discussions and getting the fix ready in a timely manner. It was a pleasure working with them.