Reminder of why we don't suid root binaries that read/write to the filesystem. Disclaimer: This message is provided for educational purposes only and comes without a warranty of any kind. By using this information for any reason, you assume all risk and responsibility. Because nmap requires root privileges to do some of its cooler scans, (like OS fingerprinting) some administrators suid root the nmap binary to allow non-users, web front ends, etc to be able to utilize all the functionality. The nmap man page says: "Significant effort has been put into decent nmap performance for non-root users. Unfortunately, many critical kernel interfaces (such as raw sockets) require root privileges. nmap should be run as root whenever possible." Both of the exploits below are possible because nmap was not written with being suid in mind. nmap is NOT distributed suid and nmap's author, Fydor, does not recommend setting nmap suid. It is my belief however that a significant percentage of sysadmins have made nmap suid. Exploit #1: nmap with the -iL option (input target file) allows you to read any file. Because nmap does not drop root privileges before reading the target file, any file is accessible. nmap -iL /etc/shadow localhost Will print out the contents of the given file to STDERR. Note that in some cases, the entire line will not be printed (in the case of /etc/shadow, only up to the first '/'), however using a debugger like gdb makes reading the entire line always possible. Both nmap 2.53 and 2.54BETA7 on Red Hat Linux 2.6/2.2.17 and Solaris 2.6/2.7 have been tested and found vulnerable. I suspect all platforms are vulnerable, and all versions of nmap with the -iL are as well. Exploit #2: nmap with the -oN/-oM/-oG/-oX/-oS options allow appending/overwriting any file. Because nmap does not drop root privileges before writing to files, one has limited ability to format text to overwrite/append to files. Many kinds of expoits are potentially possible; one is given here to illustrate. The trick of course is to get nmap to write a valid entry into /etc/passwd. nmap allows the user to have some control over the output for open ports by pointing nmap to a custom nmap-services file. The nmap_fetchfile() function in nmap.c which is used to read the nmap-services file scans directories in the following order: $NMAPDIR/ ~user/nmap/ NMAPDATADIR/ ./ placing a custom nmap-services file in either of the first two locations will allow the user to override the defaults and exploit it. The following example illustrates this: export NMAPDIR=/home/user echo "smtp::0:0:root:/home/user:/bin/bash 25/tcp" >/home/user/nmap-services nmap --append_output -oN /etc/passwd localhost if port 25/tcp is open, you'll get the following line (among others) added to /etc/passwd 25/tcp open smtp::0:0:root:/home/user:/bin/bash As ugly as that looks, it turns out to be a valid login. On Red Hat Linux 6.2 you can: su - "25/tcp open smtp" Solaris 2.6/2.7's su won't work, but you can use ssh or similar methods: ssh -l "25/tcp open smtp" localhost Again, both 2.53 and 2.54BETA7 are vulnerable if suid. I expect all versions of nmap with the -oN (and possibly other output formats as well) are vulnerable as well. Tested on Red Hat Linux 6.2/2.2.17 and Solaris 2.6/2.7. Other platforms may be vulnerable if they allow long user names and user names with spaces and slashes. Solution: Both of these problems can be solved by removing the suid bit from the nmap binary. If you're using nmap for a web front end, you should use a suid wrapper which prevents the use of -iL/-oN/-oM/-oG/-oX/-oS (which aren't required for a web front end anyways). I can't recommend using something like sudo to give 'trusted users' access to nmap. You might as well just give them the root password instead. Thanks to Roger Dingledine for pointing out that "25/tcp open smtp" might be a gross yet perfectly valid user name. Regards, Aaron Turner Gabe Rocha June 7, 2001