install.iss.txt

`Date: Sat, 20 Feb 1999 20:59:23 -0500  
From: Fyodor <[email protected]>  
To: [email protected]  
Subject: ISS install.iss security hole  
  
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.  
  
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.  
  
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/  
  
--  
Fyodor 'finger [email protected] | pgp -fka'  
"Girls are different from hacking. You can't just brute force them if all  
else fails." --SKiMo, quoted in _Underground_ (good book)  
  
-------------------------------------------------------------------  
  
Date: Mon, 22 Feb 1999 20:01:35 +0000  
From: Michael Warfield <[email protected]>  
To: [email protected]  
Subject: Re: ISS install.iss security hole  
  
All...  
  
I would like to thank everyone for bringing this to our attention.  
I would also like to reiterate that trouble reports on ISS products should  
be sent to [email protected] for prompt attention.  
  
Fyodor enscribed thusly:  
> 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  
  
Yup... You are right... That's a problem.  
  
That's the superuser courtesy check. Some customers had complained  
that the product would install but then wouldn't run if they installed it  
as a normal user. Well... It doesn't run. The binaries will not run  
unless they have access to certain OS features (raw sockets and such) and  
we were NOT going to make it SUID to root. So we added the check to tell  
the user at install that it needed to done as superuser.  
  
For the record, I strongly suspect that I wrote that. It would have  
been about 3 years ago and hadn't been looked at since. The time factor  
is no excuse, however. I should have known better and I missed it. At  
the very least, that "touch" should have been a "mkdir" (with appropriate  
modifications elsewhere in the script) with some more error checking behind  
it. Checking for the existance of the file first is useless, since that  
unavoidably creates a timing window. Any thoughts or objections to mkdir?  
I think there is only a miniscule race condition in a very few kernels (?)  
and even that should be detectable. I don't think it can be abused to  
create any denial of service attacks. Comments?  
  
Only takes a moment to plug it in.  
  
What a shame this wasn't reported to us first so we could fix it  
more promptly. We fix things as quickly as possible that get reported to  
us. But I guess that didn't suit the purpose here. The action here merely  
introduced several more days into getting this fixed (the time it took to  
appear on bugtraq, plus the weekend, plus the flack of dealing with managers  
here).  
  
It's interesting that this plays right into the discussion over  
"full disclosure" that has been raging on BugTraq. Had this been reported  
to us immediately, we would have promptly fixed it. Instead, the author  
waited until late in the week and then sent it into BugTraq where it must  
be approved by Aleph One and were it then gets posted on the weekend.  
Apparently this person was not concerned about the speed at which this  
would get fixed. That's understandable too. Not to make light of the  
problem, but it only affects the installation of the product and only  
when an administrator is installing this with a malicious user present  
on the system where he is installing his security software (Gee, this  
was uncovered when the author was trying to bypass some of the root  
checks... Hmmmm...)  
  
I don't personally care if it becomes common knowledge. I would  
have expected that ethics would manadate that someone at least notify  
us first. It's not like we are hiding. It was downloaded from our web  
site, so the author can't claim he didn't know who to notify.  
  
> 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  
  
Checking for the file first would have only turned it into yet  
another race condition in a shell script. Get real...  
  
> 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  
  
You might have to wait a while without being spotted. "Why is the  
/tmp directory so huge? Why are there 65,536 symlinks to /etc/password in  
there?" Again, no excuse, but this would be a really lame one to pull  
off unless you had something that could spot the fact that an install  
was about to take place and slam in the symlinks ahead of it. Lame or  
difficult, but not impossible, true.  
  
> 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.  
  
Yeah... It's a really annoying DoS attack when some user notices  
that his admin is about to install ISS on the system. Stupid mistake.  
My fault. Mea culpa.  
  
> 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.  
  
The hair shirt doesn't suit someone who doesn't even do the  
courtesy of notifying the authors...  
  
For the record, ISS makes very significant contributions to  
the Open Source movement. They pay several of us significantly and allow  
us to work on and contribute to several open source projects. ISS  
currently supports two members of the Samba development team and allows  
us to contribute a lot of our effort back to that open source project.  
  
Several others have made contributions to SNMP projects and I've  
done SSL patches for fetchmail that can be downloaded from the North  
American Crypto archives. We are constantly working on allowing people  
to contribute to open source projects and be allowed to work on them on  
"company time". For the most part, we are successful.  
  
No matter how much progress we make in supporting Open Source  
software, there will always be things which are going to be closed  
source. We may not agree with these stands but that's the way they  
are. I've even written articles on security and the open source movement  
and how it improves security. But reality is a problem. We can't just  
make everything "open source" over night. No matter what we do or say  
or argue, it's just not going to happen for some things.  
  
When we have people like this who just have an agenda to beat  
someone up with no regard to fixing things or to improving security,  
it just makes my job that much harder getting management to approve of  
the open source work we can do! They start taking the attitude of  
"why should we even bother when it just means more aggravation"!  
  
I can come up with all the standard answers for our managers but  
the fact remains that as long as we have people who are going to splash  
this about just for their own agrandizement without even doing the authors  
the ethical courtesy of contacting them first are NOT acting in the interest  
of the open source movement. This does nothing but discourage both  
software authors who become even more leary that some slimeball is going  
to slam them without warning and it makes their managers worry that there  
is nothing but bad pr from irresponsible individuals waiting in the wings  
if they do open sources up.  
  
If you had spotted a similar problem in an Open Source project,  
would you have notified the authors first? If not, why not? If so,  
why not do us the same courtesy? Open Source means contributing back  
to the project, not bashing it just to make yourself look bigger. We  
have a hard and fast policy to always contact the vendor or author  
before going public with security advisories or annoucements. That  
means open source or closed source. That even means our competitors.  
We will do them the same courtesy that we would expect in return. That's  
called ethics.  
  
Next time my projects get reviewed, how to I defend against  
managers who tell me that I need to spend less time on Samba and on  
fetchmail since readable source had just caused them these headaches?  
  
> 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/  
  
If security truely was the only objective here then why weren't  
we contacted first? There seems to be no logical reason NOT to contact  
us. It would have been fixed much faster had we been notified and  
then you could have announced it at about the same time as you did.  
  
In spite of the way this was announced, if we find anything in  
your code, you will hear from us first, before anything ever appears  
in public. That's our policy...  
  
> --  
> Fyodor 'finger [email protected] | pgp -fka'  
> "Girls are different from hacking. You can't just brute force them if all  
> else fails." --SKiMo, quoted in _Underground_ (good book)  
  
  
Mike  
--  
Michael H. Warfield, | Voice: (678)443-6000 (678)443-6123  
Senior Researcher - X-Force | Fax: (678)443-6477  
Internet Security Systems, Inc. | E-Mail: [email protected] [email protected]  
6600 Peachtree Dunwoody RD NE | http://www.iss.net/  
300 Embassy Row, Suite 500 | http://www.wittsend.com/mhw/  
Atlanta, GA 30328 | PGP Key: 0xDF1DD471  
  
-------------------------------------------------------------------  
  
From: Peter Benie <[email protected]>  
To: [email protected]  
Subject: Re: ISS install.iss security hole  
  
Fyodor writes ("ISS install.iss security hole"):  
> # 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.  
  
There is a second problem, but it's not as obvious.  
  
The 'touch' program first calls stat() to check if the file exists.  
If it does, it calls utime() to update the timestamps; if it doesn't,  
it calls fopen(filename, "w"). fopen will call creat() (or equivalent),  
truncating the named file.  
  
If you can predict the filename given to 'touch' (hard in this case,  
but definately possible with other scripts), you can create a symlink  
between the stat() and the creat() system calls and truncate any file  
on the system.  
  
(Not bad - two security holes in two lines...)  
  
Peter Benie  
  
`