If you ask any Opera fanboy, he will tell you that Opera is the most secured browser. Well frankly, it really is a good and secure browser, implementing many restrictions that other browsers simply ignore.

For example, while other browsers allow scripts running from local resources to access local files Opera doesn’t. And by that, it is almost impossible to steal local files, or execute code by exploiting vulnerabilities local resources.

You probably noticed that I used the word almost. It is almost impossible, due to the fact that one, and only one local resource, does allow you to access local files and other browser settings. The local resource is opera:config.

One of the many settings this local resource can be used to change is the mail external application. The mail external application will be opened whenever you click on a “mailto:” link, or whenever your browser redirects to a “mailto:” URL. If an attacker can change this setting it means that he can automatically execute arbitrary code on the user’s machine from remote.

This is of course irrelevant, unless you can actually change the settings automatically from remote, and unfortunately for Opera users, there was a way.

Today, Opera released a new version, 9.62, with a fix for a vulnerability in a different local resource - the “History Search” page (opera:historysearch). The problem was that Opera did not sanitize specific parameters correctly, and an arbitrary script could be injected to this page. An attacker could then execute a script that will create an iframe which will open the opera:config local resource. And then, it will call a script within the opera:config page, which will change the settings and execute arbitrary code on the user’s machine as explained previously.

The vulnerability in the “History Search” page was found by Stefano Di Paola, during our discussion on the full-disclosure mailing about an older vulnerability in the “History Page” that was found by Roberto Suggi and was fixed by Opera in version 9.61. I’ve created proof-of-concept codes which demonstrate the vulnerabilities. Both can be found on milw0rm.com.

While both vulnerabilities in the “History Page” are now fixed, the core problem which makes it possible to execute code from remote, still isn’t.

There is still no Same Origin Policy restriction between local resources in Opera. It is still possible for a script to access one local resource (e.g. opera:cache) from another (e.g. opera:config). In my submission to Opera I’ve asked them to fix this issue as well, and I really hope they will do so before other vulnerabilities will be found in more local resources.

Nevertheless, my recommendation for Opera users is still to upgrade to the latest version.

You all learned about the value of sharing. When I was a kid my mother taught me that I should share my stuff with my friends. Unfortunately, sharing is not always a good thing. Especially, when talking about sharing web-applications across domains.

Over six months ago I've discovered an interesting, yet troubling, issue - Google.com suffers from a cross-domain web-application sharing security design flaw. There are several Google web applications which are accessible over multiple google.com subdomains. The following are some of those web-applications and subdomains:

• Google Maps (maps.google.com)
• Google Mail (mail.google.com)
• Google Images (images.google.com)
• Google News (news.google.com)
• Google.com (Google Search, Google Accounts, Google Apps, Google History, etc.)

Here's example of Google News being hosted on the Google Maps subdomain: http://maps.google.com/news?sa=N&tab=ln

So, what's the problem with that, you ask? Well, there are several ways this cross-domain web-application sharing security design flaw can be exploited. For instance, one small XSS issue in Google Maps can now be exploited to hijack Google, GMail or Google Apps accounts, by bypassing the browser's Same Origin Policy. There were several XSS issues reported in the past, on some of the google.com subdomains, which are now fixed.

Furthermore, as shown by Adrian Pastor of the GNUCitizen team, it is also possible to abuse features of one of Google's web-application and then impersonate to an other. Adrian's proof-of-concept exploits a frame injection vulnerability in Google Images to inject a fake GMail login page. It then uses the cross-domain web-application sharing flaw to further convince the victim that this is a legitimate login page, from the legitimate mail.google.com subdomain.

I've notified Google about this issue several days after I discovered it, back in April. Their initial response was that they were looking into it. Today, after not getting any further response from the Google security team about this issue, and after Adrian published his proof-of-concept, I've decided to reveal this information in a hope that this security design flaw will be fixed by Google as soon as possible.

We've just passed the Jewish new year's holiday. Happy new year! It's a custom in this holiday to eat an apple and honey for a sweet new year.

Sadly, this year starts with a little bit sour Apple. If you follow my blog, you probably remember that I wrote about 2 vulnerabilities I've found in Apple's iPhone.

I have disclosed the technical details to Apple few weeks before that post, in a hope to get those security issues fixed as soon as possible. Unfortunately, two and a half months later, and still there is no patch for those vulnerabilities. I've asked Apple several times for a schedule, but they have refused to provide the fix date. Three versions (v2.0.1, v2.02, v2.1) have been released since I provided them with the details, and they are still "working on it". Therefore, I've decided to publicly disclose the technical details.

Both issues are pretty trivial, and can be easily fixed by Apple.

Phishing vulnerability

The iPhone's Mail application can be used to view both HTML and plain text mail messages. When the mail message is in HTML format, the text of links can be set to a different URL than the actual link. In most mail clients (e.g. on your PC / Mac), you can just hover the link and get a tooltip which will tell you the actual URL that you are about to click.

In iPhone it's a bit different. You need to click the link for a few seconds in order to get the tooltip. Now, because the iPhone screen is small, long URLs are automatically cut off in the middle. So, instead of "hxxp://www.somedomain.com/verylongpath/verylongfilename", you will get in the tooltip  something like "www.somedomain.com/very...ilename".

The problem here is that an attacker can set a long subdomain (~24 characters) that, when cut off in the middle, will look as if it's a trusted domain. The following iPhone screenshot shows an example:

In this example, the text of the link is "https://securelogin.facebook.com/reset.php?cc=534a556abd1006&tt=1212620963", and the actual URL is http://securelogin.facebook.com.avivraff.com/reset.php?cc=534a556abd1006&tt=1212620963. However, when the victim will try to check what is the actual links is, he will see: "securelogin.facebook.com...556abd1006&tt=1212620963". This will convince the victim that the link is from facebook.com, where it is actually from avivraff.com.

When the victim will click this link, Safari for iPhone will be opened:

As you can see, the address bar shows: "securelogin.facebook.co...", this will further convince the victim that he is on the right trusted domain. Furthermore, when clicking the address bar, the cursor will jump to the end of the URL. So, in order to view the right domain the user will have to scroll back, which requires a lot of clicks and patience.

Spamming vulnerability

This one is not just a trivial bug, it's actually a pretty dumb design flaw, which was already fixed by all other mail clients ages ago. Whenever you view an HTML mail message which contains images, a request is made to a remote server in order to get the image. Most of the mail clients today requires you to approve the download of the images. This is done for a good reason.

If the images were downloaded automatically, the spammer who controls the remote server will know that you have read the message, and will mark your mail account as active, in order to send you more spam. This "feature" is also known as "Web Bug"

The iPhone's Mail application downloads all images automatically, and there is NO WAY to disable this feature!

Workarounds/Suggestions

As I wrote, there is no workaround for the spamming issue. So, my only suggestion is to avoid using the Mail application until a fix is available.

If you still insist on using it, you should be careful with the links you click, as they might not be from the trusted domain you think they are...