back to article 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 …

  1. thames

    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.

    1. Chemist

      "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)

      1. Anonymous Coward
        Anonymous Coward

        rpcbind and nfs

        rpcbind is not needed in NFSv4.

    2. Ole Juul

      Just checked and yes, it's running on my up-to-date FreeBSD 11.0-RELEASE NFS server.

  2. jake Silver badge

    Anyone actually use that ...

    ... on Internet facing hardware?

    rpcinfo -s will tell you if it's running, and which services if it is.

    1. julian.smith

      Re: Anyone actually use that ...

      Thank you for the useful command to check if it's running

      All good on:

      Release Linux Mint 18.1 Serena 64-bit

      Kernel Linux 4.4.0-53-generic x86_64

      MATE 1.16.1

    2. Martin Gregorie

      Re: Anyone actually use that ...

      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.

      1. fajensen

        Re: Anyone actually use that ...

        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.

        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)!

      2. jake Silver badge

        Re: Anyone actually use that ...

        Martin, if that is true on "stock" Fedora 25, then it is fundamentally broken from a network security point of view. I wonder what other things are that badly misconfigured ...

  3. timrichardson

    are you sure port 111 is open by default on AWS? Everytime I've made a new ubuntu server on AWS, no ports are open by default, not even port 80

    1. Ben Tasker

      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.

      1. Anonymous Coward
        Anonymous Coward

        Step 1: install firewall

        Step 2: allow ip any any

        Step 3: tick audit box to confirm firewall installed and configured

        Step 4: profit?

  4. Anonymous Coward

    Many eyes...

    But all looking at pr0n!

    1. HieronymusBloggs

      Re: Many eyes...

      "But all looking at pr0n!"

      That echo is going on for a long time.

  5. John Smith 19 Gold badge

    It seems no one likes writing data validation code

    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.

    1. hplasm

      Re: It seems no one likes writing data validation code

      "...protocol code should be written by an FSM writing tool. "

      All hail His Spaghetti Code!

      1. Anonymous Coward

        Once your intern has finished looking for the left handed USB stick

        And reported back that the stores cupboard has no stripy toner cartridges - set them to work validating the execution of the FSM-generated protocol line-by-line...

      2. John Smith 19 Gold badge

        "All hail His Spaghetti Code!"

        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.

  6. Lee D Silver badge

    Not being funny:

    What Linux distro does not start from the equivalent of:


    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.

  7. Chemist

    "f you really need to run rpcbind (which binds RPC calls to addresses), put it behind a firewall limiting Port 111 to the outside world."

    Does no-one scan their external address for any (inadvertently) exposed ports ?

  8. Nick Kew

    A more innocent age

    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.

  9. Doctor Syntax Silver badge

    Was running unneeded on Debian LTS so apt-get remove rpcbind.

  10. i1ya

    I have several servers on Hetzner

    ...and they nagged me with automated e-mails to close RPC ports more than year ago. So, no news.

    (yes, was on Debian LTS by default)

  11. ilmari

    I remember around 2002 or so Redhat 6.1 ... 6.2 came with portmapper by default on 111, probably the most common reason why machines got taken over back theb.

    Funny how little things have changed in 15 years.

  12. Anonymous Coward
    Anonymous Coward

    Another day, another Linux vulnerabiliy...

    Do the internet a favour - upgrade to windows

    1. dmacleo

      Re: Another day, another Linux vulnerabiliy...

      where rpc enabled by default and needed (iow required) for many things....

      active directory, mmc consoles, etc use it.

      less of an os issue than it is a firewall issue

  13. Kevin McMurtrie Silver badge


    Verified that it's running on all interfaces of MacOS 10.11.6. My ancient 10.6.8 server at home doesn't have it (or it already died).

    1. John Smith 19 Gold badge
      Big Brother

      "Verified that it's running on all interfaces of MacOS 10.11.6. "

      Double plus not good.

    2. jbuk1

      Re: Mac

      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.

      1. Ramazan

        Re: Mac

        "Firstly the BSD implementation will be different from Linux"




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

        1. jbuk1

          Re: Mac

          Cheers, I hadn't realised they shared the same code.

      2. Ramazan

        Re: Mac

        "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!

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

  14. jbuk1

    I've just checked a 10.12 machine at work with smb and afs sharing enabled and connected to windows domain.

    Sudo netstat -l shows no rpc service bound to any tcp/ip port.

    1. Ramazan

      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.

    2. Anonymous Coward
      Anonymous Coward

      Thank you. That's the one I can't check here. [I do recommend their machines, a lot!]

  15. NetScr1be

    Fixed in most versions of Debian

    Fixed in most versions of Debian

  16. NetScr1be

    How to check if RPCBIND is active on Debian

    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


    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* LISTEN 1736/rpcbind

    tcp6 0 0 :::111 :::* LISTEN 1736/rpcbind

    udp 0 0* 1736/rpcbind

    udp6 0 0 :::111 :::* 1736/rpcbind

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon