Security @ Opera

Subscribe to RSS feed

Sticky post

Introducing the Security @ Opera home page

, ,

Welcome to the new home page of the Opera Security Group.

This is where we are going to announce security updates, links to advisories, and occasional articles with information about security topics related to Opera.

You can find out more about Opera's policies for security vulnerabilities at this page. We prefer that security vulnerabilities, like all bugs, are reported via our bug-tracking system, although we do also accept reports via the e-mail address security (at) opera dot com (PGP key can be found in this article).

Thanks to the researchers

A number of researchers have recently been helping us to secure our websites. We would like to take this opportunity to thank them for their assistance in discovering security issues:
  • Noman Ramzan
  • Danish Tariq
  • Mirza Akif Israr
  • Ali Hasan Ghauri
  • Rafay Baloch
  • Kamil Sevi
  • Hazim Aslam
  • Milad Bahari Rad
  • Shahee Mirza
  • Harsha Vardhan Boppana
  • Rajatkumar Karmarkar
  • Ajay Singh Negi
  • Monendra Sahu
  • Abhinav Karnawat \/ w4rri0r \/
  • Danijel Maksimović
  • Peter Jaric
  • Mahadev Subedi (@blinkms)
  • SimranJeet Singh (@TurbanatorSJS)
  • Christy Philip Mathew
  • Josip Franjković
  • Peter Jaric (@peterjaric)

If you have discovered a security issue in one of Opera's web sites, please report it securely using our bug tracking system (please do not report such issues using blog comments).

On the Precariousness of RC4

,

RC4 is one of the most popular encryption methods used on the Web today. We are told that up to 50% of all connections use this, partly because some recent attacks on other encryption methods have left RC4 unscathed, and many web masters have chosen to move to RC4. However, new research has devised another attack, usable against RC4. While this attack is still not viable in practice against a regular web surfer, RC4 no longer offers any extra security margin, and should another or improved attack be found, RC4 would fall.

RC4 should work somewhat like a random number generator, producing random output. However, statistical flaws have been found in the output of the algorithm, so with detailed knowledge of the flaws and sufficient attempts to encrypt the same data, some of the original data can be recovered. The recent attack has analyzed the output of RC4, and found that with a few tens of millions attempts, data can be recovered. Given sufficient time, a tab left open in the background can make this amount of requests to a logged-in website, such as a bank, thus possibly revealing the cookie. However, even with a fast intranet connection, and consuming all available bandwidth 24 hours a day, this would take several days to acomplish, making this attack infeasible against regular web surfers.

However, we want our users to feel secure browsing the web, even if they don't know what encryption methods the servers they visit use. RC4 no longer offer this assurance on its own, so in Opera 12.15 we are adding some extra safeguards whenever using RC4, so Opera users can still feel absolutely secure. Even if a new and secret improvement to the attack should be found by a surveillance agency, Opera users should still have nothing to fear.

The first of our safeguards is to add some random data into the connection, so statistical methods will be less effective. We add this both at the beginning of a new connection, and at random intervals later. Second, if we detect something which looks like an attack, we disallow further communication with that set of domains. In practice, if the number of requests during a 24-hour interval is unrealistically high, we block further requests for the remainder of that interval. The set of domains is the same as the set of domains a cookie can be sent to, and includes subdomains.

Combined, these safeguards should reassure any concerned users, while RC4 gets slowly phased out on the web. The precautions are so general in nature that they should hopefully protect also against future flaws found in RC4.

TLS Prober source code released under Apache 2.0 license

, , , ...

Three years ago, while a group, including myself, involved with work on the TLS Protocol, was discussing possible ways to solve the TLS Renego vulnerability that had been revealed a few months earlier, questions arose about the feasibility of some of the proposed measures. At that time, however, while we knew servers existed that would break if we did what was proposed, nobody had any real data about the *number* of deployed servers that would fail if such actions were taken.

I decided to take a look, to see if I could get some information about these issues.

In order to do so, I would need some kind of tool that would test TLS servers and report the results, and one fundamental part would be a TLS Protocol implementation. As I could not use Opera's own implementation, and I knew from experience just how long building one from scratch would take, I looked around for a Python-based TLS implementation that I could update as necessary for my purposes. I eventually settled on "TLSLite", a library that is available in the Public Domain, now also available on GitHub.

In the weeks and months that followed, the "TLS Prober" took shape as a system consisting of a database server and a number of machines that run tests on thousands of TLS servers and is today testing 550-600,000 TLS servers each week.

As a result, we have posted a number of articles here on the Security Group, as well as on my home page, with summaries of the data gathered by the TLS Prober.

