Things were fairly sane this week. The most exciting event was a rather foul GnuPG flaw.
GnuPG
A very interesting GnuPG flaw was found by Tavis Ormandy this week (
CVE-2006-6235). This flaw was the result of GnuPG code which was using a stack variable to hold a function pointer. This value was still used once the stack had unwound itself, possibly leading to arbitrary code execution.
For those of you unfamiliar with this idea, the stack is best represented as a "stack" of something, let's say pieces of paper for the sake of this example. When a function is called, a new piece of paper is added to top of the pile with whatever information the function needs to run properly. Once the function returns, the piece of paper is removed and discarded. Now imagine an instance where we pass around a pointer to some data printed on one of the pieces of paper. If that piece of paper is no longer on our stack, the pointer now points to unknown data, likely information which is part of a new stack variable. If an attacker can control the value of the data we point at, they can make it contain a value which can be used to alter the execution of the GnuPG process. The idea here being that if I send you a malicious GnuPG message, I can run whatever commands as your user I want to (arbitrary code execution). The scary part here is all the things that will run GnuPG automatically over untrusted data, such as a mail programs.
eEye Digital Security
eEye came to my attention for two reasons this week.
The first thing I noticed is that eEye launched a
Zero-Day Tracker. The noteworthiness of this is that there is nothing noteworthy about it. The goal of eEye is to frighten people into purchasing one of their products or services. I'm not a fan of this business model. It's in the best interest of these groups to overplay the severity of security issues and report them irresponsibility. This brings me to the second reason eEye was noticed this week.
Intel Network Adapter Driver Local Privilege Escalation
This advisory states that the Linux kernel is vulnerable to a local privilege escalation flaw. This statement is not in any way true. After various kernel developers looked at this report, they verified that this flaw does not affect the Linux kernel in a meaningful way. It is possible for the root user to cause a 4 byte buffer overflow, but if a malicious user already has root access, this is a trivial problem. The responsible thing for eEye to do would be to note this detail in their advisory.
The volume of misleading information in the security world seems to be increasing as of late. I have no real data to back this up, it's simply something I've been noticing. It seems that there are a number of researchers trying to attain security rockstar status by finding relatively minor flaws, then trying to pass them off as being serious. The problem I have with this is as the noise increases, it becomes harder to raise awareness to issues that matter. This is where sane vendor response is key. It's important for a vendor to not downplay an issue, and also to treat an issue with appropriate severity. There are many times I see various vendors fix the lame easy issues, but then sitting on some harder flaws. The difficulty of fixing a flaw should not dictate how its severity is assigned.
And now, time to wait and see what next week brings.
