linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: neilb@cse.unsw.edu.au (Neil F. Brown)
To: nfs@lists.sourceforge.net, linux-kernel@vger.kernel.org
Cc: Janusz Niewiadomski <funkysh@isec.pl>
Subject: ANNOUNCE: nfs-utils 1.0.4
Date: Tue, 15 Jul 2003 03:00:01 +1000	[thread overview]
Message-ID: <1030714170001.24267@cse.unsw.edu.au> (raw)

This release of nfs-utils contains:

 1/ Fix for a remotely exploitable buffer-overflow bug.
 2/ assorted minor bug fixes
 3/ Extensive changes to make use of new functionality in linux-2.6.0 nfsd

nfs-utils 1.0.4 can be downloaded from 
  http://sourceforge.net/project/showfiles.php?group_id=14
or
  http://www.{countrycode}.kernel.org/pub/linux/utils/nfs/

I consider this release to be a pre-release for 1.1.0 which I hope to
release before linux-2.6.0-final.  Bug reports are very welcome.


1/ A buffer-overflow bug was found by 
    Janusz Niewiadomski
    iSEC Security Research
    http://isec.pl/

  It is trivially exploitable to effect a remote denial of service.
  More subtle exploits may be possible.

  I recommend that all users of nfs-utils either:
    1/ upgrade to 1.0.4 
  or
    2/ Get an update from their vendor (most vendors should have an
       update available).

  I also recommend that all NFS services be protected from the
  internet-at-large by a firewall where that is possible.

2/ See the change log in the source for details on bug fixes.

3/ In 2.4 and earlier kernels, the nfs server needed to know about any
 client that expected to be able to access files via NFS.  This
 information would be given to the kernel by "mountd" when the client
 mounted the filesystem, or by "exportfs" at system startup.  exportfs
 would take information about active clients from /var/lib/nfs/rmtab.

 This approach is quite fragile as it depends on rmtab being correct
 which is not always easy, particularly when trying to implement
 fail-over.  Even when the system is working well, rmtab suffers from
 getting lots of old entries that never get removed.

 With 2.6 we have the option of having the kernel tell mountd when it
 gets a request from an unknown host, and mountd can give appropriate
 export information to the kernel.  This removes the dependancy on
 rmtab and means that the kernel only needs to know about currently
 active clients.

 To enable this new functionality, you need to:
   mount -t nfsd nfsd /proc/fs/nfs

 before running exportfs or mountd.  

 If you are using 2.6.0-testX and exporting files with NFS *please*
 test this out and let me know of any problems.

NeilBrown - July 2003


             reply	other threads:[~2003-07-14 16:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-14 17:00 Neil F. Brown [this message]
2003-07-14 19:34 ` ANNOUNCE: nfs-utils 1.0.4 Steven Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1030714170001.24267@cse.unsw.edu.au \
    --to=neilb@cse.unsw.edu.au \
    --cc=funkysh@isec.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).