Today, we are releasing the source code for the TLS Prober, and its associated "TLS Web Prober", a web service tool to do quick testing of TLS servers, under the Apache 2.0 License. The updated and instrumented TLSLite library is also being released, still under its original Public Domain license (but it has not been upgraded to the newer version mentioned above).

The database containing the results will not be released, as we are concerned that it could contain sensitive data about sites.

You can find the four git-repositories (repos) in Opera's GitHub area: TLSprober, TLSwebprober, TLScommon, TLSLite.


Additionally, we are releasing the "Git-splitter", a small Git-related tool that can be used to extract the files and commit history of a sub-directory in a Git repo, as well as reversing the process.

This tool became necessary for one of our internal projects, as some source code was shared across multiple projects, and normal migration back and forth was complicated. In order to improve the process, the system needed to be changed to use Git sub-modules instead. To do so, however, the relevant files and their commit history needed to be extracted from the original projects' source code.

Originally, we used a tool called git-subtree for this, but we encountered performance issues due to how git-subtree used temporary files. Therefore, I decided to write a similar tool in Python that eliminated those performance issues, as well as being able to reverse the process, since we also wanted to migrate any updates in the new sub-modules back to the original projects.

The result was the "Git-splitter", which is now available under the Apache 2.0 license in Opera's GitHub area.

Enjoy! smile

Opera's Cross Network Protection

, ,

For some time, Opera has had a Cross Network Protection in place. For the most part, users never encounter this, but we have received some questions about it from users or developers in special environments. This post will try to explain the background for it, how it works, and how to selectively disable it when needed.

Read more...

Suspected malware performs man-in-the-middle attack on secure connections

, ,

In the past few weeks, we have seen an increasing number of reports from users saying that they are receiving certificate warnings, similar to the unrelated example below, on any secure site they visit, including Google, Facebook and Twitter.



This is not a browser or SSL issue as such, since the correct certificate warning is given. It looks more like a combination of installing malware or a trojan and social engineering.

Investigating, we found that one of the frequently reported certificates was a self-signed certificate purporting to be from "Thawte", one of the major CA trademarks owned by Symantec, but which was never issued by them.

There are a few legitimate cases where an unknown issuing certificate can be observed, mostly for internet-security software installed locally on the machine, but such certificates always identify the responsible product. That was not the case this time.

The use of the name "Thawte" in the certificate clearly indicates that whoever was responsible did not want to be identified and wanted to rely on a well-known trademark to trick the user into accepting the certificate, which is a clear indication of malicious intentions.

Many factors, such as the number of affected sites, the geographic diversity, and the fact that other computers on the same network did not see the same issue, quickly indicated that the problem was local on the user's machine, probably due to some undetected malware.

Thanks to the detective work of one forum poster, Sam Van den Vonder, and his friend who encountered this problem, a possible sample of the malware was obtained, and forwarded to Symantec and Microsoft for analysis.

Symantec has tentatively determined that the malware is a Trojan.Tatanarg variant, which they have named Trojan.Tatanarg.B. [Update June 3rd, 2012: Symantec have posted another article about this malware]

This trojan family has been used to steal banking information by performing man-in-the-middle (MITM) attacks on the user's secure connections, by presenting a fake certificate, which the user has to accept in order to be attacked through this method.

The MITM attack is staged by hooking into the computer's network drivers, in order to intercept all HTTPS connections to websites, pretending that it is the server, and then establishing a separate connection to the server to which the user was connecting, pretending to be the client. The malware has to present a fake certificate to the client, which the client then shows to the user, because it is not issued by any of the trusted Certificate Authorities in the repository. If the user accepts the certificate, then the malware can, depending on its capabilities, not just listen in on everything the user does on the site, such as which passwords are used, but also can inject actions into the session, such as transferring money out of a bank account.

The probable infection vector is thought to be vulnerabilities in Java and happens when the user visits a site that has been compromised and is used to send malware to its visitors. Many high profile sites, including Amnesty International, have been abused in this manner.

This trojan is probably not the only such malware one out there, we have seen reports of at least one different certificate being used, and there are probably many more in circulation.

If your computer gets infected with such malware, and your antivirus software does not detect it, or is not able to remove it, the best option may to reinstall the OS after backing up all your data.

Once you are on a secure system, you need to change the passwords for all affected accounts and audit the activity there, particularly for online banking. You also need to make sure that you have not permanently accepted any of the fake certificates in the Certificate Manager (Menu>Settings>Preferences>Advanced>Security>Manage Certificates>Approved).


