On 13 Jun 2001, at 14:24, Michael T. Babcock wrote:
> > > And without IOS source, that would certainly be... challenging...
> >
> > I quite agree.
>
> I disagree ... many, many buffer overflow exploits in closed-source
> software packages have been discovered by trial and error, without
> any use of source code; they aren't that hard to find. Simply find a
> good search engine (such as astalavista.box.sk) and look for HOWTOs
> on buffer overflows.
Bear in mind that these closed-source packages are running on
popular hardware architectures and common OS platforms.
> > IF the buffer overflow is on the stack
>
> This is quite often the case ...
>
> > and lets you overwrite the program counter
>
> ... this is almost always the case ...
>
> > AND IF it can be overwritten to point into the buffer
>
> ... and this is almost always the case as well, unless using an OS designed
> specifically to not allow execution of the stack (there are options for this
> in Linux, et al.).
These are all common, but they are NOT universal.
> > knowledge of the IOS internals to make the code do anything "useful".
>
> Like what knowledge? The type that could be gleaned by owning a
> cheap refurbished Cisco unit?
Or perhaps disassembling a downloaded version of IOS. You don't
necessarily need to have the hardware, although it would make testing
easier. (Having the source to IOS would be even better. How many
people has Cisco laid off in the last six months?)
Okay, suppose we've met all of the stack-overflow conditions so
that the program counter is now pointing at bytes that were supplied
by the intruder in creating the overflow condition. Now what? Those
bytes have to be in the machine language understood by this CPU. If
they make references to absolute memory addresses, the author has to
know what those addresses are for this particular model with this
much memory and this IOS version. If he wants to reroute packets or
something, he has to know how legitimate IOS code invokes those
services....
> > Short of that, there could be some risk that an attacker *might* be
> > able to "hang" IOS rather than force a reset.
>
> It would be much more entertaining if they were able to send all packets
> to a multicast address ...
Yes, but it's about an order of magnitude harder to do. There can
be buffer overflows which interfere with stable/normal operation;
some of those meet the above conditions and allow arbitrary code to
execute; and for some of *those*, someone has done (or is doing, as
we speak) the really hard work to get that arbitrary code to actually
compromise the operation of the box and not just disrupt it.
David Gillett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
