Possible security issue with mktemp in Zenmap

[Daniel Miller <bonsaiviking () gmail com>]

List,

Zenmap currently uses Python's tempfile.mktemp function 
(https://docs.python.org/2/library/tempfile.html#tempfile.mktemp) to get 
a filename to pass to nmap's -oX option. There is a race condition here 
where an attacker could observe or guess the filename after it is 
generated but before it is created (not sure how this would be done) and 
create the file as a symlink to some other file to which they do not 
have access. Nmap's XML output would then go into the destination of the 
symlink, possibly leading to a security problem.

As a solution, Python's tempfile module offers several replacements for 
mktemp that open the file immediately, preventing the race condition. 
This would not work to pass to the Nmap command, since the open file 
handle can't be passed on the command line, however. We could use the 
special "-" filename to send output to stdout, which can be grabbed via 
the subprocess.Popen call, but then we can't get the normal text from 
stdout.

We could do more existence checking in Nmap itself, and unlink 
destination files before opening them, which would remove the previous 
file (possibly symlink) and create a new one instead of just truncating 
the old one. I'm not sure of the security implications here, either.

In general, this is another reason why installing Nmap setuid is a bad 
idea: regardless of the mktemp issue, a user could use Nmap to clobber 
any file on the system with the output arguments.

If Nmap is not setuid, then there's a similar race condition if the root 
user runs Nmap and instructs it to output results to a world-writable 
directory (like /tmp, which is the problem with the Zenmap mktemp 
issue), because an unprivileged user can observe the filename in the 
process listing before Nmap opens the file, and can therefore win the race.

In conclusion, I don't know if this is a problem, and I have no 
solutions. :(

Dan
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/