Weekly Edition
Return to the Security page
| |||||||||||||
|
| |||||||||||||
On quietly fixing security holes
A recent Bugtraq posting came with the
following statement:
I have discovered a signed/unsigned issue in a routine responsible
for demarshalling XDR data for NFSv3 procedure calls. As far as I
can tell, this bug has existed since NFSv3 support was
integrated. It has been silently fixed in 2.4.21.
This bug allows a remote attacker who can send packets to an NFSv3 server to overwrite memory and bring the system down. It would appear to be a hard vulnerability to exploit for anything beyond a denial of service, however. The problem was not fixed entirely silently in 2.4.21; the relevant changelog entry reads "Avoid oops when NFSD decodes enourmous filehandle." Still, the fix has not been all that widely advertised either; there have been no alerts reading "systems running 2.4.20 and prior kernels may be subject to a denial of service vulnerability." In that sense, this was a classic "quiet fix." There are advantages to quiet fixes when nobody is known to be exploiting the problem. With luck, the fix will be widely deployed before anybody notices the problem. If all goes well, many vulnerable installations can be protected before anybody begins to exploit the problem, and without the need for a panic update. These advantages need to be weighed against a couple of problems with quiet fixes, however. One is that crackers do watch changelogs and patch releases, hoping to find just this sort of fix. And the other is that many sites may continue to run vulnerable code because nobody has told them that there is a problem. If you run any NFS servers with kernels older than 2.4.21, this is your notice that you may want to look into an upgrade. So far, nobody has been hurt by the quiet nature of this particular fix. Even so, it would have been better to treat it as the true security hole that it is. (Log in to post comments)
On quietly fixing security holes Posted Jul 31, 2003 1:53 UTC (Thu) by smoogen (subscriber, #97) [Link] Another kind of quiet fix I have seen was that the fix was put in for one reason and completely fixed another security related issue... Of course convincing paranoid people it was by accident is often impossible.
On quietly fixing security holes Posted Jul 31, 2003 9:11 UTC (Thu) by beejaybee (guest, #1581) [Link] "With luck, the fix will be widely deployed before anybody notices the problem. If all goes well, many vulnerable installations can be protected before anybody begins to exploit the problem, and without the need for a panic update."Sounds suspiciously like an excuse for those suppliers who argue for non disclosure. "crackers do watch changelogs and patch releases, hoping to find just this sort of fix" Precisely. I don't think this sort of thing can _ever_ be "ignored". Unpatched systems can and will give linux a bad name if and when a working exploit is developed. IMO every linux user owes a duty to the whole community by keeping systems patched so that exploits cannot get to the point where headlines are likely to be generated.
On quietly fixing security holes Posted Jul 31, 2003 15:58 UTC (Thu) by DaveK (subscriber, #2531) [Link] IIRC there are a few 'nasties' in 2.4.20 that could be harnessed to yield more damaging exploits. This quiet NFS fix can probably be forgiven in this instance on the understanding that most sites will have already updated their 2.4.20 machines to fix those other problems.This may not always be the case however.
|
|
||||||||||||