Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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 ... 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 '11 at 14:41

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.

share|improve this answer
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 '11 at 10:34
Probably to appease anti-virus vendors. – LawrenceC Feb 19 '11 at 10:54

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

share|improve this answer
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 '11 at 14:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.