Chrome/Opera ATOM/RSS Reader Script Execution

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