Security – netcat -e: the GAPING_SECURITY_HOLE

bsdnetcatSecurity

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?

Best Answer

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

Related Topic