My OperaWhat is a browser security issue, anyway?
By Yngve Nysæter Pettersenyngve. Thursday, February 18, 2010 3:24:35 PM
[Note: This is a updated version of the Opera Labs article from 2006]
A large number of people are looking for security problems and vulnerabilities in Opera and other applications. Some people do not like this, but we think it is fine. When done responsibly, this can increase security for the application and is thus of great benefit to users. However, when done irresponsibly, the activity can cause needless alarm, wasting the time of application vendors and end users.
An example of irresponsibility is how they report and classify the issues they find, and how the issues are communicated to the application vendor.
The primary problems we see with some of the reporting is that:
The terms "security issue" and "vulnerability" cover a large number of serious problems within an application.
Security real issues list:
Those are just some of the possibilities. As important is what should NOT be called a security issue.
Security non-issues list:
Sometimes, reporters incorrectly classify instances from the non-issues list as issues from the real issues list.
The two main severity concerns prone to be exaggerated are allegations that a problem "can be used to execute arbitrary code" or is a "Denial of Service" (DOS) attack.
It seems that the combination of a very large input and a crash leads some people to automatically think the problem may be used to "execute arbitrary code", that is, take over the user's computer. That is not always the case, and is usually only possible for what is called a stack buffer overflow, even though it is also sometimes possible for heap (allocated) buffer overflows. However, we have seen this phrase used even for ordinary "NULL pointer" crashes that had no possibility whatsoever to be
abused.
Another exaggeration is calling any crash that can be triggered by a Web site a "Denial of Service" attack. In our opinion, crashing a server which could potentially be running an important or critical service can rightly be called a Denial of Service, as long as the server is not able to automatically recover. This is because bringing down the server will deny service to all users.
Crashing a client, while it is an undesirable event and one we want to fix quickly, can only be achieved by enticing the user into accessing a document that crashes the client. Even then it will usually only inconvenience the user long enough to restart the application. That is not sufficient cause to call it a Denial of Service; in most of these cases it is a stability issue.
The only way, in our opinion, that a crash in a client can be called a Denial of Service is if the attack causes the client to crash again when it is restarted, and when fixing the problem requires more than changing the immediate startup configuration (previous session or blank page). Consequently, this requires editing of the configuration files or a complete re-installation.
In our opinion, calling a normal crash problem in a client a "Denial of Service" vulnerability is a devaluation of the meaning of the term "Denial of Service", which eventually may rob it completely of its correct meaning. Much in the same way, the word "hacker" is now considered to mean "computer criminal", not "highly skilled computer specialist", which was its original meaning. Please see http://en.wikipedia.org/wiki/Hacker_(computing). One may ask if an attack that disables the client really is a
security problem. After all, it does not compromise the user's information security, privacy, or the system's integrity. Generally, we do not consider ordinary crashes, freezes, and other so-called "Denial of Service" attacks security problems; they are stability issues.
Other browser developers have also seen this kind of exaggeration, and Gerv of Mozilla apparently shares our opinion about calling crashes Denial of Service. While we think Microsoft is stretching the definition of Denial of Service, their situation is a bit more complex, which may justify using the definition in their case.
We would like to use this opportunity to ask the security research community to revisit and update/clarify the meaning of their classifications for the various contexts where they are used. In particular, those who maintain vulnerability databases should consider the actual severity of a reported problem before posting the information.
"I think I have found a security issue in Opera. What should I do?"
We recommend: Report it to us before you publish it, so we can fix the problem and release an updated version as soon as possible. We take security seriously, and will investigate all reports.
You should file the report at https://bugs.opera.com/wizard/, with the severity "Security Issue" and you should fill in all information you have, or suspect, about the problem:
* Give a clear and concise explanation of the problem, as complete as possible, including why it is a security issue if that is not obvious.
* Identify which version(s) of Opera you have tested, including which operating system versions. At least one of the tested versions should be the most recent release for the affected platforms.
* Document what is needed to replicate the problem with a step-by-step procedure which includes the source code or command line operations.
* Provide an e-mail address where we can contact you in case we need more information, and to keep you updated about our progress.
* Provide actual test cases. The test cases should contain only the minimum complexity required to reproduce the problem.
* Provide references to previous discussions about the problem area, and if it has occurred in other software.
You should always file a bug report about the issue, even if you are going to send information to the Security Group via e-mail (see below). The report will be filed in our system, and it will remain in the system even if your e-mail should go astray.
Unless they are very short, the test cases should be attached to the bug report by using the e-mail address you get after you submit the bug report.
Server-side test cases should, if there are no special reasons to use other formats, be written in Perl, PHP, or Python. Aside from using standard libraries, they must be self contained.
To protect the data integrity of the test cases, you should PKZip/WinZip (.zip) or Tar/Gzip (.tar.gz) the test cases, even if they are single files.
If you further wish to protect the test cases you may PGP encrypt them to security (at) opera dot com using the public key below, before attaching them to the bug report.
We recommend that if you are planning to publish your report, the information you submit to us must at least include all the information you are going to publish, preferably more. We have occasionally received reports that contained very limited information as compared to what was eventually published, and therefore it was only after publication we were able to understand the true severity of the problem.
Allowing the application vendor to fix the issue before publishing the advisory is good for the users of the application. There is no point leaving end users vulnerable to attack. We at Opera will cooperate and verify the advisory; we can also point out if the issue is not exploitable, helping to increase the quality of the advisory. As a matter of principle we always try to give due credit to responsible reporters in our changelogs or press releases.
Happy, and responsible, hunting!
To contact the Opera Security group, send an e-mail to security (at) opera dot com , whose PGP key is below. As noted above, we prefer that Security Issues are reported via our Bug tracking system, even if you do send an e-mail about the issue.
View the PGP key on our secure server
A large number of people are looking for security problems and vulnerabilities in Opera and other applications. Some people do not like this, but we think it is fine. When done responsibly, this can increase security for the application and is thus of great benefit to users. However, when done irresponsibly, the activity can cause needless alarm, wasting the time of application vendors and end users.
An example of irresponsibility is how they report and classify the issues they find, and how the issues are communicated to the application vendor.
The primary problems we see with some of the reporting is that:
- Many reports are about problems that may be bugs, even significant stability issues, but they are not really security issues.
- Some reports exaggerate the severity of the problem.
- Some reporters do not give us an opportunity to check the problem, verify that it is indeed a security issue, and release a patched version before they publish their findings.
The terms "security issue" and "vulnerability" cover a large number of serious problems within an application.
Security real issues list:
- A real issue makes the application reveal the user's protected information, such as file system information, user name, passwords, etc., without authorization.
- A real issue makes the application mislead the user about what is going on.
- A real issue makes the application execute arbitrary code.
- A real issue uses weak protocols when it is possible to use stronger protocols.
Those are just some of the possibilities. As important is what should NOT be called a security issue.
Security non-issues list:
- A non-issue involves crashes that do not prevent the restart of the application, and do not lead to an execution of arbitrary code.
- A non-issue involves attacks that permanently disable the application.
- A non-issue states that users are not able to access or use their online banking sites, shopping sites, etc. due to site specific problems
- A non-issue states that Web sites claim cookies do not work.
- A non-issue states that the application uses stricter security protections than another competing application.
Sometimes, reporters incorrectly classify instances from the non-issues list as issues from the real issues list.
The two main severity concerns prone to be exaggerated are allegations that a problem "can be used to execute arbitrary code" or is a "Denial of Service" (DOS) attack.
It seems that the combination of a very large input and a crash leads some people to automatically think the problem may be used to "execute arbitrary code", that is, take over the user's computer. That is not always the case, and is usually only possible for what is called a stack buffer overflow, even though it is also sometimes possible for heap (allocated) buffer overflows. However, we have seen this phrase used even for ordinary "NULL pointer" crashes that had no possibility whatsoever to be
abused.
Another exaggeration is calling any crash that can be triggered by a Web site a "Denial of Service" attack. In our opinion, crashing a server which could potentially be running an important or critical service can rightly be called a Denial of Service, as long as the server is not able to automatically recover. This is because bringing down the server will deny service to all users.
Crashing a client, while it is an undesirable event and one we want to fix quickly, can only be achieved by enticing the user into accessing a document that crashes the client. Even then it will usually only inconvenience the user long enough to restart the application. That is not sufficient cause to call it a Denial of Service; in most of these cases it is a stability issue.
The only way, in our opinion, that a crash in a client can be called a Denial of Service is if the attack causes the client to crash again when it is restarted, and when fixing the problem requires more than changing the immediate startup configuration (previous session or blank page). Consequently, this requires editing of the configuration files or a complete re-installation.
In our opinion, calling a normal crash problem in a client a "Denial of Service" vulnerability is a devaluation of the meaning of the term "Denial of Service", which eventually may rob it completely of its correct meaning. Much in the same way, the word "hacker" is now considered to mean "computer criminal", not "highly skilled computer specialist", which was its original meaning. Please see http://en.wikipedia.org/wiki/Hacker_(computing). One may ask if an attack that disables the client really is a
security problem. After all, it does not compromise the user's information security, privacy, or the system's integrity. Generally, we do not consider ordinary crashes, freezes, and other so-called "Denial of Service" attacks security problems; they are stability issues.
Other browser developers have also seen this kind of exaggeration, and Gerv of Mozilla apparently shares our opinion about calling crashes Denial of Service. While we think Microsoft is stretching the definition of Denial of Service, their situation is a bit more complex, which may justify using the definition in their case.
We would like to use this opportunity to ask the security research community to revisit and update/clarify the meaning of their classifications for the various contexts where they are used. In particular, those who maintain vulnerability databases should consider the actual severity of a reported problem before posting the information.
"I think I have found a security issue in Opera. What should I do?"
We recommend: Report it to us before you publish it, so we can fix the problem and release an updated version as soon as possible. We take security seriously, and will investigate all reports.
You should file the report at https://bugs.opera.com/wizard/, with the severity "Security Issue" and you should fill in all information you have, or suspect, about the problem:
* Give a clear and concise explanation of the problem, as complete as possible, including why it is a security issue if that is not obvious.
* Identify which version(s) of Opera you have tested, including which operating system versions. At least one of the tested versions should be the most recent release for the affected platforms.
* Document what is needed to replicate the problem with a step-by-step procedure which includes the source code or command line operations.
* Provide an e-mail address where we can contact you in case we need more information, and to keep you updated about our progress.
* Provide actual test cases. The test cases should contain only the minimum complexity required to reproduce the problem.
* Provide references to previous discussions about the problem area, and if it has occurred in other software.
You should always file a bug report about the issue, even if you are going to send information to the Security Group via e-mail (see below). The report will be filed in our system, and it will remain in the system even if your e-mail should go astray.
Unless they are very short, the test cases should be attached to the bug report by using the e-mail address you get after you submit the bug report.
Server-side test cases should, if there are no special reasons to use other formats, be written in Perl, PHP, or Python. Aside from using standard libraries, they must be self contained.
To protect the data integrity of the test cases, you should PKZip/WinZip (.zip) or Tar/Gzip (.tar.gz) the test cases, even if they are single files.
If you further wish to protect the test cases you may PGP encrypt them to security (at) opera dot com using the public key below, before attaching them to the bug report.
We recommend that if you are planning to publish your report, the information you submit to us must at least include all the information you are going to publish, preferably more. We have occasionally received reports that contained very limited information as compared to what was eventually published, and therefore it was only after publication we were able to understand the true severity of the problem.
Allowing the application vendor to fix the issue before publishing the advisory is good for the users of the application. There is no point leaving end users vulnerable to attack. We at Opera will cooperate and verify the advisory; we can also point out if the issue is not exploitable, helping to increase the quality of the advisory. As a matter of principle we always try to give due credit to responsible reporters in our changelogs or press releases.
Happy, and responsible, hunting!
To contact the Opera Security group, send an e-mail to security (at) opera dot com , whose PGP key is below. As noted above, we prefer that Security Issues are reported via our Bug tracking system, even if you do send an e-mail about the issue.
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP 8.1 mQGiBELOLzkRBADVw74D8uj9bPNzgmfgf9tC72ckgqnxGHrRTMMK9y42XiLXiIYp B66OjYpPiwgWzNqivcuyhc0HUGHZeezyE1wK4qGZ0cvxYuWrod2B0xyIXcDg6jTt Vr/KgbfZy1RhLb9CPW3ngH28wbKAGud7dOsCjqvC+RWXAqPzN9ZXT6S3AwCg/+q6 pzhHdFMjvWrmRuWnypwO3mcD/iDbfiKe7c4nJs+yUveVjEkP+2f/zNg/3lSNUjBO sg9CaXQlC7QCsTLEmDWAmjlebTI/DVlOfnGYa22myj1KLZdx5/uUG0aZUWDMOkKn MjqLSyFRqb4VwSjetoojGcHob5zJQUeZ3+q4fSt66kWRwxARmnP3fyeHtdt+ddWa KkMlBACkj3ZjnORHkyFQDru88IcZKgzTuQzhMcYmCp9vd+gMAy4+r3vUEq5EnXeg ydBVBzReI4bDizjvpwUwbCEOn+ei8n95x2n7DHEjpn2THasb1ENkVfZ1iHi4OnO3 DaqvnXwNhnobEfEEcLjQDvMEjfWx/T1fZ6I1FwXJZr7TzwvJIrQpT3BlcmEgU2Vj dXJpdHkgR3JvdXAgPHNlY3VyaXR5QG9wZXJhLmNvbT6JAF0EEBECAB0FAkLOLzkH CwkIBwMCCgIZAQUbAwAAAAUeAQAAAAAKCRB2h/HMa2j6eQKoAKCv6+UWqdumoTjy bYL5fzdVlUm8BgCdFX2FFnsyd1O9tSszh7JQ20is1065Ag0EQs4vORAIAPZCV7cI fwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ +AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm /xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1F HQ98iLMcfFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzh sSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZ Jrqrol7DVekyCzsAAgIH/1nn7DeOo79hX8V3cgGRbHDyw/CC251salCt5gislPdV RaUAyAC24m2MprPUr6JV6QfmmXgt/FYYbdscREPkbGplXkZFSDlcH8PKfzDDaewG dApQhOCg4bsFNUX46l/kcooAjlihLZbb9XUJ0IqIvbxJze0NtHD6o7ABTQeEagK+ dL/CBlYxMWG4SvCCol88IjsdkwpCrpIMcnh1lGPMEfvCt86hk96Y1jUouve1sLGx zx9QbCqo8TkJyi5bJhCGEHS90nEQsdHmaS+Grvm3eep9dTLxhn+Aj/WTpdUy8VD0 rwPAEKWOo4V4HdNEgGjSNOV8LSp8/2wZR0z7zZc3vYeJAEwEGBECAAwFAkLOLzkF GwwAAAAACgkQdofxzGto+nnZ1ACg9xn8tVb99DfZsC6wRGzr7dtfMU0An1aY3FZ7 k3eRlyzdgO2F+WOHux4J =w+QX -----END PGP PUBLIC KEY BLOCK-----
View the PGP key on our secure server
Mağruf ÇolakoğluZAHEK # Thursday, February 18, 2010 9:18:30 PM
Charles SchlossChas4 # Thursday, February 18, 2010 9:57:11 PM
Cutting Spoonhellspork # Friday, February 19, 2010 2:35:06 AM
This reminds of the time when Cnet was called-out for being troubled when NOD32 did not catch a "non-damaging fake virus, nor a disabled real virus". In other words, they complained that NOD32 was not erroneously reporting a false positive.
You devs have my sympathy for dealing with this storm of scum-sucking bottom dwellers who have neither talents nor valid opinions. Keep up the information holy war.
Annoynimousthe_Arioch # Saturday, March 13, 2010 3:39:17 AM
formally speaking, on Opera's part only the violation of standard, the disclosing of pivate info is on server's side. However, it is Opera's violation that provokes server to do so.
Cutting Spoonhellspork # Monday, March 15, 2010 6:21:03 PM