Why does the BSD version 1.10 of nc disable the -e option found in other, so-called insecure distributions when the same dangerous feature could be trivially achieved as follows even with the 'secure' version of nc:

$ # Machine A
$ mkfifo pipe
$ nc -l 4000 <pipe | bash >pipe

$ # Machine B
$ nc MachineA 4000

Now, if I were to wrap-up the incantation on Machine A in a script (that, if passed a `-e' argument, effectively does the above), I have essentially introduced the 'gaping security hole' without having to step down to the Makefile and build level.

So, why go to the extent of #define-ing GAPING_SECURITY_HOME in netcat.c?

  • 1
    Sorry to be so dumb, but I don't understand the security problem here. It seems like you'd have to say: nc -e /bin/bash ... or similar on machine A in order to make machine A vulnerable. Well if I choose to do so then that's my silly fault, but perhaps I want it for something like: nc -e knockknockwhosthere.sh ... to create a perfectly harmless server. Disabling suchlike just seems like banning microwave ovens so people don't try to dry their pets in them. Or have I missed something?
    – user100575
    Nov 10, 2011 at 14:41

3 Answers 3


While I've no definitive answer, I believe the gaping security hole is only present if your nc has -e enabled and is setuid root. (As nc is often used to bind to ports, it might be packaged setuid root to enable all users to bind on the privileged ports below 1024.)

In that situation, nc -e would exec the given process as root - which means it would let any user run any process as root. I'm sure you'll recognise that this is a gaping security hole. By contrast, if you run your own process and use pipes to connect it to nc, that process does not run as root unless you have some other way to elevate it (like sudo access).

As grawity pointed out, netcat's original release announcement complained that

the commercial vendors would have likely packaged [netcat] setuid root and with -DGAPING_SECURITY_HOLE turned on but not documented.

This lends weight to my theory, I think. :)


from the original release announcement:

Obligatory vendor-bash: If "nc" had become a standard utility years ago, the commercial vendors would have likely packaged it setuid root and with -DGAPING_SECURITY_HOLE turned on but not documented. It is hoped that netcat will aid people in finding and fixing the no-brainer holes of this sort that keep appearing, by allowing easier experimentation with the "bare metal" of the network layer.

Not that it makes anything clearer...

  • 1
    That doesn't appear to be a very good argument because the security hole is by all means there even in the supposedly secure version of nc with that piece of code disabled. It thus gives a false sense of security to new users. A better strategy, IMO, would be to warn loud and clear in the man page that, hey, this program is very dangerous and, so, you may or may not want to give everybody access to it. (Or, something to that effect.)
    – Harry
    Feb 19, 2011 at 14:48

I can use "netcat -e" to run other application, for example imap or pop3. section "#ifdef GAPING_SECURITY_HOLE" may contain a bug that allows you to run a shell, which is why it's ifdefed out by default. ifdef wraping security-critical section.

  • 1
    My executable is called nc; it came with Fedora12 (nc-1.84-21.fc12.i686), and does not have the -e option. Some distributions do but this one does not. And the 'justification' for this absence is covered in places like this one for example. My question is about the distributions that disable -e. As I argued above, even in such, so-called safe versions, you have the security hole anyway... so why not as well provide -e and make it a tad easier for the ethical hacker and the power user.
    – Harry
    Feb 19, 2011 at 10:34
  • Probably to appease anti-virus vendors.
    – LawrenceC
    Feb 19, 2011 at 10:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .