Security Week in Review (2006-12-10)

Tis the holiday season now. I'm traveling about the country to visit the relatives and fix their computers. I suspect the world of security will be rather quiet until after the first of the year. Unless there is something worth commenting on, I don't plan on posting another weekly security commentary until the new year.

gdm
A buffer overflow flaw was found in gdm (CVE-2006-6105). This flaw is a bit interesting when you consider how to exploit it. The gdmchooser application has a format string flaw that can only be exploited by a local user typing into an input box. Since the gdmchooser application is running as the root user, the potential exists for a local user to gain root privileges. The trick here is that there isn't a nice way to paste shellcode into the textbox. The user would have to physically type in the exploit code. This is not a trivial task. This is a good example of where a theoretical flaw collides with the harsh world of reality.

Quite often there are flaws that are sound in theory, but when you look at the exploitability potential, it's more theoretical than practical. Most attacks today are of the automated type. This means that attacks that are more likely to be exploited in an automated manner are of a higher priority than those that would be more of a personalized attack. This doesn't mean that direct attacks should be ignored, simply that flaws should be prioritized and handled accordingly.

D-Bus
A D-Bus denial of service flaw went public last week (CVE-2006-6107). The denial of service isn't the most interesting thing I see here. What I find interesting is how all these desktop bits interact together. As the desktop user experience becomes more rich, the interactions on the back end are going to become more complex. As the complexity increases, the number of potential security flaws increases. Anytime software has to process user supplied input, all values passed to libraries need to be verified. This means that data formats should be as simple as possible. As format complexity increases, libraries tend to stop aggressively checking the user input.

This is easily seen in web browsers. The HTML standard is horribly complex. Checking all possible input combinations is very difficult and the verification code is going to contain bugs as all software does. Such bugs would likely be considered security issues. While HTML is a somewhat unique situation, new data standards would benefit greatly from keeping things as simple as possible if for no other reason than avoiding security flaws.


Well, that's all for this week. Things were pretty slow as was expected.