[16522] in bugtraq
Need for exploits (was: Remote DoS Attack in Eeye Iris. . .)
daemon@ATHENA.MIT.EDU (Zow Terry Brugger)
Sat Sep 2 14:31:12 2000
Message-Id: <20000901203210.7FD4A2099E@lists.securityfocus.com>
Date: Fri, 1 Sep 2000 13:32:17 -0700
Reply-To: Zow Terry Brugger <zow@PENSIVE.LLNL.GOV>
From: Zow Terry Brugger <zow@PENSIVE.LLNL.GOV>
X-To: Valdis.Kletnieks@VT.EDU
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Message from Valdis Kletnieks <Valdis.Kletnieks@VT.EDU> of "Fri,
01 Sep 2000 12:29:05 EDT."
<200009011629.e81GT6026452@black-ice.cc.vt.edu>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Allow me to start by saying that I generally agree with you, but I think
there's a important issue that needs to be addressed here. I do not want this
to become yet another full disclosure debate and I will express no opinion to
that end.
> And maybe you *need* to slap the jellied remains to get people to upgrade
> and migrate. Somebody just posted to the XEmacs list with a bug report
> that XEmacs fails to build in the X11R4 environment that SunOS 4.1.4
> provides. Should people on those systems not be told "Hey, there's an
> issue here", just because their vendor has dropped support?
>
While I agree with you here, there are many installations that continue to use
these old, unsupported products for valid reasons (e.g. lock in of a system
configuration in a change management system). If a system provides all the
functionality that it needs to, why change it and (likely) break it? I will
argue that they have no business trying to install a new program (like XEmacs)
on that system as that demonstrates that the system does not in fact provide
all the necessary functionality. BUT, how can we protect these systems when
the vendors no longer will? Some fundamental problems can not be fixed short
of replacing the system, but I assert that some can be patched by doing things
like intercepting the input stream to the system to do input validation and
other similar methods. With the growing number of unsupported systems still in
wide deployment a general solution to these sorts of problems would be very
useful I suspect.
> Consider the recent rpc.statd exploit - if it had included "and oh, yeah,
> FooBarOS 7.1 is vulnerable too", and FooBar Inc had gone belly up, what do
> the legacy users use to test? An exploit known to work is a BIG step
> up - there's a lot of people out there who can apply a patch, but aren't
> able to craft an exploit themselves. If they have one that works to start,
> they can be pretty confident when they've closed the actual hole, as opposed
> to merely having been unable to get the exploit to work.
>
This is the real point I wanted to address (the above was more food for
thought). Users would be well advised to be wary of false negatives. Just
because a given exploit works on some number of hardware, system and
application configuration combinations does not necessarily mean that it will
work on every one. Many classes of exploits are inherently sensitive to the
system they're running on because of things like requiring a certain
instruction set on the processor or a certain layout of the stack or
instructions in the kernel. If you've got an old, unsupported system that's
likely had a great deal of local modification and configuration (hence making
it difficult to replace), then it's entirely probable that a given exploit
will not work on your system when your system is still vulnerable. User beware.
"Zow" Terry Brugger
zow@acm.org
zow@llnl.gov
#ifndef STDDISCLAIMER
#define STDDISCLAIMER
Any opinions are mine and mine alone. My employer will accept no
responsibility for the content or opinions expressed herein.
#endif
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBObASUafuGVwXgOQkEQKmIQCfRdXFHN7PhJlpvyQTw0NAR23x21UAn2WA
Yg80O1TbMe+aWhiUVnL1DSKF
=c+s8
-----END PGP SIGNATURE-----
