Date: Sat, 20 Feb 1999 20:59:23 -0500
From: Fyodor <fyodor@DHP.COM>
To: BUGTRAQ@netspace.org
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 pgp@www.insecure.org | 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 <mhw@CHAOS.ISS.NET>
To: BUGTRAQ@netspace.org
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 support@iss.net 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 pgp@www.insecure.org | 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:  mhw@iss.net  mhw@wittsend.com
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 <pjb1008@CAM.AC.UK>
To: BUGTRAQ@netspace.org
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