Bitten by old bugs
Posted Aug 14, 2003 5:01 UTC (Thu) by ncm
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
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.
to post comments)