Skip navigation.

exploreopera

| Help

Sign up | Help

Posts tagged with "security"

A malicious thought: how to imagine a security issue

Monday, 22. October 2007, 13:17:31

So Dan Kaminsky claims on Wired that the browser is the bug after investigating Flash security policy issues. Well, we already know that the Flash security policy is too liberal by default, and it's not exactly a bug in the browser from my point of view -

But the Wired article is interesting, though not very detailed. Some scope for imagination.. so let's imagine he has found a way the page will "spoof" its own address to confuse the plugin when it tries to apply samedomain policies.

Just imagine, how might that happen?

One of the unbelievable shortcomings of the old Netscape plugin API is that it doesn't actually tell the plugin the address of the page you're loading. That makes it kind of hard for a plugin like Flash to apply any meaningful samedomain security policy!

What Flash does to work around this is to ask the browser to open this URL:

javascript:window.location+"__flashplugin_unique__"

and read the output. In other words, to spoof the address of the page you're at would require making the browser see another object than the real window.location in this request. (Also, it means Flash can't apply security policies when JavaScript is disabled.. And I wonder if IDNA allows underscores in URLs now and what would happen if Flash ran on, say, www.example.com__flashplugin_unique__.com? Will Flash see their "unique" string and consider it the end of the URL?)

Of course we can not set "location" because trying to set it will take you away from the page and destroy the plugin instance you're trying to confuse.

Is there any other way to hide the location object?

The malicious thought: elements with IDs populate the global object (aka window). What would happen if we added an element with the id "location" to the document? Something like..

<div id="location" href="http://www.example.com/"></div>

just might make the browser see something completely different if you read window.location.href ...

Here is a
test case.
Luckily for your online safety Opera, Firefox, IE7 and Safari on Windows all pass - so move on, nothing to see here. But it's a good test case to keep around - for next time we tweak how elements are exposed in the global scope - and perhaps it inspires more of you to look for those places where feature + feature = security issue..

For security testing, every malicious thought is welcome!

:devil:+:sherlock:=:wizard:

3 Comments

they've made you safer

Friday, 19. October 2007, 14:22:06

One night I checked work E-mail quickly on my mobile, and one of the numerous E-mails from the bug tracker caught my attention. It had a very specific and detailed - though brief - summary and claimed the bug was about a samedomain security policy violation. With mixed feelings of security concerns and curiosity I didn't go to bed but un-packed the laptop to have a look at the bug...

Now 9.24 arrived a couple of days ago. This is a recommended security upgrade which fixes two security issues, reported by Opera users. Both of them hang out on My Opera, so cheers to dbloom and burnout426 for having made us all safer! The results of their work and testing reach beyond those two simple fixes since a single security issue found makes us all investigate how it happened - QA wonders why things weren't tested from that angle - and thus a number of new test cases are written to try to ensure not only that those issues won't re-occur but also that related similar issues won't arise, and will be caught when they do.

So many thanks, guys! Good catch and your work is greatly appreciated. :cool:

7 Comments

enforcing a stricter Flash security policy

Sunday, 16. September 2007, 23:12:54

, ,

Since Opera 9.5 'Kestrel' is in beta, it contains some experimental stuff. "Beta" means "things will be broken", and here's a case where it means "we've broken this on purpose": 9.5 contains a hack to make Flash content default to a more secure security policy.

Flash can communicate with JavaScript in a page. Since you may not trust some random Flash content in your site (think external ads or embedded media players) Macromedia (back when it was still known as Macromedia) came up with the allowScriptAccess attribute. When you embed an external Flash you should specify allowScriptAccess=samedomain as an embed attribute or PARAM to make sure the Flash isn't allowed to talk to JavaScript in the page.

The problem was that when Macromedia invented the allowScriptAccess attribute, there was already quite some Flash content out there, and most likely a lot of it relied on the non-enforcement of cross-domain security policies. They decided to make the Flash player default to always allowing script communication. Defaulting to the least secure option is bad, but they probably felt they had no choice if the alternative meant temporarily breaking thousands and thousands of Flash sites.

With 9.5 previews, if you forgot to add allowScriptAccess=samedomain, Opera will add it for you when invoking Flash. This will break sites, we're well aware of that, and we're already seeing some really high profile casualties. The point of enabling this hack was seeing how many broken sites we could find, to evaluate whether we should remove the hack again or keep it for Kestrel final..

A typical symptom is un-closeable Flash overlay ads, so please look out for those and report anything you come across! It's not unlikely that we will have to revert this feature, but meanwhile we'll keep breaking the web - one Flash site at a time.

13 Comments

Opera and security disclosure

Tuesday, 24. July 2007, 14:15:02

, ,

Note: this post is expressing personal opinion. The official policy is here.

The five wishes for Opera meme is still going strong and Asa chimes in with some criticism. Some good feedback, I do in particular share the request for automatic updates.

However, I noticed that Asa is speculating on whether we have changed our security issue disclosure policy. I guess the advisories without credits that he noticed are this on data: urls and this on HTTP authenticate dialogs. They are not credited because vendors don't usually credit researchers who disclose issues before an agreed date.

