Rene,
Well a router does run applications. A telnet daemon. A routing daemon. A tftp daemon. NTP. SSH. There are many others that they might run. Packets headed towards those services could cause an overflow just as with any other application.
As for causing a overflow with routed packets that would be very difficult but certainly not impossible. I would think more likely it would need to be a malformed Ethernet packet than IP packet.
-----Original Message-----
From: Rene Wijninga [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 13, 2001 2:33 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: cisco reboot
Might sound silly, but normally when the receiving buffer overflows
(receives an oversize packet), shouldn't the router just drop the oversize
packet? As far as I understood (but who is me anyway) is that what happens
in a Cisco.
By the way IOS COULD have bugs? Sorry, I must tell you that is HAS bugs. But
then again, it was written by humans.... :-)
Rene
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 13, 2001 4:24 AM
Subject: Re: cisco reboot
> 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.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
