Bug 219066

Summary: rpcbind rpcbomb
Product: Base System Reporter: lampa
Component: kernAssignee: Xin LI <delphij>
Status: Closed FIXED    
Severity: Affects Many People CC: cem, delphij, des, lampa
Priority: ---    
Version: 10.3-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
patch for usr.sbin/rpcbind none

Description lampa 2017-05-04 12:36:18 UTC
See http://seclists.org/oss-sec/2017/q2/209

FreeBSD rpcbind seems to be vulnerable too:

# ruby rpcbomb.rb localhost 100000000

     r p c b o m b

     DoS exploit for *nix rpcbind/libtirpc.

     (c) 2017 Guido Vranken.

     https://guidovranken.wordpress.com/

Allocated 100000000 bytes at host localhost:111.

Damn it feels good to be a gangster.
Comment 1 lampa 2017-05-05 09:33:42 UTC
All usr.sbin/rpcbind, libc/rpc and kernel sys/rpc are affected. 

usr.sbin/rpcbind can be patched from https://github.com/guidovranken/rpcbomb/rpcbind_patch.txt

libc/rpc and sys/rpc can be probably patched more or less directly from https://github.com/guidovranken/rpcbomb/libtirpc_patch.txt
Comment 2 Dag-Erling Smørgrav freebsd_committer 2017-05-05 12:03:41 UTC
I'd like to point out that the output from rpcbomb.rb proves nothing.  It always prints the exact same message, unless it manages to cause rpcbind to crash, in which case it prints "No response from server received." instead; but rpcbind will not crash and will continue to answer the requests you really care about (GETPORT, mostly).  The target host will not crash either, because rpcbomb only fills up the target process's address space, not the host's physical memory or swap.  My tests resulted in rpcbind growing to 128 TB but otherwise functioning normally.  I was unable to provoke a similar bug in nfsd (with a carefully crafted LOOKUP request), but I didn't try very hard, and it would have been very slow.

Also, the rpcbind patch is purely cosmetic.  It sets an upper bound on the amount of memory libtirpc will leak, so it slows down the attack but does not prevent it (as long as the attacker adjusts numBytes so the packet isn't rejected until after the memory has been allocated).  The other patch is mostly just more of the same; the only part you really need is the xdr.c bit, with a few improvements.
Comment 3 lampa 2017-05-12 08:31:23 UTC
So maybe this is the right direction?
https://www.spinics.net/lists/linux-nfs/msg63669.html

rpcbind doesn't call svc_freeargs() in the case of svc_getargs() failure,
so buffer for string is not released.
Comment 4 lampa 2017-05-12 08:38:15 UTC
And another conclusion:
https://access.redhat.com/solutions/3025811/
Comment 5 lampa 2017-05-12 09:10:52 UTC
Created attachment 182540 [details]
patch for usr.sbin/rpcbind
Comment 6 lampa 2017-05-12 09:17:20 UTC
I can confirm, that with this patch rpcbind VM size doesn't increase after rpcbomb.

The other files (pmap_svc.c, rpcb_svc_com.c) that are patched in the Linux case, are probably not required to patch at all, as their rpc arguments are not allocated and cannot leak.
Comment 7 Xin LI freebsd_committer 2019-11-30 06:23:15 UTC
Fixed in r319369.