Bug 219066 - rpcbind rpcbomb
Summary: rpcbind rpcbomb
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.3-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: Xin LI
Depends on:
Reported: 2017-05-04 12:36 UTC by lampa
Modified: 2019-11-30 06:23 UTC (History)
4 users (show)

See Also:

patch for usr.sbin/rpcbind (783 bytes, patch)
2017-05-12 09:10 UTC, lampa
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.


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?

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:
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.