A recent Bugtraq posting
came with the
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,
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.
to post comments)