Bitten by old bugs [LWN.net]

Bitten by old bugs

Posted Aug 14, 2003 5:01 UTC (Thu) by ncm (subscriber, #165)
Parent article: Bitten by old bugs

All bugs are security holes until proven otherwise.

That's why OpenBSD doesn't announce security holes they find when they fix bugs in inherited packages. Instead, they advise users to run the latest versions of everything. They also advise anybody who cares about the security of those packages to watch (and, one hopes, apply) OpenBSD's patch list.

Last year I fixed a bug in Gnome libxml2 -- a double-free error that could be evoked, if I recall correctly, by supplying bad XML text. Exploits of double-free errors have appeared in the wild, although they are a little harder to make work, and more dependent on exact versions, than your typical buffer overflow. Nobody announced a security hole in libxml2. Should they have? Bugs are getting fixed all the time. No exploits have been reported yet. Arguably, though, libxml2 is used widely enough now that it demands the level of auditing thus far reserved for mail transport agents and secure remote login services. XML from all over gets parsed by all kinds of programs, some of which run privileged, and all of which (anyhow) run on systems that are easier to crack from a login than remotely.

As it is, any time somebody competent wants to break into a host somewhere, it suffices to look at the list of bugs fixed in package versions released after the host was installed. Only the tiniest minority of those packages will have had security alerts (which get ignored by maintainers of 40+% of exposed hosts anyhow). While the majority of bugs probably turn out not to have been exploitable, it's remarkable how many are. (Where no fixed bug serves, new features often bring easily-detected bugs of their own, so change logs for older versions offer black hats a second chance.)

This suggests that the Debian Project policy of preferring to keep old versions of packages around, and backporting only patches reported as security problems, might be unwise. For security-critical programs and the libraries they use, it might be better to maintain forks that get all applicable bug fixes, not just those attached to security advisories. While bug fixes bring their own risks, those risks don't generally involve marauders behind your firewall.

I don't know of any case of a security hole deliberately introduced along with a bug-fix source code patch. Although that is conceivable, it would be risky and anyway unnecessary; there are plenty of bugs already there to exploit. The ready supply of old bugs is probably also the reason that we have so rarely seen attacks on code repositories such as just happened to the FSF's ftp site. They just haven't been necessary. If we ever start treating all bugs (and new features) as potential security holes, these other avenues might become more attractive.

(Log in to post comments)

Bitten by old bugs

Posted Aug 14, 2003 6:17 UTC (Thu) by proski (subscriber, #104) [Link]

While the majority of bugs probably turn out not to have been exploitable, it's remarkable how many are.

However, the attacker needs only very specific vulnerabilities. If the attacker has no local account, s/he needs a remote exploit. Many holes require social engineering to be exploited - they may be useless against smart users. Most software is not directly listening to the ports - it needs to be run by other software or by one of the user (often by root). Double free in a piece of software that nobody runs on untrusted data is useless.

The ready supply of old bugs is probably also the reason that we have so rarely seen attacks on code repositories such as just happened to the FSF's ftp site.

As far as I know, it was a brand new bug that didn't have a fix released at the time it was exploited.

Bitten by old bugs

Posted Aug 14, 2003 16:13 UTC (Thu) by ncm (subscriber, #165) [Link]

Libraries used by programs that do keep open ports are rarely treated with the same care as those programs, even though they contribute equally to vulnerability. Also, programs running at reduced privilege are not treated as seriously even though vulnerabilities there lead to local shell access and to the much richer exploit opportunities available that way.

The FSF ftp server compromise occurred not because a new hole opened up, but because somebody found a hole that was there and used it. Probably there are dozens more, and it might have happened dozens of times before, but not so many people are interested yet. As it is, the best that can be done is to reduce the number of people who have logins.

Bitten by old bugs

Posted Aug 15, 2003 13:57 UTC (Fri) by pimlott (guest, #1535) [Link]

This is absolutely true, and I'm glad you've explained it so well. This idea of backporting only "security" fixes sounds like a prudent engineering principle, but the reality is far less pretty. As you said, there's just no way that all fixed bugs can be evaluated for their potential exploitability, and missing just one is enough.

Furthermore, running a patched older version leaves you running a configuration that nobody upstream is even thinking about. It's like taking a boat out without telling anyone. With the current version, you have a whole community watching your back. (Say a bug is found in the current version that happens not to be exploitable because of some other change since your version. Is anyone going to tell you?)

In practice, the best software development teams (and I'm not just talking about OpenBSD) have a simple "don't leave bugs open" discipline. You take some risk by continuously fixing bugs, but with a little intelligence, the risk is very small and entirely acceptible. And the benefits are, of course, in more than security: every bug hit is an alienated user.

Frankly, many small projects don't even really need separate stable branches, because even "development" releases are highly unlikely to break anything. That said, bigger, more complex projects should have stable branches on which bugs are fixed aggressively. If they don't, the distributions should pick up the slack, but they should encourage upstream to do it, so there are more hands and eyes involved, and the whole user base benefits.

The OpenBSD guys ought to be among the most qualified to distinguish "security" bugs from other bugs, and even they don't do it. Debian shouldn't either.