On Thu, 14 Jun 2001, Gibson, Brian wrote:
: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.
Even IP packets can cause a great deal of problems for some routers.
Witness the problems some OS's had with overlapping fragments.
The real problem, though I don't think Cisco is subject to this,
is that most routers out there take their IP stack from some
previously written OS. In fact, many routers just take an existing
OS and add their own forwarding and device code to it.
When a vendor takes an existing OS and decides to do proprietary
development on it for their device, this is essentailly a code fork.
Some of the work I've done includes devices which use some proprietary
code fork of BSD. What happens is that the vendor writes all their
new forwarding and device code, but doesn't add the security patches
which are released for the original OS after they forked it.
This is why you will find obscure firewall appliances, routers, and
even machine control systems that you can drop with a Ping of Death,
or a small syn flood.
If you are evaluating a new product, find out what OS their firmware or
OS theirs is based on, find out when it forked away from the original
distribution, and then get a list of all the relevant patches that have
been made to the original OS since the creation of this "proprietary"
OS, and test for those bugs.
It's really scary what you will find.
Also, if you want to see how a device handles malformed packets, point
ISIC at it for 20 minutes. There is a strange and cruel pleasure in
watching a half million dollar machine thrash uncontrolably under the
stress of filling it's fragment buffers.
Tata,
:
:-----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.]
:
--
--
batz
Reluctant Ninja
Defective Technologies
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
