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.]
