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:
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
a new patch (you can base it on your old patch) adding support for
automatic creation? The only thing is that we shouldn't use a
"/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.
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
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
in the ncat_connect callbacks?
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/