netdev - Re: [Bugme-new] [Bug 8891] New: in-kernel rpc generates broken RPCBPROC

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-next>] [day] [month] [year] [list]
Date:	Wed, 15 Aug 2007 12:29:09 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	netdev@...r.kernel.org, nfs@...ts.sourceforge.net
Cc:	"bugme-daemon@...zilla.kernel.org" <bugme-daemon@...zilla.kernel.org>,
	speidel@...erschuss.de
Subject: Re: [Bugme-new] [Bug 8891] New: in-kernel rpc generates broken
 RPCBPROC_GETVERSADDR v4 requests

On Wed, 15 Aug 2007 12:22:51 -0700 (PDT)
bugme-daemon@...zilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=8891
> 
>            Summary: in-kernel rpc generates broken RPCBPROC_GETVERSADDR v4
>                     requests
>            Product: Networking
>            Version: 2.5
>      KernelVersion: 2.6.22.1
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Other
>         AssignedTo: acme@...stprotocols.net
>         ReportedBy: speidel@...erschuss.de
> 
> 
> Most recent kernel where this bug did not occur: 2.6.20

Apparently a regression.

> Distribution: Fedora Core 6
> Hardware Environment: x86_64
> Software Environment: NFS
> Problem Description: When locking a file, an invalid RPCBPROC_GETVERSADDR
> procedure call is sent out
> 
> Steps to reproduce:
> on the NFS server, run: tcpdump -xX -pni eth0 -s0 port 111 and src host
> theNFSclient
> on a client running 2.6.22.1, run: flock -x /nfsmount/somefile ls
> tcpdump will show:
> 
> 17:10:01.290655 IP 141.2.15.141.34572 > 141.2.1.1.sunrpc: P 0:168(168) ack 1
> win 183 <nop,nop,timestamp 966695 115079499>
>         0x0000:  4500 00dc 53ad 4000 3f06 bcdc 8d02 0f8d  E...S.@.........
>                 0x0010:  8d02 0101 870c 006f cdcd 938d db00 c8a7 
> .......o........
>         0x0020:  8018 00b7 e59d 0000 0101 080a 000e c027  ...............'
>         0x0030:  06db f94b 8000 00a4 fd48 2a07 0000 0000  ...K.....H*.....
>         0x0040:  0000 0002 0001 86a0 0000 0004 0000 0009  ................
>         0x0050:  0000 0001 0000 0054 0000 03c6 0000 0007  .......T........
>         0x0060:  6572 6964 796b 6500 0000 0000 0000 0000  eridyke.........
>         0x0070:  0000 000e 0000 0000 0000 0001 0000 0002  ................
>         0x0080:  0000 0003 0000 0004 0000 0005 0000 0006  ................
>         0x0090:  0000 0007 0000 0007 0000 0009 0000 000a  ................
>         0x00a0:  0000 000c 0000 0014 0000 001c 0000 0000  ................
>         0x00b0:  0000 0000 0001 86b5 0000 0004 0000 0003  ................
>         0x00c0:  7463 7000 0000 0009 3134 312e 322e 312e  tcp.....141.2.1.
>         0x00d0:  3100 0000 0000 0004 7270 6362            1.......rpcb
> 
> Note the "141.2.1.1" in the output.
> 
> According to RFC 1833, you can read here the following fields:
> 
> RPCBPROC_GETVERSADDR version 4 procedure is being called
> r_prog == 0x000186b5 == 100021 == nfs.lockd
> r_vers == 4
> r_netid == (length 3) "tcp"
> r_addr == (length 9) "141.2.1.1"
> r_owner == (length 4) "rpcb"
> 
> This r_addr member is supposed to contain an universal address. Although I have
> no source for that, the RFC clearly says a service can listen to an address,
> and RPCBPROC_GETVERSADDR is supposed to return an universal address too. From
> this I can conclude that an universal address is supposed to contain the port
> number, and other operating systems are using the format
> a.b.c.d.PortHighByte.PortLowByte (like in FTP, but with . instead of ,). I
> interpret the RFC 1833 so that the port number of the rpcbind, that is, 111, is
> to be appended, so the correct value of r_addr would be "141.2.1.1.0.111". This
> matches other implementations.
> 
> Of course, all this does sound like nitpicking, and as the callee is not even
> supposed to look at the port number (this argument is only there so the callee
> can decide correctly which interface address to use for the response). However,
> this omission triggers an apparently unpatched denial of service vulnerability
> against HP-UX 11.11's rpcbind and causes it to quit with a core dump and a bus
> error. When using a correctly formed universal address, or the empty string,
> there is no crash of HP-UX's rpcbind.
> 
> And of course it is HP who has to fix the DoS bug - but Linux 2.6.22 triggers
> it by a RFC violation, which is a minor bug to be fixed on Linux's side. By the
> way, does anyone have the right contacts to HP to report this bug? I do not
> have a HP service contract any more, and the only other support place I found
> is their public forum, where I of course can only provide limited information
> about the bug (basically, the same I am posting here).
> 
> Maybe the bug is fixed in a more current kernel, I was only using Fedora's
> highly patched distribution kernel and compared it to the sources of the base
> version in the main tree, where I see the very same problem in the source code.
> So I do not think it was Fedora who caused the problem, and am assigning it to
> mainline.
> 

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html