Weekly Edition
Return to the Security page
| |||||||||||||
The trouble with backporting fixes
Most Linux distributors, as a matter of standard procedure, do not fix
security problems by upgrading their users to the latest version of the
affected program. Instead, the specific fix is painstakingly backported to
whatever version was originally shipped, and a minimally disruptive (one hopes) update
is released. This approach does help protect users from dealing with new
issues caused by unplanned software upgrades, but it poses some risks as
well.
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:
Luckily, Linux 2.4.23-ow2 and 2.4.24-ow1 are not affected as these
patches already included a kernel bug fix which was later
determined to be security-critical and needed to avoid this second
mremap(2) system call vulnerability. In fact, it's the exact same
fix which went into Linux 2.4.25.
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. (Log in to post comments)
Credit where credit due Posted Feb 26, 2004 4:14 UTC (Thu) by ncm (subscriber, #165) [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.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.
Credit where credit due 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.
Additionally there might be compatibility issues with other programs Posted Feb 26, 2004 11:09 UTC (Thu) by miannac (guest, #11411) [Link] The described approach (backported patches) can also create some problems in understanding the compatibility of new packages that people want to install.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
The trouble with NOT backporting fixes Posted Feb 26, 2004 16:33 UTC (Thu) by maney (subscriber, #12630) [Link] 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.There's really no perfect solution to imperfect software other than making the software perfect. :-/
The backport policy is flawed--but entrenched in Debian Posted Feb 26, 2004 16:57 UTC (Thu) by pimlott (guest, #1535) [Link] 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.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.
The backport policy is flawed--but entrenched in Debian Posted Feb 26, 2004 19:24 UTC (Thu) by smoogen (subscriber, #97) [Link] 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 Posted Feb 26, 2004 20:25 UTC (Thu) by ncm (subscriber, #165) [Link] Moving to later versions of glibc need not cause any such problems.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.
The backport policy is flawed--but entrenched in Debian Posted Feb 26, 2004 21:01 UTC (Thu) by oak (guest, #2786) [Link] 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 Posted Feb 28, 2004 13:19 UTC (Sat) by gallir (guest, #5735) [Link] If you really have to recompile everything to assure they work, somethingis seriously flawed in our "shared object" implementation.
|
|||||||||||||