You only need 60 bytes to hose Linux's 
rpcbind A 60 byte payload sent to a UDP socket to the rpcbind service can crash its host by filling up the target's memory. Guido Vranken, who discovered the vuln and created the “Rpcbomb” exploit, complains that he couldn't get action from the package maintainers, so he's written patches himself. He writes that Shodan turned up 1.8 …
Before panicking, check to see that it's even installed. I just checked my PC (Ubuntu 16.04 desktop), and it's not installed by default.
I've not had anything to do with "rpcbind" myself, but from what little I've seen about it, it appears to be mainly used with NFS servers.
According to the on-line man pages, it seems to originally be a BSD program which was ported to Linux in the very early days. Given that, it's quite possible that this may affect any version of BSD or Apple Mac OSX as well.
"it appears to be mainly used with NFS servers."
It is, both my NFS servers have it open but they are internal.
( The only ports I have exposed externally (via port forwarding) are ssh on unusual port numbers, with unusual user names ( just the one limited user on each machine) and certificates)
rpcbind is disabled by default for Fedora 25, but running "rpcinfo -s" locally or "rpcinfo -s hostname" remotely both start it. So, remember to run "sudo systemctl stop rpcbind" to stop it again if you don't need it running.
However, you'll find that running "sudo systemctl stop rpcbind" outputs this: "Warning: Stopping rpcbind.service, but it can still be activated by: rpcbind.socket" so it follows that stopping rpcbind may not do all that much good. I've just found out that running nmap from another host on your LAN can start it, i.e. any process that tries to open port 111 for any reason has the side effect of starting rpcbind if its not already running.
If, like me, your router doesn't accept any inbound connections then you should be safe, though you may still want to block port 111 on your hosts' firewalls.
e. any process that tries to open port 111 for any reason has the side effect of starting rpcbind if its not already running.
You should probably check that some incarnation of "inetd" is not enabled / running and configured to run "rcpbind". Most installations do not need "intetd" functionality, today I believe that dedicated daemons for each service are preferred.
https://en.wikipedia.org/wiki/Inetd
Of Course:
systemd supports inetd services, and expands socket activation beyond IP messaging (AF INET+6) to include AF UNIX, AF NETLINK and more.[2][3]
The Blob has sucked in fossil stuff and made it come Alive (and Un-installable)!
You'll quite often find (particularly with AMI's others have built) that there's all sorts of crap listening, but that the Security Policy is locked down by default (so you have to go and permit the ports/protos in AWS).
Which is all well and good until some tosser sets up and Allow All from Everywhere without thinking about it.
So yet another piece of software can get hosed fairly easily.
I really do think a lot of protocol code should be written by an FSM writing tool. Yes some protocols are too complex to accommodate inside one but most are not and you can check for obvious mistakes.
As it happens I worked for a company that had a SW package written for them by an outside SW house.
PHB had the choice of the model their CASE tool used (expensive) or the code it generated (cheap)
PHB bought the generated code. I had to help maintain it.
So I know how s**t generated code can be.
OTOH Lex and Flex also implement FSM (what did you think an "automaton" was?) for the "symbol" recognition process. People seem OK with using them. something to do with using a table based designed with the code actually being an interpreter that decided what the next state the program should be in. PITA to write for humans, but quite easy to generate in SW.
Maybe because they don't do lots of goto's but rely on a state table design?
You post is funny because it's often true, which is why I upvoted it. when they are done right FSM's can provide clarity, as long as you retain the model of course.
Not being funny:
What Linux distro does not start from the equivalent of:
ACCEPT RELATED, ESTABLISHED
ACCEPT ssh <-- possibly!
DENY all
as default rule on iptables?
Even ufw has defaults that basically correspond to the same.
Who is installing rpcbind, opening it to the world in the configuration and then again in the firewall? Because, pretty much, the package maintainer ought to be shot if they are adding firewall rules, and the firewall package people who ought to be shot if they're allowing rpcbind to the world by default.
I recollect using RPC in an application I once wrote. It gave me for free an architecture that decoupled client and server, so my users could run a utility on their own desktop that would order something from the server.
This was before the WWW. And before Linux. It was not before X11 had brought us the networked desktop, but it was still the era when X11 was so painfully slow that few used it, and among those who did, running unexpected things on random colleagues' desktops was a jolly prank.
By the time we got the Web in the mid-90s, security advice was clear. RPC services should be firmly firewalled off from anything facing the outside world. With discs reaching gigabyte sizes, the need for widespread NFS was rapidly receding, and RPC relegated to a greybeard niche.
Firstly the BSD implementation will be different from Linux so it's unlikely the same bug is present.
Secondly OSX has the firewall on by default and I suspect (and will confirm later) that rpcbind is not exposed through the firewall unless you enable sharing of NFS from the sharing control panel so none issue.
Personally I use PF on mine with a very tight firewall rule set.
"Firstly the BSD implementation will be different from Linux"
nope:
http://metadata.ftp-master.debian.org/changelogs/main/r/rpcbind/rpcbind_0.2.1-6+deb8u1_copyright
...
/*-
* Copyright (c) 2000 The NetBSD Foundation, Inc.
* All rights reserved.
*
* This code is derived from software contributed to The NetBSD Foundation
* by Frank van der Linden.
"Secondly OSX has the firewall on by default"
I never saw such a thing as "the firewall on by default" in the Linux world. Well, except for openwrt/dd-wrt "distro"s. For example, Debian installation nowadays is streamlined and simple and user is presented "tasksel" choices like "Debian desktop environment" varieties, "ssh server", "print server" etc but there's no way to enable a firewall in this installation "wizard" ("Debian Installer" is its name BTW). So after this user-friendly installation process is finished the very first thing to do is to setup some firewall rules (mine live in /etc/network/interfaces in the "lo" interface section), and most ordinary users wouldn't know where to start (run apt-get search firewall and see for yourself).
My opinion on the subject is this: if you put an effort into making your Linux distro accessible by ordinary users, then some "firewalling" must be included and turned on by default.
P.S. even on Ubuntu, FFS!
https://help.ubuntu.com/16.04/ubuntu-help/net-firewall-on-off.html
"Ubuntu comes equipped with the Uncomplicated Firewall (ufw) but the firewall is not enabled by default. Because Ubuntu does not have any open network services (except for basic network infrastructure) in the default installation, a firewall is not needed to block incoming attempted malicious connections."
On Debian the "rpcbind" package is required by NFS server[s], NFS client, NIS, BSD automounter, and some other marginal utils. I consider BSD automounter and NIS as marginal too, so the only real problem is NFS (both client and server). Most sysadmins know that NFS is fundamentally insecure so some firewalling or LAN-only exposition is expected to be present though.
Must be easy to write these scare-mongering articles and not provide any practical information or do any reader service.
The article doesn't even provide;
the vulnerability ID: CVE-2017-8779
Source: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8779
Is it running?
sudo rpcinfo -s
program version(s) netid(s) service owner
100000 2,3,4 local,udp,tcp,udp6,tcp6 portmapper superuser
100024 1 tcp6,udp6,tcp,udp status 106
What version is installed?
sudo apt-cache showpkg rpcbind
What versions are fixed in Debian? (Most of them)
Is it really on port 111? (Also shows protocols)
sudo netstat -tulpn | grep 111
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1736/rpcbind
tcp6 0 0 :::111 :::* LISTEN 1736/rpcbind
udp 0 0 0.0.0.0:111 0.0.0.0:* 1736/rpcbind
udp6 0 0 :::111 :::* 1736/rpcbind
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
