I'm baaacccck...
On 14 Jun 2001, at 14:55, mouss wrote:
> At 14:24 13/06/01 -0400, 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;
>
> and one thing that eases it is "good guessing". This isn't as hard as one
> can think! you just try to think of how to implement something and see that
> there are some traps. You can then test "closed-source" software to check
> whether they falled in. I think that some specialist could write a book on
> "security bugs patterns".
This is simply not true. *Exploitable* stack overflows involve
writing *machine code* that runs on a particular hardware
architecture and OS, and virtually all of them to date have been for
arch/OS combinations that are widespread and well-documented.
EVEN if the exploit-developer knows what CPU architecture a
particular box uses, he also needs to understand how its OS
implements APIs in order to invoke functionality outside the exploit
code.
> A fundamental example that comes again and again is reading a
> line. Protocol handling requires parsing, and if not done the
> correct way, it always results in either buffer overflow or
> "normal" bugs (truncated lines and so on).
A truncated line is not an exploitable attack. A buffer overflow
that causes a reboot or hang of the box can be used as a DoS, but
it's not further *exploitable* in terms of TAKING OVER the box or
invoking behaviour contrary to the policies of the box owners. So
this paragraph is not really relevant to this thread.
> > 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.
> >
> > > IF the buffer overflow is on the stack
> >
> >This is quite often the case ...
>
> And if one keeps in mind the fact that all stacks have been either
> derived or inspired by the original BSD implementations, one can
> find many bugs just by looking at what has been corrected since
> then in the *BSD. Those who argue that this or that stack have been
> written from scratch should think about this: - either the guy
> never took a look at the available source code, but then he is
> probably a silly guy reinventing a square wheel. When solving
> problems, one should always check what others have done before (MS
> should have taken more time to review the problems encountered by
> Unix developpers, but let's forget about this); - or he wrote it
> from scracth after (carefully if he is "serious") checking what
> BSD guys have done. And as a human being, you can't force yourself
> to "forget" what you've learnt. so there are always chances of
> reproducing some old behaviour...
The fact that you have mistaken the CPU's *execution stack* for the
OS's *protocol stack* (not a stack at all, from a programming
perspective!) strongly suggests that you are out of your depth here.
Whether the code containing a buffer overflow bug is part of the
protocol stack or not is IRRELEVANT. In order to be exploitable --
to get the CPU to run instructions supplied by the attacker -- the
buffer that overflows must ALMOST ALWAYS have been allocated on the
*execution stack* of the CPU.
(I am the author of that "IF" line, the first of several conditions
to be met before a buffer overflow bug can be turned into an actual
exploitable hole....)
Developing an actual exploit involves crafting CPU-specific AND OS-
specific (often VERSION-specific) binary machine instructions to be
sent to the box being attacked. Your comments do not sound like you
are familiar with developing or debugging code at that level.
> [snip]
David Gillett
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
