Warning message

Log in to add comments.

What defines a security issue?

bressers@redhat.com published on 2012-10-17T13:00:52+00:00, last updated 2012-10-17T13:00:52+00:00

When dealing with developers, this question comes up fairly often:

Is this bug a security issue?

It is not always obvious if a bug is a security flaw or not. The reality is that the line is quite gray when it comes to deciding if something is a security flaw or not. It depends on a lot of factors, many of which are complicated and confusing.

Consider the following example:

CVE-2012-1182 describes a problem in Samba where a remote attacker could run arbitrary code as root. This is a fancy way of saying a really bad security flaw. In this context, a remote attacker is a person who has access to a computer via the network. A locked server room and good passwords would not help. Arbitrary code is the ability to run anything you want: a virus, a worm, or even a password stealing program. The root user on Linux is the superuser. If you can run things as root, you can generally do whatever you want (Security-Enhanced Linux (SELinux) changes this dynamic, but that is beyond the scope of this article).

A bug allowing anyone on your network to execute whatever they want on the Samba server is pretty bad. Not all security flaws are this straightforward, however.

The following is a more complicated example:

CVE-2012-4285 describes an issue in Wireshark that leads to a divide-by-zero error. This will crash Wireshark while reading network data. It is easy to make the argument that this is not a security flaw. If Wireshark crashes on a divide-by-zero error, who cares? You cannot execute arbitrary code as any user.

CVE-2012-4285 sounds like a bug, but it is a bit more complex than that. This is an instance where the context of what we are doing matters. If an end user application, such as a PDF viewer, crashed due to a divide-by-zero error, it would not matter much. Just do not open that PDF file again. Wireshark is different though - it is often used as a security tool. Consider this fictional example:

Your network has been acting up, strange things are happening, so you decide to capture some network traffic. There is indeed an attacker inside your network. The network issues you see are from the attacker probing various systems and services. The attacker knows Wireshark will be run eventually, so immediately before they send a new probe, they first send a packet that will trigger CVE-2012-4285. Your Wireshark never captures the probe attempts, because it keeps crashing.

Sometimes it is really hard to decide what is or is not a security flaw. Even the experts often debate if a given bug should be a security flaw or not.

The following is a trickier example:

CVE-2012-4245 describes an error in the GIMP scriptfu server that allows a remote attacker to execute arbitrary code. This is the same as the Samba flaw! We know it must be a very serious issue.

Actually, it is not a security flaw at all. It just reflects the fact that the scriptfu network server is not secure (as upstream documented), and so the GIMP scriptfu network server should never be exposed to a public network, or even used in a production environment.

The fundamental take away here is that security is hard. There is no simple answer to any of this. Every issue must be investigated on its own merits. As we saw above, just because two different bugs have the same outcome, it does not mean they are treated equally. Keeping users and products secure is not a trivial task; it takes a lot of hard work from knowledgeable people. This difficulty is why vendors will often assign a security severity to their advisories. Tools like CVSS can be a useful guide in determining how bad a security issue really is. Simply reading a description isn't always enough information to understand the full impact of what's going on.


About The Author

bressers@redhat.com's picture Red Hat


Josh Bressers is a Security Strategist for Red Hat in the Platform Business Unit. Josh has been involved in security for more than 20 years, with a heavy focus on open source. Josh spent more than 12 years at Red Hat as part of various security teams, everything from security response, open source s...