108575 2003-07-30  18:52  /60 rader/ Stephen Clowater <steve@stevesworld.hopto.org>
Importerad: 2003-07-30  18:52  av Brevbäraren
Extern mottagare: Jared Stanbrough <jareds@pdx.edu>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <5794>
Kommentar till text 108538 av Jared Stanbrough <jareds@pdx.edu>
Ärende: Re: Remote Linux Kernel < 2.4.21 DoS in XDR routine.
------------------------------------------------------------
What does one need for this attack to work?

Can it only be launched by people in the exports ? Or can it be
launched by anyone?

Thanks

Steve
----- Original Message ----- 
From: "Jared Stanbrough" <jareds@pdx.edu>
To: <bugtraq@securityfocus.com>
Sent: Tuesday, July 29, 2003 4:55 PM
Subject: Remote Linux Kernel < 2.4.21 DoS in XDR routine.


>
> Hello all,
>
> 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.
>
> The bug is in the decode_fh routine of fs/nfsd/nfs3xdr.c under the kernel
> source tree.
>
> Vulnerable code:
>
> static inline u32 *
> decode_fh(u32 *p, struct svc_fh *fhp)
> {
>         int size;
>         fh_init(fhp, NFS3_FHSIZE);
>         size = ntohl(*p++);
>         if (size > NFS3_FHSIZE)
>                 return NULL;
>
>         memcpy(&fhp->fh_handle.fh_base, p, size);
>         fhp->fh_handle.fh_size = size;
>         return p + XDR_QUADLEN(size);
> }
>
> Where p is a packet of attacker controlled XDR data. If size is made to be
> negative, the sanity check is passed and the malicious value is passed to
> memcpy. Due to the behavior of the kernel's memcpy, this will cause a very
> large copy in kernel space, resulting in an instant kernel panic.
>
> The attached code is a POC of this vulnerability. It requires that the
> vulnerable host has an exported directory available to the attacker. This
> is probably not the only way to manifest this bug, however.
>
> If you have any questions, please feel free to contact me.
>
> Cheers,
>
> Jared Stanbrough <jareds@pdx.edu>
>
(108575) /Stephen Clowater <steve@stevesworld.hopto.org>/(Ombruten)
Kommentar i text 108591 av Jared Stanbrough <jareds@pdx.edu>
108591 2003-07-30  20:42  /75 rader/ Jared Stanbrough <jareds@pdx.edu>
Importerad: 2003-07-30  20:42  av Brevbäraren
Extern mottagare: Stephen Clowater <steve@stevesworld.hopto.org>
Mottagare: Bugtraq (import) <5810>
Kommentar till text 108575 av Stephen Clowater <steve@stevesworld.hopto.org>
Ärende: Re: Remote Linux Kernel < 2.4.21 DoS in XDR routine.
------------------------------------------------------------
Steve,

The attached code requires that an export has been previously mounted
onto the attacker's machine. I haven't done much testing to determine
whether or not it is vulnerable before authentication takes
place. Since the procedures which operate on file handles are only
called after a client is authenticated, I believe that only people in
the exports can trigger it.  If anyone can trigger it otherwise I'd
like to hear, though...

--jared

On Tue, 29 Jul 2003, Stephen Clowater wrote:

> What does one need for this attack to work?
>
> Can it only be launched by people in the exports ? Or can it be launched by
> anyone?
>
> Thanks
>
> Steve
> ----- Original Message -----
> From: "Jared Stanbrough" <jareds@pdx.edu>
> To: <bugtraq@securityfocus.com>
> Sent: Tuesday, July 29, 2003 4:55 PM
> Subject: Remote Linux Kernel < 2.4.21 DoS in XDR routine.
>
>
> >
> > Hello all,
> >
> > 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.
> >
> > The bug is in the decode_fh routine of fs/nfsd/nfs3xdr.c under the kernel
> > source tree.
> >
> > Vulnerable code:
> >
> > static inline u32 *
> > decode_fh(u32 *p, struct svc_fh *fhp)
> > {
> >         int size;
> >         fh_init(fhp, NFS3_FHSIZE);
> >         size = ntohl(*p++);
> >         if (size > NFS3_FHSIZE)
> >                 return NULL;
> >
> >         memcpy(&fhp->fh_handle.fh_base, p, size);
> >         fhp->fh_handle.fh_size = size;
> >         return p + XDR_QUADLEN(size);
> > }
> >
> > Where p is a packet of attacker controlled XDR data. If size is made to be
> > negative, the sanity check is passed and the malicious value is passed to
> > memcpy. Due to the behavior of the kernel's memcpy, this will cause a very
> > large copy in kernel space, resulting in an instant kernel panic.
> >
> > The attached code is a POC of this vulnerability. It requires that the
> > vulnerable host has an exported directory available to the attacker. This
> > is probably not the only way to manifest this bug, however.
> >
> > If you have any questions, please feel free to contact me.
> >
> > Cheers,
> >
> > Jared Stanbrough <jareds@pdx.edu>
> >
>
>
>
(108591) /Jared Stanbrough <jareds@pdx.edu>/(Ombruten)