From j@hosting3.clara.carpediem.fr  Sun Apr 21 01:18:59 2002
Return-Path: <j@hosting3.clara.carpediem.fr>
Received: from hosting3.clara.carpediem.fr (hosting3.clara.carpediem.fr [212.43.240.203])
	by hub.freebsd.org (Postfix) with ESMTP id 131F937B41C
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 21 Apr 2002 01:18:58 -0700 (PDT)
Received: (from root@localhost)
	by hosting3.clara.carpediem.fr (8.11.6/8.11.6) id g3L8IfZ32009;
	Sun, 21 Apr 2002 10:18:41 +0200 (CEST)
	(envelope-from j)
Message-Id: <200204210818.g3L8IfZ32009@hosting3.clara.carpediem.fr>
Date: Sun, 21 Apr 2002 10:18:41 +0200 (CEST)
From: Frank Denis <j@pureftpd.org>
Reply-To: Frank Denis <j@pureftpd.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc: j@pureftpd.org
Subject: Denial of service through bad NFS packet
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         37304
>Category:       kern
>Synopsis:       Denial of service through bad NFS packet
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Apr 21 01:20:02 PDT 2002
>Closed-Date:    Sun Apr 21 09:26:31 PDT 2002
>Last-Modified:  Sun Apr 21 09:26:31 PDT 2002
>Originator:     Jedi/Sector One
>Release:        FreeBSD 4.5-STABLE i386
>Organization:
42 Networks
>Environment:
System: FreeBSD hosting3.carpediem.fr 4.5-STABLE FreeBSD 4.5-STABLE #11: Mon Jan 28 09:43:06 CET 2002 j@hosting3.carpediem.fr:/usr/obj/usr/src/sys/J i386



>Description:

Special NFS packets can cause a kernel panic on a BSD NFS server.

It doesn't seem to be a FreeBSD specific issue, I've found that OpenBSD is
vulnerable as well.

>How-To-Repeat:

To trigger the kernel crash, a client can mount a NFS export with the
following options :

tcp,rdirplus,-r=32768,-w=32768

The server immediately crashes after some transfers.

With UDP NFS + rdirplus, transfers hang but the server doesn't crash.
With TCP NFS + rdirplus, a kernel panic occurs because the chunk is too
large (it exceeds NFS_MAXPACKET) .

>Fix:

While this may not be a correct fix, it may be better to ignore such packets
instead of going into a kernel panic (think about publicly accessible NFS
shares) .

Simple patch follows :

--- sys/nfs/nfs_syscalls.c.orig	Sun Apr 21 10:08:01 2002
+++ sys/nfs/nfs_syscalls.c	Sun Apr 21 10:08:47 2002
@@ -622,8 +622,8 @@
 				m = m->m_next;
 			}
 			if (siz <= 0 || siz > NFS_MAXPACKET) {
-				printf("mbuf siz=%d\n",siz);
-				panic("Bad nfs svc reply");
+				printf("mbuf siz=%d - bad client options\n",siz);
+				break;
 			}
 			m = mreq;
 			m->m_pkthdr.len = siz;

>Release-Note:
>Audit-Trail:

From: Jedi/Sector One <j@pureftpd.org>
To: freebsd-gnats-submit@FreeBSD.org, j@pureftpd.org
Cc:  
Subject: Re: kern/37304: Denial of service through bad NFS packet
Date: Sun, 21 Apr 2002 17:41:30 +0200

   Please close that PR, false alert, sorry.
   
   FreeBSD is _not_ vulnerable to this, the real fix occured in nfs_serv.c a
 while ago.
 
   Great news :)
   
   

From: Ian Dowse <iedowse@maths.tcd.ie>
To: Frank Denis <j@pureftpd.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: kern/37304: Denial of service through bad NFS packet 
Date: Sun, 21 Apr 2002 16:47:07 +0100

 In message <200204210818.g3L8IfZ32009@hosting3.clara.carpediem.fr>, Frank Denis
  writes:
 >To trigger the kernel crash, a client can mount a NFS export with the
 >following options :
 >
 >tcp,rdirplus,-r=32768,-w=32768
 >
 >The server immediately crashes after some transfers.
 
 Was this a FreeBSD client? I wasn't able to reproduce this on a
 loopback NFS mount on FreeBSD -current or -stable. It would be
 useful to get a tcpdump of the request packet that actually triggers
 the crash (with options "-X -s 1600" to get the full data).
 
 However, I did find one related bug in the NFS code that might be
 responsible, but I could only trigger this with a crafted NFS request
 that contained an over-long readdirplus `count' field. A patch for
 this issue is below, so it would be interesting to see if it helps.
 
 NFS server op functions are never supposed to return a reply that
 is longer than the NFS protocol permits, regardless of what the
 client sends, so it is best to leave the `Bad nfs svc reply' error
 as a panic and fix the real bug.
 
 Ian
 
 Index: nfs_serv.c
 ===================================================================
 RCS file: /home/iedowse/CVS/src/sys/nfs/Attic/nfs_serv.c,v
 retrieving revision 1.93.2.4
 diff -u -r1.93.2.4 nfs_serv.c
 --- nfs_serv.c	5 Feb 2002 19:09:30 -0000	1.93.2.4
 +++ nfs_serv.c	21 Apr 2002 15:16:51 -0000
 @@ -2993,6 +2993,8 @@
  	cnt = fxdr_unsigned(int, *tl);
  	siz = ((cnt + DIRBLKSIZ - 1) & ~(DIRBLKSIZ - 1));
  	xfer = NFS_SRVMAXDATA(nfsd);
 +	if (cnt > xfer)
 +		cnt = xfer;
  	if (siz > xfer)
  		siz = xfer;
  	fullsiz = siz;
 @@ -3282,6 +3284,8 @@
  	off = toff;
  	siz = ((siz + DIRBLKSIZ - 1) & ~(DIRBLKSIZ - 1));
  	xfer = NFS_SRVMAXDATA(nfsd);
 +	if (cnt > xfer)
 +		cnt = xfer;
  	if (siz > xfer)
  		siz = xfer;
  	fullsiz = siz;
State-Changed-From-To: open->closed 
State-Changed-By: iedowse 
State-Changed-When: Sun Apr 21 09:15:32 PDT 2002 
State-Changed-Why:  
Submitter says this can be closed, as the readdirplus miscalculation 
bug was fixed some time ago. The patch I mentioned in the audit 
trail that fixes a related issue has been committed now too. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=37304 
>Unformatted:
