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 supportat_private 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 pgpat_private | 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: mhwat_private mhwat_private 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:36:57 PDT