Security Thoughts

Tuesday, November 04, 2008, 11:47

Melomania

Some days ago there has been a bit of movement in the security scene since Opera 9.61 was released.
Thanks to Roberto Suggi Liverani that pointed out an issue on Opera historysearch feature and to Kuza55
for asking if the problem, initially considered as "simple" data stealing, could lead to a command execution,
I started thinking about the analogies with chrome Firefox implementation.

After some lazy testing, I figured out that same origin iframe technique could be used in order to exploit the
Xss, leveraging it to Js driven configuration change.
Why?
Because when dealing with opera:* features the browser, in the context of same origin policy, considered
the SOP matching as follows.

Since SOP matching is evaluated by comparing

scheme1 + host1 + port1 == scheme2 + host2 + port2

We got opera:* considered as:

opera + null + null

For every opera:* feature.

So by injecting an iframe from opera:historysearch and pointing to opera:config there was a match in the SOP.

That is the real issue.

Well, not really, that is only one of the hypotesis that have to be satisfied in order to lead to automatic command
execution.
The very first and interesting issue was the CSRF to opera:* location allowed using the window.open Js method
from a http: scheme protocol, and that has to be credited to Roberto Suggi Liverani for finding that.

The rest of the history is quite straightforward.

After the issue found by Roberto I started to play a bit with the historysearch feature parameters.
And it resulted in a very simple attribute-escaping-injection in the next-previous Xss.
So by pointing the browser to:

opera:historysearch?q=">payload&p=1&s=1

there was the chance to exploit once again the opera:* scheme, but just if some result in the historysearch
page was found.

That's why the payload needs to be in the attacker evil page.

The only problem was that '/' could not be used because of Opera's way of encoding/decoding them.

Double urlencoding came into help. The solution was using %%32f in spite of %2f.
(Avif Raff's came up with '<image src=x onerror=Payload' solution)

And that's the full Poc.

So, another new "chrome" alike interface to be abused? Maybe.
What is for sure is that when a browser adds new local functionalities accessible to the user, dressed as
internal_scheme: with html page and internal Js methods, well, security should be taken very seriously by doing:

0. Research in the history of other browsers' flaws;
1. Risk Assessment in the design phase;
2. Threat analysis and Abuse Cases Analysis in the design phase;
3. Secure Code Review of the new features;
4. Black Box Penetration Testing.

And that's where Opera missed its chance.
We all hope they learnt something from their history(search).

Now I can say that I'm a melomaniac again.

Comments:

kuza55, Wednesday, November 05, 2008, 01:25

Nice work Stefano :D

It seems we're only going go get more and more of these types of command execution bugs given all the movement to writing desktop apps in JavaScript, and letting them execute commands. Which means that XSS may become the new buffer overflow after all, even given all the shit I give everyone who's said it before :S

In any case, it seems we're only going to keep finding more and more ways to own browsers :D

Security Thoughts

Wisec is brought to you by...