Suggested mitigation steps:

  • Disable plug-ins generally, and only enable them for sites where you want to have plug-ins used. Optionally, you can instead use the "Enable plug-in on demand" feature. This reduces the potential for being attacked through plug-ins, since the attacker would have to attack one of the sites for which you have enabled plug-ins. An extra benefit is that you will not see flash ads or unrequested videos on most sites.
  • Keep in mind that serious websites do not trigger security warnings. If you encounter security warnings on your online banking site, Google, Facebook, Twitter, Amazon, or other public websites, it is not the browser that is at fault, it is telling you that there is a serious problem somewhere. In such situations, you should never click through the warning, but instead leave the site, and start checking your system for malware. In case you decide to click through the certificate warning dialog anyway, Opera will still not show the site as secure.


[Update June 3rd, 2012: Added link to Symantec article]

Opera's CABForum reorganization position paper

, , ,

A few weeks ago we told of the recent CABForum initiative to consider reorganizing the forum, and its request for public input into this process.

Today, Opera submitted its position paper to the CABForum, discussing some of the important aspects the initiative will need to consider:

Dear CABForum,

Below you will find some thoughts we at Opera Software have had about the changes being considered for the CABForum organization, as they might affect the membership and work process of the forum.

Expansion of membership

At present, the CABForum's membership, which includes, and will continue
to include Opera, consists of certificate authorities, browsers and other
clients that use certificates, plus a few observers, such as WebTrust and
PayPal.

A possible outcome of the reorganization under consideration is that the
forum opening the forum to new categories of members. Which groups should
be eligible for membership, what should the criteria for joining be, and
how will such an extension affect the CABforum's work?

Possible membership categories

New members should, as now, be approved by the existing forum members
before they are allowed to join. This is to ensure that perspectives
offered by the new members are relevant to the work done by the forum.

  • Websites, other certificates subscribers

    It is our opinion that website operators, OS and software vendors, and
    others who rely on certificates in their work (i.e., subscribers) and who
    have an interest in the topic, should be able to join.
  • Users

    This is the largest group of potential members, as it includes every
    internet user in the world. The browser vendors have seen it as their
    responsibility to guard the interests of users, but, as in any area, there
    are those who will disagree with the positions taken. It might, therefore,
    be beneficial to have more user-related viewpoints represented.

    As the "users" category is so large, it is not very practical to open the
    CABForum to individual users. Instead, organizations that represent groups
    of users and that have an interest in what the CABForum works on should be
    allowed to join the forum.
  • Independent experts

    While many of the members will have experts working in many areas within
    the CABForum's purview and will draw on those experts' expertise while
    working in the forum, other independent experts may provide different and
    relevant viewpoints.

    Security is not the only area where such experts may prove useful; other
    areas are UI, lawyers, etc., and experts in these areas with an additional
    interest in the topics covered by the forum should be allowed to join.

Both experts and user representatives might either apply to join or be
invited. In either case, new memberships must be approved by the existing
group, as detailed above.

Relationships with other standards organizations

Several other standards organizations work in areas that are either
overlapping or related to the areas that the CABForum covers.

Opera thinks the CABForum should establish relationships with relevant
standards organizations, so each can be kept up to date on what is going
on in the other organization.


Impact on work process

Increasing the membership of the forum will very likely cause trouble with
at least two areas of the current work process in the CABForum: balloting
the proposed specification and how public the groups discussions should be.

At present, there are different ballot majority rules for the CAs and the
browsers, and they are considered separately due to the huge difference in
numbers between the CA populace and the browser populace, in order to
prevent one group from steamrollering the other.

If more categories of members join the CABForum, then not only will such a
ballot system quickly become difficult to maintain, but also it may make
it very difficult to perform the balloting, at least in a meaningful
fashion.

We think it will, therefore, be necessary to change the final approval
phase of the CABForum work flow towards one based on achieving consensus
about a new specification in a working group, before issuing a Last Call
to the members. Once the Last Call has been completed, and the issues
resolved (which might be that nothing should be done about it or that it
is an issue to handle in the next version), then the specification is
considered ready be published.

The second aspect of the work process that need to be considered is
whether discussions should be public or private.

Opera thinks most discussion should be public, but there should still be
non-public discussion venues that can only be seen by members of the
CABForum. This system would be similar to the arrangement used by W3C.

IPR

With respect to Intellectual Property Rights (IPR), particularly patents,
Opera's position is that standards should be unencumbered by IPR claims,
and in the event that such claims are made, implementors of the standard
should be granted a free license to use the IPR, a so-called RAND-Z
license.

Sincerely,
Opera Software ASA
www.opera.com


Other announcements

