Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: ncat - UNIX-domain sockets support
From: David Fifield <david () bamsoftware com>
Date: Wed, 21 Nov 2012 09:57:30 -0800

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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault