Josh's Blog

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.

imlib2
A number of flaws were found in imlib2. After some analysis I found that these flaws are not present in the imlib code, only imlib2. I've noticed that most image loaders do a rather poor job of verifying the data passed into them from the images loaded. Luckily, they're also getting better at fixing these flaws.

Firefox and Friends
The Mozilla project released new versions of Firefox and Thunderbird on Tuesday. This is always a busy time around Red Hat as we have to update Firefox, Thunderbird, and Seamonkey. They all take quite some time to build and QA properly. While I have no impirical data to back up this statement, it seems like the Mozilla project updates are getting less severe with each update.

Most of these flaws can be blocked if you install a plugin such as NoScript which can be configured to only run JavaScript from trusted sites. It's always important to keep in mind that this isn't completely foolproof as many sites will import content from third parties (advertisers for example). It should be noted that NoScript doesn't stop the HTML layout bugs, which can be triggered by nothing more than a web page.

OpenSSH
A rather interesting OpenSSH security update was released this week. OpenSSH 4.5 was released with the changelog claiming to fix this:

* Fix a bug in the sshd privilege separation monitor that weakened its
verification of successful authentication. This bug is not known to
be exploitable in the absence of additional vulnerabilities.

The truly interesting bit of this fix is that while it's called a security issue, it's not exploitable. The unique thing is that while this issue alone shouldn't even be considered a security issue, but it would be a critical flaw if an "additional vulnerability" is found.

When OpenSSH is run in privileged separation mode, there are two processes at work, one process is privileged, the other is not, with the intention being that since user interaction happens against the unprivileged process, a vulnerability in sshd won't give up root. This flaw is the result of the two processes getting out of sync, where the privileged process thinks authentication was successful, while the unprivileged process knows it wasn't. Luckily the unprivileged process causes both to exit after authentication fails. If there was a way to cause the unprivileged process not to exit, it's possible that a remote attacker could gain unauthenticated access to the machine. This is of course completely theoretical, but given the potential, it's worth fixing.

Red Hat Enterprise Linux OVAL Support
Red Hat now publishes OVAL definitions via Red Hat Network with each security update. The Open Vulnerability and Assessment Language (OVAL) provides a standardized language to describe a security vulnerability and how it may affect a given machine. This means that it is possible to feed the Red Hat provided OVAL definitions into an OVAL parser, which will tell you which particular vulnerabilities your machine is affected by.

I've decided to put an effort forth to summarize the previous weeks security events and how they relate to the Red Hat and Fedora community. There is a great deal of misleading information anytime a security vulnerability is found and fixed. Sometimes it's the result of researchers looking for more press than they deserve, but most likely it's the result of misunderstanding. Security vulnerabilities are usually difficult to understand and are usually even harder to assign a proper severity rating to. If you're unfamiliar with how severity is assigned to security issues found in Fedora Core and Red Hat Enterprise Linux, the Security Classification page should help define the ratings. The thing to keep in mind is that the goal of the ratings are to be clear and simple.

So on to this weeks issues.

The two most prominent security updates this week were in PHP 5.2.0 and Wireshark 0.99.4. The PHP update is the most severe of the two.

Wireshark
Wireshark is usually assigned a severity rating of moderate due to the nature of the program. Most of the flaws will only cause one of the Wireshark dissectors to crash or sometimes execute arbitrary code. This means that the user will have to capture data off the network or open a malicious network dump file and use the appropriate broken dissector to view the data. Due to the high level of user interaction needed for this attack to succeed, a rating of Important or Critical would be most inappropriate. My only issue with this update was listing this bug as a security issue:

If AirPcap support was enabled, parsing a WEP key could sometimes cause a crash.
Versions affected: 0.99.3.

That bug is a buffer overflow caused when a user of AirPcap enters a very long WEP key into a dialog box. If you can be tricked into entering a very long, very odd looking WEP key into a dialog box, it's likely easier to trick you into running a dangerous command as root. Luckily though, AirPcap is a Windows Wireshark addon, so it doesn't affect us anyhow.

PHP
The most important fix in the PHP release is this one:

Fixed a possible buffer overflow in the underlying code responsible for htmlspecialchars() and htmlentities() functions

This flaw could allow a script that passes arbitrary data from a website into the htmlspecialchars() or htmlentities() functions to overflow a buffer and possibly execute arbitrary code. We've assigned it a severity of Important. This issue isn't deserving of a Critical rating since there are too many "ifs". Most notably, your PHP application has to pass unsanitized data into one of the vulnerable functions in a certain way.

Most of the other PHP security fixes are in open_basedir and safe_mode functions. These fixes probably shouldn't be considered security fixes as they are band aides, not actual fixes. PHP's built in safe_mode and open_basedir restrictions are fundamentally broken by design and should not be trusted as ways to secure a PHP installation.


Press
I think the most frustrating security article from last week was a Slashdot story: Another Denial of Service Bug Found in Firefox 2. I fail to understand how this is considered news. All web browsers have lots of bugs that will crash them. If you've ever tried to load a large XML document in Firefox, you'll also see what is best described as a DoS bug too. At Red Hat we classify this bug as the "don't do that" sort (bug, not security issue). If a user visits a web page that crashes their web browser, they're just not going to visit that page again. I could understand this issue being news perhaps if it could prevent Firefox from starting without blowing away ~/.mozilla, but the actual issue is just plain silly to make a big deal about.

In general the week was fairly slow with nothing terribly exciting surfacing. See you next week.

Slashdot today had an article titled Another Denial of Service Bug Found in Firefox 2. For those of you smart enough not to read the Full Disclosure and Bugtraq mailing lists on a regular basis, there has been quite a bit of Firefox denial of service (DoS) traffic lately. While there's nothing wrong with such information, the amount of attention it's getting is rather misleading.

Red Hat usually doesn't consider client crashes such as this security issues. We call them bugs of the "don't do that" class. While it may be trivial to crash Firefox, you have to convince a user to visit a certain web page to crash their browser. Even then, how many times doesn't Firefox crash for no apparent reason anyhow?

I don't usually expect people posting information to various public lists to fully research every issue they post. Part of the advantage to sharing information with a public list is to get information from others in the know regarding your issue. What annoys me is when an organization such as SANS does a terrible job describing an issue. Anyone who ran Firefox in a debugger and caused that crash would notice that the crash was being caused by a NULL pointer dereference. A NULL pointer dereference is almost never exploitable beyond a DoS (certainly not in this case). The SANS Handler's Diary also specifies that the entry will be updated if more information becomes available, which it never was. The issue was discussed on the Bugtraq mailing list where it was made rather clear that this flaw presents no threat beyond a DoS.

As the volume of possible security issues increases, I worry about the current trend I see. Most organizations are willing to call something a security flaw with no real research into what the actual cause is, or what programs are affected by the issue. At Red Hat we do our best to sort the wheat from the chaf, which I believe is part of the added value the Red Hat Security Response Team lends to our products. I would very much like to see the rest of the security community put an effort forth to help with this effort.

Updated:
I should also add that part of my goal in writing this is to become more involved in the information posted to various public lists. In the past I've been far to willing to just let misleading public information slide. If I'm going to complain, I need to take responsibility for my actions (or lack of action in this instance).