Re: ncat - UNIX-domain sockets support

[David Fifield <david () bamsoftware com>]

On Wed, Nov 21, 2012 at 03:18:52AM -0500, Tomas Hozza wrote:
> Hi David.
>
> I basically reverted your commit which removed the automatic 
> generation of name for temporary source socket, test from 
> ncat-test.pl and changed documentation (ncat.xml). 
>
> ----- Original Message -----
> > I agree now that Ncat should do something compatible. Would you
> > produce
> > a new patch (you can base it on your old patch) adding support for
> > this
> > automatic creation? The only thing is that we shouldn't use a
> > hardcoded
> > "/tmp". This page has a code example that reads the TMPDIR and TMP
> > environment variables in addition to using mkstemp:
>
> I used tempnam() function which uses TMPDIR and TMP, so "/tmp" is not
> hardcoded. It was done so also in the last bunch of patches.
>
> > http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html#TEMPORARY-FILES
>
> There is example of how to use tempnam function to be more safe,
> but unfortunately this can not be used in this case. The problem is
> that after the temporary name is generated, we are not opening/creating
> any file/socket. It is done later when calling bind() on the source socket FD
> together with the temporary name (so the socket binds to the path/name).

This is the way I was thinking before too. But netcat-openbsd calls
mkstemp, at least if I understand correctly. Apparently it is no problem
for the file to exist as a regular file before binding to it? If so,
then that is what we should do. I want to avoid a race condition like
the following:
 1. tempnam generates a nonexistent name in /tmp.
 2. Attacker guesses the name and puts something there.
 3. Ncat binds to the file name.
 4. Ncat calls unlink on the attacker-controlled file name.
Offhand I can't think of what harm an attacker can do with such an
unlink, but since the implications are unknown, it's better to be safe.

Please correct me if I misunderstand something.

I'd also like to be sure to unlink the socket even if there is an error.
Would you check if it's possible to replace
        exit(1);
with
        nsock_loop_quit(nsp);
        return;
in the ncat_connect callbacks?

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/