In general this was a fairly slow week. I can't say I mind slow weeks all that much as they provide time for the various projects in that "other" category. Next week is a US holiday (Thanksgiving), so it's possible I won't find the time to write the week in review. I suspect unless there's something rather exciting to comment on (or visiting the relatives proves to be very boring), I'll take it off.
libpng
An out of bounds (OOB) memory read flaw was found in libpng (
CVE-2006-5793). This flaw can only cause a client using libpng to crash, there is no potential for arbitrary code execution. This begs the question, should a bug like this be considered a security issue?
Right now most client side crashes get a CVE id. There is no question that if a bug causes a long running server process to crash, it's a denial of service flaw. What's the adverse affect of a client side crash? I'll agree that it's annoying, but it probably falls into the class of "don't do that" bug. It's a bit like the old joke where the patient tells the doctor it hurts when he moves his arm in a certain way, and the doctor replies "then don't do that".
links
An arbitrary command execution flaw was found in the links SMB browser (
CVE-2006-5925). Red Hat considered this flaw to be of critical severity and we burned the midnight oil to get a fix out as fast as possible. While most people consider links to be a rather low profile program, when we assign severity to a flaw, we do so based on technical merit, not on popularity. While I personally won't lose much sleep over a critical links flaw as it's not my browser of choice, someone who is a links user will be rather concerned.
SANS Top-20
The
SANS Top-20 list came out this week. If I had to sum the list up in a single word, it would have to be "lame". Most of the things mentioned in the list are a bit of a stretch to consider them serious security issues. Many of them are fairly moderate in my opinion. I think the list is a testament to security being taken somewhat seriously these days. I do have a few nitpicks though:
PHP remote file includes are listed as a threat, with a possible outcome being rootkit installation. While it's maybe be possible that this is possible on a windows system (I have no idea, but I doubt it), it definitely is not on a Linux system. In order for a PHP flaw to install a rootkit, an attacker would first have to first use the PHP exploit to gain local access, then leverage a local privilege escalation flaw to install a rootkit.
The mitigation section then goes on to say that one way to protect yourself is to enable the open_basedir PHP option. This advice is terrible as PHP's open_basedir functionality is fundamentally broken by design. Misleading security features are worse than no security features as they provide a false sense of protection.
I also found this tip a bit disturbing:
* As a last resort, consider banning applications which have a track record of active exploitation, and slow response times to fix known security issues.
That should not be a last resort, it should be common sense. Anyone who runs an application that fits this description should expect to be compromised.
I also think the list should include Firefox. It lists Internet Explorer, which has had a number of critical vulnerabilities against it. Firefox is really no better in this respect. All web browsers contain lots of security flaws, Firefox is no different. I'm not sure why they left out Firefox, but my guess would be that it lacks the widespread exploits Internet Explorer enjoys.
Well, that's all for this week. See you next time.