In related news, we would like to thank Burak Beyzadeoğlu for his assistance in discovering and fixing several security issues with Opera's web sites.


CA/Browser Forum considers reorganizing

, , ,

The CA/Browser Forum (CABForum) has, since it was formed in 2005, worked to improve security and trust on the internet -- first by defining the Extended Validation (EV) guidelines and, most recently, by defining the "Baseline Requirements for CAs".

Since its start, the list of participants in the Forum have included the major certificate authorities and browser vendors as voting members, as well as auditors and some other observers from interested parties.

Last week, at the 25th meeting of the forum, it was decided to form a working group to evaluate whether it is time to reorganize the forum, as well as whether membership should be expanded to include representatives of certificate subscribers (websites) and users (relying parties).

As part of this process, the CABForum invites interested parties to submit short position papers with suggestions about the topics to be considered. Please note that the submissions will be posted to the CABForum website.

Opera will participate in the working group and also intends to submit a position paper.

Please see the CABForum's announcement for more information.

About Opera 11.60 and new problems with some secure servers

, , , ...

After we released Opera 11.60 earlier this week, a few people reported problems with some secure sites, sites that had worked in Opera 11.52.

The affected servers must be upgraded to versions that are not affected by the observed problem.

These reports are not unexpected, as the problems are caused by one of the security patches introduced by Opera 11.60 for the so-called BEAST issue, reported by researchers Duong and Rizzo, an issue we posted about in September.

Also, the problems observed with these sites are not isolated to Opera, as other browser vendors have either already released versions with the same kind of protocol update or will soon do so. In addition to the browser updates, Oracle released a patched version of Java in October.

The issue that this patch mitigates is that when a server supporting SSL v3 or TLS 1.0 (TLS 1.1 and later are not affected) selects certain encryption methods, specifically Triple-DES or AES in Opera (ARC4/RC4 is not affected), an attacker that is able to both observe the encrypted datastream, and control specific parts of the plain text that is sent in that datastream, was able to discover data sent over that connection that the attacker could not control, such as the cookies used for that site. The attack has been known for a long time, but what Duong and Rizzo discovered was a way to increase the speed of the attack dramatically.

The attack only works when attackers can see the encrypted data sent immediately before the next block of data that they send and that gets encrypted, which offers a way to mitigate the problem.

What Opera and the other browser vendors have decided is that each block of application data (such as a secure HTTP request) will be split into two blocks of data that are encrypted separately. The first encrypted block only contains the first byte of the application data; the second block contains the rest of the data. The method is being called a "1/n-1" record split. This payload splitting prevent the attackers from being able to construct a block of application data that can help them guess the content of the data they did not control (e.g., the cookies).

However, a few secure servers are not standards compliant and do not tolerate that a HTTP request such as "GET / HTTP/1.0" is broken up into two blocks of separately encrypted SSL/TLS records, such as "G" and "ET / HTTP/1.0", and responds in a number of ways -- for example, by just closing the connection, never responding, or responding with a HTTP error messages.

Before releasing this patch we did some research with the TLS Prober to discover the extent of the problem.

The numbers indicate that up to 0.25% of servers may be affected by this issue, although not every one of these servers is affected, as it depends on the specific encryption method selected by the server; however, it is possible that at least 0.16% could be affected, as they either support AES or only support Triple-DES.

As far as we can tell from the recorded information about the affected servers, most of the affected sites seem to be using unidentifiable SSL/TLS front-ends, as there is no specific server software that stands out among the servers.

There is still some uncertainty about the precise numbers, since the automatic detection of problematic servers in the TLS Prober might still incorrectly flag a server as behaving incorrectly, although among the reported servers tested so far, they have all been detected as being non-compliant.

As mentioned above, all browser vendors have either shipped, or will soon be shipping, updates of their browsers that will implement this new countermeasure, so the operators of the affected servers should as soon as possible do one of the following:

  • Upgrade the server to a newer version that is not affected by the problem. This is a good idea in any case, since the affected servers are probably old and thus have other security problems, too.
  • Configure the server to prefer the RC4 encryption method (which does not have the problem), but this will still cause the problem to appear if the client does not support RC4.

About the SVG font manipulation vulnerability that was fixed in 11.52

, ,

Recently, news of a SVG-related vulnerability has been circulating on the net, along with claims that Opera had "decided not to fix it".

At Opera, we take security very seriously, and you can be sure that we would not choose to ignore exploitable security vulnerabilities.

With our release today of Opera 11.52, we now have a fix available for this issue, but we want to shed more light onto what happened, as well as explain why we both ask for - and practice - responsible disclosure.

Read more...