Security @ Opera

Executive Summary

The original report about the Windows-only malformed Content-Length header problem is not a security issue, but a variant of the issue, brought to our attention by Secunia, has a theoretical possibility of allowing arbitrary code to run. We have developed a fix for the problem, which is being tested, and are planning to release an update of Opera soon. Until then, if Opera crashes on an untrusted site, you should avoid visiting that site again.

Details

March 4th, just days after the release of Opera 10.50, we learned about a crasher and possible security issue posted the day before to an online vulnerability database. Many security sites reposted this information, claiming it was a buffer overflow.

This crasher used a very large number in the Content-Length HTTP header to trigger the crash. In fact, the number used was much larger than was necessary to trigger the crash. It was over 5000 digits long, but 20 digits would have been enough. This excessive length would prove to be a bit of a distraction when we analyzed the issue.

We quickly determined what was causing the problem: The incorrect use of a signed integer length data type, not properly checking conversion errors, and not limiting the result to only positive values. We could then develop a fix for the problem. We also determined that this example was not exploitable, since it would always trigger an attempt to copy Opera's entire memory (up to 4 GB on 32-bit, much more on 64-bit) from one location to another, an operation that will always crash in a non-exploitable fashion once the copy operation runs into an area of the memory address-space that has not been allocated.

This was the first information available to us, and we passed our preliminary evaluation to several of the security sites, asking if they had any more information. We also made this evaluation available to press inquiries and users, without making a official post about it.

But the size of the test-case had blinded us to one possibility, brought to our attention by Secunia the next day, which existed due to the aforementioned signed integer use: A value in the range is 2⁶³ to 2⁶⁴-1 was returned as a valid number, despite being outside the signed data-range of the compiler provided conversion function (so it should have triggered an error instead), and as a result a negative value was returned in the range -2⁶³ to -1.

This is a much worse scenario than what we were looking at initially. In a 64 bit environment this would still crash, but in a 32 bit environment it would allow the configuration of any copy length the malicious server operator desired, and it could potentially be used to move memory from one location to another without crashing, provided the specified length was not too long. However, the fix we had already developed would also fix this problem.

This is not a buffer overflow, at least in the normal sense of the term, but it would cause memory corruption, and the question was whether or not the resulting corruption could be used to run code provided by the attacker, or if it would just cause a random crash somewhere else?

While investigating the issue with Secunia they provided us with an example that would cause a random crash, showing that it was at least possible to provoke a possible code execution later, which means that the corrupted memory could be in a partly usable state after the corruption occurred. However, there are so many dependencies in data used in an application like Opera that getting valid data into every location that needs it is rather unlikely, and a random crash soon after the corruption is the most likely scenario, unless the final phase of the attack can be carried through very quickly, something which depends on a large number of variables.

Our updated conclusion is that the original test-case is not a security issue, but for Secunia's modified test-case there is a theoretical possibility that an attacker could set up conditions so that arbitrary code can be run, and it is therefore a security issue. However, we think it is unlikely that this can be done is a predictable fashion. We also determined that the problem only existed in our Windows version.

In the event that an attack should successfully get past the hurdles mentioned above, Opera for Windows have for some time supported the security mechanisms DEP (which prevents code execution in the applications data areas) and ASLR (which makes the location of the data less predictable), DEP is available from Windows XP SP2 and later versions of Windows, ASLR from Windows Vista and up, though there may be system specific restrictions. If these two Windows security features are enabled, the probability of carrying through a successful attack becomes much smaller than it already was.

Of course, since this is considered a security issue, even if it is currently theoretical, we have a fix ready and are testing it. The plan is to release an update of Opera soon. Until then, if Opera crashes on an untrusted site, you should avoid visiting that site again.