[1399] in linux-security and linux-alert archive
[linux-security] program xxx is not vulnerable.
daemon@ATHENA.MIT.EDU (Rogier Wolff)
Thu Jan 23 02:04:56 1997
To: linux-security@redhat.com
Date: Wed, 22 Jan 1997 10:06:19 +0100 (MET)
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
Sometimes linux-security gets a message stating that program xxx might
be vulnerable to an yyy-attack (*). Sometimes people follow up stating
that they couldn't find an exploit.
If I ask the test-squad to test some know-to-work exploit, I get about
a 50/50 response. Half couldn't get the published exploit to work.
I've learned to interpret "nope it doesn't work on my system" as
containing little or no information. Certainly it should not be taken
as a true statement.
Now, when a possible security problem is found in some program that is
either accessable from outside or running with setuid permissions, for
some people this is a VERY serious problem. Others only care about
outside -> inside bugs. Even more others are just interested in keeping
informed, and won't even take action on a bug with a published exploit.
As a moderator for linux-security, I cannot take responsibility for
your security policy. This means that I approve possible bugs even
when there is no immediate threat.
Suppose I have a machine doing internet-order-processing. I have
100 clients that use that service, each with a few employees who have
an account on the order-entry machine. If I were responsible for the
security on this machine I really wouldn't want to wait for some
genius to find an exploit for the current "not exploitable"
buffer-overrun problems.
On the other hand, a private machine that doesn't have any other
user-accounts than mine, I really wouldn't take the trouble to fix it.
However I find it frustrating to have bugs found, but not fixed. If
in 5 years I find out that someone managed to exploit this buffer
overrun on the then-current Red Hat 12.1 distribution, I'd be really
pissed. We saw the possible bug, and should try to fix it somewhere in
the "master source".
I suggest we try to tag bug reports between
Everybody should evaluate the consequences.
and
only security critical installations need
to evaluate the consequences.
I'd recommend "security critical" sites to evaluate the recent buffer
overrun situations themselves(%). The maintainers I plead, please fix
every "possible" security hole. Even when it isn't proven that it's
exploitable (+). For others, I personally think that fixing this is too
much trouble, for what it gains you.
Roger Wolff.
(*) Currently xxx == write or login, yyy == buffer-overrun
(%) I -=am=- responsible for a security critical machine. Problem
evaluated. Action taken: None. I -=do=- have to take that decision
myself.
(+) For example when you find
for (i=1;i<argc-1;i++);
handle_file (argv[i]);
I really hope everybody maintaining a source would fix it even though
nobody has reported a bug about "more than one argument" not working.
(remove the "-1" and the ";" on the first line)
P.S. I had a peek at the login-buffer overrun problem. Wether or not
it is exploitable depends on the byte-order of your machine, and the
implementation of your compiler. I think i386/gcc isn't vulnerable. I
can't say a thing about other architectures or compilers (Possibly
even omitting -O2 could change things). Do -=not=- read this as other
architectures need to act on this problem. I don't think it is
exploitable, but for security critical applications, the person
responsible should be the one taking the actual decision.