So Asa, there is no need for speculation - Opera's policy on security issues is clearly spelled out, and it hasn't changed. Regarding your specific question about disclosing issues found internally, we do believe in responsible disclosure of real security issues and you'll notice the policy says
If issues are discovered, they are fixed, and the fix is released in a new Opera version. Where appropriate, the release changelog will mention the security fix, and an advisory may be issued.


So, there you go. This clearly translates to: no, we do not disclose all issues we find internally, only those we think it is appropriate to disclose. There is no need for guesswork, that's the policy.

And this policy is IMO justified and well considered: Whether or not to disclose issues we discover internally is a complex question.

Asa is rightly proud of Firefox's automatic update feature, but he probably forgets that Opera runs on a large number of platforms and devices where automatic updates is impossible. If Opera runs on a mobile phone where the user pays data charges, regularly fetching some megabytes of software behind the user's back just isn't doable. (Doesn't mean we should not do it for desktop, but it does mean we'll always have a long tail of users with outdated versions.)

This means full disclosure might expose a lot of users on various platforms to risks.

Yes, this is security through obscurity. When a target group is small, I think it makes a lot of sense: penetrating the obscurity isn't going to be worth it for hackers. Do you think some hacker really will travel to Japan, buy a specific handset from a specific network and vendor and start testing it for exploitable security issues to exploit the users that a) have this handset, b) actually browse the web on it and c) happen to go to an infected website?

In the comments, Asa has some other arguments for a disclosure policy:

It would be good for the browser industry as a whole, allowing other vendors to share the work Opera did and address similar issues in their own products


Yes, it would. This is IMO Asa's best argument for full disclosure. Nevertheless, if I find an issue with Opera I usually test it in a few other browsers too, for comparison, and any issues in other browsers we find internally are reported to the respective vendors. As a very recent example I can mention a security issue with version 7 of the Flash plugin for Linux/Solaris that was reported to Opera by Mark Hills, one of our users. While developing test cases internally we noticed that Konqueror had the same problems and contacted them about it, and helped Adobe eventually publish a Flash player upgrade that adressed the problem. I believe we're being good citizens within the given restrictions.

would give users confidence that Opera is actually finding and fixing more than just those bugs they're forced to fix because third parties threaten public disclosure if they don't


Sorry, not at the cost of putting other users at risk. Updates with security fixes should always be labelled as such, but beyond that I'm afraid users will have to take our word for it.

10 Comments

DOMStorage and security

Friday, 29. June 2007, 10:57:46

, , , ...

The DOMStorage feature of the WHATWG WebApps spec is criticised for the security implications. 0x000000 has excellent points (particularly in comments) and I'll think out loud about how UAs like Firefox and Opera will need to address them. I'm not terribly good at spec writing and not implementing this stuff myself so only personal opinion and thoughts to be found here..

Quoting 0x000000:
Starting in Firefox 2 but mainly in Firefox 3, the browser is fully capable of restoring this sessiondata after a crash. This is interesting because we could on purposely crash a window and inject sessiondata to make it an persistent denial of service


Yes, that's a real threat. Opera already addresses a similar issue in the dialog you get on resuming after a crash, where you can choose to start without open windows. An even better implementation might be to detect what window or session caused a crash, and attempt to restore all others - I assume it would require quite some engineering like a separate monitoring process or something. In any case, users will need a "start without restoring sessions" option to avoid persistent session storage enabling persistent crashers.

this storage engine allows me to store what ever I want, whenever I want, and it allows huge data -if I have access to that page- which is useful when there is some XSS hole on that page


Um, if there is an XSS hole on the page you've got the data anyway, is this really more dangerous than just submitting it to a server you control?

It can be used to store worms and activate them across webpages instead of calling remote scripts


Still requires some XSS vulnerability on the page you want to run the worm on. If white-list restriction is implemented it requires both attacker and target to be white-listed.

it can used to store heapspray shellcode to actively stay under the radar of anti virus programs


The bad code needs to travel over the wire at least once to get to the local storage, so that's not entirely true but still an interesting point. I guess it's a matter of timing. If you can get a piece of malware into the local storage of a sufficient number of UAs before security software is updated to detect this threat, you could then activate the attach with some fairly innocent-looking JS that might be much harder to filter out. Should UA vendors collaborate with Antivirus companies on enabling local storage scanning? I'm not sure here, guess malware detection evasion side effects of local storage need more thinking..

it can store a great deal of information later to used on sub domains to read them out again and use them, like defeating single sign on schemes


I'm not sure what he means by "defeating single sign on schemes" here.

it can also be used to profile users and de-annonymize them by storing data vectors in their browser


Yes, it can if you find an XSS hole on a site I give personal information to (or if a web developer by mistake stores given information in a too public part of the local storage).

Now, security concerns are addressed by the specification. Perhaps it's too easy to overlook, but note how the spec explicitly states that
user agents may prevent domains from storing data in and reading data from the top-level domain entries in the globalStorage object

and I guess UAs will in practice require per-domain white-listing of domains that are allowed to use global storage, or make it available only in "application-like" contexts such as widgets. I can't imagine any UAs implementing this part of the spec without additional security restrictions, that would indeed be crazy. On the other hand, per-domain whitelisting will address most of his potential exploits as long as the white-listed sites themselves are safe.

