It's a C O M P U T E R.
It runs software (IOS); that software could have bugs or
compromises.
The primary function of that software is to receive and forward
packets intended for other machines, and to do reasonable things with
packets that cannot, for some reason, be forwarded.
It's a computer which is a node addressable on a network.
A secondary function of its software is to communicate, as an
endpoint, with network administrators, or those attempting to pass
themselves off as such.
I'll accept that "oversize packet" was too simplified. What I
meant more generically was "more data than the receiving buffer can
hold", and I'll conced that at the *packet* level, this is *probably*
handled correctly.
It's a bit less likely to be handled correctly at the "application"
level. i.e., suppose you telnet in and send it 64K of text when it
prompts for a password.
Regarding "which counter"....
It's a C O M P U T E R.
The error indicates that an attempt was made by the CPU to access
memory using an address that couldn't possibly be valid. It's true
that SOME instructions retrieve data from memory by referring to
addresses that they have also retrieved from somewhere in memory,
where they could have gotten corrupted[*].
However, *EVERY* instruction is itself retrieved from memory at the
address specified by the "program counter" register. At a bare
minimum, HALF of all memory accesses must use this address, and it
would not surprise me if in useful code the proportion exceeds 85% or
more.
(I'll concede that static discharges are more likely to corrupt
pointers/addresses stored in memory than those in registers, and that
since the program counter is relatively rarely loaded from memory, it
is no more likely that a pointer corruption caused by static would
affect the program counter than any other pointer.
The flip side of that, though, is that buffer overflows on the
heap, rather than the stack, are likely to corrupt pointers besides
the program counter. So whether the corrupt pointer is the program
counter or not doesn't really prove whether it was corrupted by a
buffer overflow.)
[*] Static discharges such as you describe tend to have rather high
voltages, and may not just corrupt bits but actually damage memory
components. Apparently that didn't happen in this case. I'm not
saying that proves it wasn't a static discharge....
> Isn't this a "firewall" list.
Yes. So if there's a security-threat context in which an address
might become corrupted, it's not entirely inappropriate to consider
it.
I agree that the lack of repetitions does make it *less* likely
that this is the result of malicious network traffic. I'm not sure
we were given that information before, and it falls way short of
PROVING it wasn't malicious -- maybe the instigator is back at the
drawing board, trying to figure out why his exploit code didn't run.
David Gillett
On 12 Jun 2001, at 14:53, Brian Ford wrote:
> David,
>
> It's a R O U T E R.
>
> Try sending over size packets. Properly configured R O U T E Rs just take
> the packets, chunk them up differently based on MTUs and forward them out
> another interface. They don't care about putting all the packets back
> together to process some message from another device. IF they do they are
> probably doing a non routing (i.e. gateway) function.
>
> Regarding "which counter", this isn't open source code. You and Dave have
> no idea as to which counter got a bad value because you have no idea what
> the code base looks like. You could spend months or years and never
> re-create this fault.
>
> The reality is that this as probably just a static discharge from the
> serial line (or other temporary environmental problem) that caused the
> router to corrupt some bits and power cycle. And the router did power
> cycle and come back up. And this router has been in place for at least 3
> years without incident. And this router has been working correctly ever
> since. Period.
>
> Isn't this a "firewall" list.
>
> Regards,
>
> Brian
>
> At 04:30 PM 6/12/2001 +0000, Firewalls-Digest wrote:
> >Date: Tue, 12 Jun 2001 08:58:26 -0700
> >From: [EMAIL PROTECTED]
> >Subject: Re: cisco reboot
> >
> > > So David how do you create a buffer overflow condition on this
> > > router? Hmm?
> >
> > Send an oversize packet to one of its interfaces, I expect, just as
> >one does with any other kind of net-connected computer.
> >
> > > And Dave which counter got a bad value?
> >
> > If you've *ever* worked at the assembler/machine-language level on
> >any mainstream CPU architecture, you will have been introduced to a
> >register (or register-pair) called the "program counter", which
> >contains the address of the next instruction to be executed.
> > Most instructions include, as a side-effect, incrementing this
> >register by an appropriate amount. JUMP instructions overwrite the
> >register contents with a new address. CALL instructions save the old
> >address to the stack first, and RETURN instructions pop a value from
> >the stack which is *supposed* to have been saved there by a CALL.
> >
> >1. Exploitable buffer overflows typically involve a buffer allocated
> >on the stack, so that the overflow corrupts the return address.
> >
> >2. "Bus error" is how several of the CPUs Cisco has used signal that
> >they have tried to access memory using an address that is invalid
> >because it is not properly aligned.
> >
> > Dave's suggestion is that the bad address could have been the
> >program counter value. My elaboration is that a bad program counter
> >value could be the result of stack corruption caused by a buffer
> >overflow.
> >
> >David Gillett
>
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
