bugtraq - Re: Remote Linux Kernel < 2.4.21 DoS in XDR routine.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <003301c35627$c3ed7be0$0201a8c0@stephenjfrss85>
Date: Tue, 29 Jul 2003 20:18:48 -0300
From: "Stephen Clowater" <steve@...vesworld.hopto.org>
To: "Jared Stanbrough" <jareds@....edu>, <bugtraq@...urityfocus.com>
Subject: 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@....edu>
To: <bugtraq@...urityfocus.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@....edu>
>