UPDATE: A CVE number has been assigned, it’s: CVE-2017-8779.
This vulnerability allows an attacker to allocate any amount of bytes (up to 4 gigabytes per attack) on a remote rpcbind host, and the memory is never freed unless the process crashes or the administrator halts or restarts the rpcbind service.
Attacking a system is trivial; a single attack consists of sending a specially crafted payload of around 60 bytes through a UDP socket.
This can slow down the system’s operations significantly or prevent other services (such as a web server) from spawning processes entirely.
This vulnerability may also be conducive in exploiting unrelated software running on the target system; there is a class of bugs that become exploitable (using uninitialized buffers, double frees, out-of-bounds writes, what have you) when there is insufficient memory; a call to malloc() fails and the software starts behaving in a way that was not foreseen. Resource shortage is an otherwise rare situation, so a lot of software is not equipped to safely deal with this situation.
It might not be easy to turn this constellation of factors into a practical exploit, but this class of bugs is a real thing, and it is the reason why a project like OpenSSL is now simulating allocation failures in their fuzzing framework, while applications like Tor will immediately terminate upon an allocation failure.
Suffice it to say that this is a potentially severe vulnerability.
I’ve developed a fix for this bug. This involves patching both rpcbind and libtirpc. I’ve been in touch with the maintainer of both packages but communication is slow so I’ve decided to go ahead and publish my findings. I see no reason to withhold them any longer because I’m including the remedy which distributions can consume and push to their users. You are encouraged to verify the correctness of the patches yourself before merging.
Exploit and patches can be found here: https://github.com/guidovranken/rpcbomb
Shodan reports 1.8 million hosts serving on port 111 (rpcbind). Many of those appear to be Amazon AWS instances and other mass hosting services where the owner is presumably using their default Linux distribution configuration that leaves rpcbind open to the internet. I assume there’s also a large amount of rpcbind services running behind internet firewalls (so they go undetected by Shodan) but accessible via their local networks or within a VPN.
Patch today or better yet, unless you really need it, remove the rpcbind service entirely from your system. If you really need it, it might be wise to apply some access limitation to port 111 in your firewall. I’ve scrutinized rpcbind and libtirpc to the best of my ability, but it is possible that this old software still hides vulnerabilities of equal or even greater severity.
A question to my readers
With regards to the class of vulnerabilities mentioned earlier, where resource shortage can lead to, I’d like to ask my dear readers a question: should memory-corrupting or memory-divulging bugs, which only exist under memory shortage that is non-trivial (assume a failure to allocate a couple of hundred kilobytes or more is the lower bound required to trigger the bug), be taken seriously and treated as proper vulnerabilities? The reason I’m asking this is because instances of this class of bugs are usually met with some ambivalence; let’s make a fix because who knows, and bury it in the endless stream of other nondescript commits, and let’s not issue an advisory because the prerequisites are outlandish. Failing to allocate 500 kilobytes on systems that are not a Commodore 64 is unusual, but obviously and inevitably there is a limit to the free memory that can be consumed. The amount of memory that is free at any given moment is largely outside the software’s purview; ultimately, memory is a shared and limited resource, and every concurrent process can affect the others’ stability.
Actual exploit development is not my forte nor my objective, so I’ve put up this survey to collect the opinions of those who are perhaps better versed in this area.
Take into account the fact that some systems like embedded devices operate in a state (default memory consumption, upper bound of memory consumption, processes running at any given moment) that is more or less known to the attacker, which may benefit the precision and reliability of an exploit.
I will post the results of this survey!
Guido Vranken 