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-FILESThere 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/
Current thread:
- Re: ncat - UNIX-domain sockets support Tomas Hozza (Oct 04)
- Re: ncat - UNIX-domain sockets support Tomas Hozza (Oct 15)
- Re: ncat - UNIX-domain sockets support David Fifield (Nov 08)
- Re: ncat - UNIX-domain sockets support David Fifield (Nov 08)
- Re: ncat - UNIX-domain sockets support Tomas Hozza (Nov 12)
- Re: ncat - UNIX-domain sockets support David Fifield (Nov 12)
- Re: ncat - UNIX-domain sockets support Tomas Hozza (Nov 13)
- Re: ncat - UNIX-domain sockets support David Fifield (Nov 20)
- Re: ncat - UNIX-domain sockets support Tomas Hozza (Nov 21)
- Re: ncat - UNIX-domain sockets support David Fifield (Nov 21)
- Re: ncat - UNIX-domain sockets support Tomas Hozza (Nov 26)
- Re: ncat - UNIX-domain sockets support David Fifield (Nov 27)
- Re: ncat - UNIX-domain sockets support Tomas Hozza (Nov 28)
- Re: ncat - UNIX-domain sockets support David Fifield (Nov 28)
- Re: ncat - UNIX-domain sockets support Tomas Hozza (Nov 12)