Nmap Development mailing list archives
Re: Possible security issue with mktemp in Zenmap
From: Patrick Donnelly <batrick () batbytes com>
Date: Wed, 2 Apr 2014 15:04:49 -0400
On Wed, Apr 2, 2014 at 12:54 PM, Daniel Miller <bonsaiviking () gmail com> wrote:
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.
I'm not looking into detail how Python does this but mktemp/tmpnam warnings are really annoying IMO (looking at you gcc). So long as Zenmap is opening the file with O_EXCL, there is no problem here.
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.
This does not solve the race condition, it just makes the window smaller.
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 people actually still do this I'd go so far as to say we should make Nmap cowardly refuse to run if the setuid bit is set on the executable. Nmap is not hardened for this type of use. -- Patrick Donnelly _______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Possible security issue with mktemp in Zenmap Daniel Miller (Apr 02)
- Re: Possible security issue with mktemp in Zenmap Patrick Donnelly (Apr 02)