Nevertheless, the spec gives greater powers to web developers. It will enable them to do interesting things more easily, but as we know with greater powers comes greater responsibility - including responsibility for coding responsibly and preventing XSS. The greater capabilities we give JavaScript, the greater the damage a single XSS exploit can cause.

(Opera doesn't support DOMStorage yet but we probably will at some point, apparently Firefox 3 will support it according to 0x000000's post.)

0 Comments

window.opener and security - an unfixable problem?

Wednesday, 14. March 2007, 15:46:53

, , ,

If you know some JavaScript, you'll know that window.opener exists in popups created with window.open() to allow JavaScript in the popup to communicate with its opener window. You might not be aware that this property is also created for popups caused by target=_blank links and forms, but IE and Firefox do this. Popup -> opener communication is generally subject to the normal cross-domain limitations, so that a page from another domain can't for example change the DOM of the opener. However, it *is* allowed to change the address of the opener window by setting window.location, even cross-domain !

This opens up some security worries. Ideally, we would like to prevent cross-domain opener.location setting (for example, an abuse case might be clicking a link in an E-mail that opens in a popup and navigates the main window away from your mailbox to a page you would rather not visit..) but I guess that we would see considerable breakage on the Web if we tried that.

We have tried to let sites sort of "opt-out" from having window.opener defined in the popup window by not setting the window.opener property if the popup was created by clicking a link with target="_blank". That way, your webmail could simply give external links a _blank target attribute and protect the inbox from malicious navigation changes.

Enter KfW Förderbank.. Load page and click "Abschicken" at the bottom. Try the link in the popup. Nothing happens because that functionality depends on "window.opener" being set after submitting a target=_blank form.

Perhaps this problem isn't fixable at all? Or perhaps we should ask the Web API guys to enhance window.open with a new argument that will create a popup without window.opener?

[Edit: trying to "bump" post since there are no comments yet, changing date p: ..]

9 Comments

law, meet web..

Sunday, 28. January 2007, 15:17:08

, ,

The insanity of the teacher guilty in Norwich porn case news is beyond belief. One can make lots of obvious observations about the importance of browser security based on this enormous injustice. But let it also be a lesson to us that the law and the society in general still has a very shallow understanding of computers and the web.. The smallest details of browser UI (like when :visited styling is applied) can be misunderstood and have grave consequences. Is it possible to make a UI that can not be misunderstood even in the court room?

2 Comments

patching Adobe's hole

Saturday, 6. January 2007, 23:58:45

, ,

At this point most readers of this blog will have noticed the latest Adobe Acrobat security issue (see links at the bottom of this post if you haven't). In brief, an Acrobat PDF plugin feature lets an attacker run JavaScript of their choice on any site that hosts PDFs.

To put that into perspective, I am aware of several online banks that have a "mailbox" feature where you can see official letters from the bank to you in a PDF format. A malicious attacker could gain complete control of your online banking interface, for example inject malicious code to perform money transfer, by making you click a link of the form

https://examplebank.com/mailbox/letter1.pdf#arg=javascript:some_javascript_here

Even if you are technical enough to check that protocol and hostname of that link are OK, it is easy to overlook the abnormal and dangerous bit at the end. And it works in any browser using the NSAPI plugin - for example Opera and Firefox. This exploit is very dangerous indeed!

The blame and responsibility for fixing it lies with Adobe. Fortunately, they've resolved the issue in Acrobat Reader 8 - but most users are as we know slow at updating their systems..

So, I'm happy to announce that most cases of this exploit no longer work in Opera.

Yesterday we published a browser.js update for all public versions of Opera greater than 8.01 which disables the exploit for all files that have a .pdf extension. Normally, this update will be downloaded by all Opera installations within a week from now - to get it faster just choose "Help > Check for updates". You may see a message saying no updates are available but the new browser.js will have been downloaded.

I will work a bit more on the patch to see if I can write a version that gives complete protection also for files without .pdf in the address, but you're already much safer with PDF security patch version 1.

It's the first time we've published a generic security issue fix in browser.js. Hopefully it won't happen often but it is interesting to see site patching applied in the security domain.

More information about the security issue and its consequences:

Official advisory:
http://www.adobe.com/support/security/advisories/apsa07-01.html

Other related links:
http://www.gnucitizen.org/blog/danger-danger-danger/
http://www.securityfocus.com/brief/401?ref=rss
http://www.symantec.com/enterprise/security_response/weblog/2007/01/when_pdfs_attack.html
http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/

And, in case you're curious this is the patch itself (in a somewhat more readable format than in browser.js itself):

opera.addEventListener('BeforeJavaScriptURL', function( e ){
var pathname=unescape(self.location.pathname.toLowerCase());
var hash=unescape(self.location.hash.toLowerCase());
if( pathname.indexOf('.pdf')>-1 && hash  &&  hash.indexOf('javascript:')>-1   ) e.preventDefault();
}, false);

12 Comments

1 2 Next »

Showing posts 1 - 8 of 12.