netcat -e, the GAPING_SECURITY_HOLE. But, really?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I posted my question earlier here, ,
but did not get any satisfying responses.

Would security experts on this group like to take a stab at this
newbie question of mine and share any enlightening insights?

Many thanks in advance,

Re: netcat -e, the GAPING_SECURITY_HOLE. But, really?


Quoted text here. Click to load it

First insight: If it's too much trouble for you to tell us your
question in the body of your message, it's probably too much trouble
for us to read it.

I strongly suggest that you read ESR's essay on asking questions in
technical forums, at

Re: netcat -e, the GAPING_SECURITY_HOLE. But, really?

I didn't realize it would be a problem. The reason I posted the link becaus=
e the original link also has comments by other folks, which I thought membe=
rs on this forum would like to read in context. Anyway, I'm including the q=
uestion body inline now. Please reply... and don't be sarcastic this time, =


Why does the BSD version 1.10 of `nc` disable the `-e` option found in othe=
r, so-called insecure distributions when the same dangerous feature could b=
e 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, i=
f passed a `-e` argument, effectively does the above), I have essentially i=
ntroduced the 'gaping security hole' without having to step down to the Mak=
efile and build level.

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


Site Timeline