Re: Possible security issue with mktemp in Zenmap

[Patrick Donnelly <batrick () batbytes com>]

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/