The trouble with backporting fixes
Consider, for example, this notice sent out to users of Solar Designer's Openwall Linux. On the topic of the recently discovered mremap() vulnerability (the second such), it states:
We asked Solar how it was that his patch, which fixed the problem long before it was reported, was not more widely distributed. His response was that he had sent a patch around, but most distributors did not see at the time that the bug had security implications, so they left it out in order to distribute a minimal fix for the first mremap() problem. By insisting on a minimal patch, the distributors left their users open to another vulnerability, and forced them to deal with yet another security update shortly thereafter.
The free software community, in fact, has a long history of bug fixes which, at some later point, turn out to close a security hole. Certain members of the black hat community spend a lot of time digging through changelogs looking for just this sort of problem. Some of them have a true gift for seeing vulnerabilities where the original developers see only bugs. For these people, software changelogs are a roadmap of potentially exploitable bugs known to exist on most deployed Linux systems.
Few system administrators enjoy being forced to upgrade a package in a
hurry. They have learned through hard experience that such upgrades can
introduce no end of problems and make a serious dent in their weekend
beer-drinking time. In the end, however, we may be forced to face a simple
fact: any bug may potentially have security implications. It may be that
the Fedora Project has the right idea: when a security hole must be closed,
that should be done by upgrading the whole package to the current version.
Relatively young software and the new and unknown bugs it is certain to have may turn
out to be safer than staying with an older version, which has old and
well-documented bugs.
| Index entries for this article | |
|---|---|
| Kernel | Security |
Posted Feb 26, 2004 4:14 UTC (Thu)
by ncm (guest, #165)
[Link] (1 responses)
Running newer versions is no panacea. New features are fertile ground
for un-reported and un-analyzed bugs, readily discovered by inspection.
It may be that critically-exposed software should be released in a form
in which new features can be ifdef'd out until after they have been
vetted thoroughly.
Posted Feb 26, 2004 11:13 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Running newer versions is no panacea. Most big projects have two versions anyway: stable and development (untested, beta, etc). Vendors should stick to stable version and try to avoid creation of "super-stable" version by backporting only security bugs. Reason is simple: almost noone (except very few maintainers and black hats) will look on this version. That's all.
Posted Feb 26, 2004 11:09 UTC (Thu)
by miannac (guest, #11411)
[Link]
For example: also Suse always backport the kernel fixes to the kernel release that was originally shipped with that specific distribution. Now, this makes more difficult for me to install programs that require specific kernel releases (i.e the one related to wlan, PCMCIA, USB, etc): how do I know if current latest kernel release (k_smp4G-2.4.21-192) is compatible with 2.4.21, 2.4.22, 2.4.23.. even 2.6.x? The alternative is to use always latest std kernel releases... but then you always need to check if that std kernel release doesn't break some of the installed packages (and their dependencies). Marco
Posted Feb 26, 2004 16:33 UTC (Thu)
by maney (subscriber, #12630)
[Link]
There's really no perfect solution to imperfect software other than making the software perfect. :-/
Posted Feb 26, 2004 16:57 UTC (Thu)
by pimlott (guest, #1535)
[Link] (4 responses)
I tried to raise
this with the Debian security team, but made no headway. I think they
have misjudged the security/stability trade-off: the security issue is much
worse than they allow, and the stability issue is manageable. Most projects
are quite good about not breaking things in their stable branches; and even
if they occasionally break things, we should respond by 1) working with
upstream to create more stable "stable" branches and 2) improving our
testing processes, not by reverting to minimal (and inevitably incomplete) security fixes.
Posted Feb 26, 2004 19:24 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (3 responses)
Posted Feb 26, 2004 20:25 UTC (Thu)
by ncm (guest, #165)
[Link] (2 responses)
Nothing that depends on the older version needs to be recompiled,
because the glibc ABI is enforcedly stable. Glibc uses ELF versioning
to preserve old interfaces and semantics -- although they don't
necessarily preserve old bugs that result in undocumented behavior.
That's to the good, because the programs get unexpected fixes, and
only programs that depended on undocumented behavior get new problems.
I.e. the ripple effect peters out fast.
Posted Feb 26, 2004 21:01 UTC (Thu)
by oak (guest, #2786)
[Link] (1 responses)
Posted Feb 28, 2004 13:19 UTC (Sat)
by gallir (guest, #5735)
[Link]
I believe it has always been OpenBSD's position that all bugs are security
holes until proven otherwise. It's no fun seeing proof.
Credit where credit due
Credit where credit due
The described approach (backported patches) can also create some problems in understanding the compatibility of new packages that people want to install.Additionally there might be compatibility issues with other programs
I think you gloss over the advantage of a backporting policy, or rather a crucial effect of that policy: the confidence that the backported fix can be installed without any worry about breaking even obscure corner cases. Considering how large a part of the problem belated application of fixes is in the real world, this is worth quite a bit. Better a possibly imperfect fix that you feel safe applying now than one that's more comprehensive but that you can't trust without a week's testing... even aside from the cost of doing the testing.
The trouble with NOT backporting fixes
It is surprising to me how popular the backport policy has become, because
the serious dangers ought to be obvious (and hopefully Jonathan's article
will help work them into the community's consciousness). This is far from
the first time this has happened; just look at this
LWN vulnerability report for
another instance and some discussion.
The backport policy is flawed--but entrenched in Debian
It all depends on the package and the change. If Debian has to fix xmms, it is probably easier to go to the latest and greatest that has the fix. If the problem is in glibc.. then having to recompile everything in Debian stable to use the latest glibc means a lot of work (plus other problems cropping up.)
The backport policy is flawed--but entrenched in Debian
Moving to later versions of glibc need not cause any such problems.
The backport policy is flawed--but entrenched in Debian
You need to recompile everything (including all architectures) just to make sure that the new glibc version really works. And by "works" I don't mean that it would run software correctly, just that it can be used to build it.The backport policy is flawed--but entrenched in Debian
If you really have to recompile everything to assure they work, something The backport policy is flawed--but entrenched in Debian
is seriously flawed in our "shared object" implementation.