lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 28 Oct 2009 06:56:05 -0700
From: "Inferno" <inferno@...urethoughts.com>
To: <bugtraq@...urityfocus.com>
Subject: Hijacking Opera's Native Page using malicious RSS payloads

Hijacking Opera's Native Page using malicious RSS payloads
----------------------------------------------------------------------------
---------
For complete post (with images), please visit -
http://securethoughts.com/2009/10/hijacking-operas-native-page-using-malicio
us-rss-payloads/

Well, this one is a continuation of my previous post on Cross Site Scripting
issues relating to RSS feed readers. In that post, I mentioned Scenario (3),
but didn't discuss any details or PoC since Opera Team was actively fixing
it. This issue is now fixed in the latest security update v10.01 from Opera
Team.

In this exploit, an attacker uses a maliciously crafted RSS payload to
achieve full control over the Victim's Opera Browser. The attack works by
convincing a user to visit a RSS feed link. When the user opens the url in
Opera, there are two things that take place. The first one being Javascript
in various RSS feed entries gets executed in the context of the calling
site. This part was discussed in the previous post and can be used to
execute XSS in the context of that site. The second thing that occurs is the
untrusted rss feed content lands up in the Opera's Feed Subscription Page
(also the reason for this post). Since this is a native page, it runs in a
higher privileged zone than the internet zone (something similar to
chrome:// in Firefox and Chrome).

So, if you find a way to execute your malicious javascript in the feed
subscription page, you can essentially execute native opera functions and
ultimately use it to control the Victim's Opera browser. It looks like
Opera's Team did think about the implications of putting untrusted user
content in this page and hence only permitted a certain whitelist of html
tags. In addition, for some html tags such as "A" and "IMG", it required a
certain precondition to be met. See the code snippets captured using Opera
inbuilt debugger DragonFly (you can also use Firebug lite).

Whitelisted HTML Tags Definition - Opera Feed Subscription Page (Source -
DragonFly)
(Image)

HTML Tag Sanitizer/Filter Function - Opera Feed Subscription Page (Source -
DragonFly)
(Image)

If you had tried the simple xss attacks like <img src="x:x" onerror="some
javascript"/> or something like <a onmouseover="some javascript">link</a>,
these won't work here (hint: check out preconditions defined above). It is
important to understand what you are attacking and if read this code, you
will figure out what constitutes a valid malicious payload that will evade
this filter or sanitizer on the Opera Subscriptions Page.

So, here is an example PoC exploit code which executes the
opera.feeds.subscribeNative function to automatically register a feed in
Opera browser without user consent.
http://securethoughts.com/security/rssatomxss/opera10exploit2.atom
(Tested on Opera 10.00 Stable Build 1750)
(Image)

Thanks and Regards,
Inferno
Security Researcher
SecureThoughts.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