Re: securing bind

[Gerardo Richarte <core.lists.firewall-wizards () core-sdi com>]

    I tried to not quote all your message, but I have something to say  about
almost everything...

Ken Hardy wrote:

> IMHO something like StackGuard should be a standard option on
> *all* compilers, and all exposed services like DNS should be
> compiled with it enabled.  Make that every bit of code (incl.
> kernel?) running on a firewall.
>
> It's not a cure-all for bad coding, but it does disable the
> hackers' favorite attack automatically w/o any application code
> review and patching.  Well, not completely disable, but it will
> turn a root compromise into a DOS (program abends on stack
> overrun).

    You are more right than what you think... The example you are using here is
not a very happy example (BIND). StackGuard may be a good solution for a lot of
buffer overflows, but IT'S NOT the final solution.
    StackGuard doesn't take care of the known IQUERY buffer overflow in BIND
(http://www.securityfocus.com/vdb/bottom.html?vid=134). This is a double buffer
overflow, (a buffer overflow overwriting a pointer to a buffer where information
is copied later).
    Current StackGuard (v1.21) says it fixes this problem, but as I stated in a
message in bugtraq, this is not true. While it makes it impossible to exploit it
changing the return addresses in the stack, it's still possible to exploit it
using a different approach.
    I know, as Crispin Cowan said, that there will be a new product from
StackGuard's people that takes care of function pointers, while I don't know how
they will do it, I KNOW that this will NOT fix the problem I recalled previously
(BIND's).

> See http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard.
> I'd be interested in knowlegeable comments about how reliable
> and comprehensive this approach to the stack overrun problem
> is, though it's probably beyond the charter of this list.

    Take a look at
http://www.securityfocus.com/templates/archive.pike?list=1&date=1999-11-8&msg=199911092144.NAA24201 () church cse ogi 
edu
for a description of the problem, as presented by StackGuard's people. And take a
look at the thread starting with that message for a discussion of it. Specially
take a look at
(http://www.securityfocus.com/templates/archive.pike?list=1&date=1999-11-8&msg=382AD8E0.304928DD () core-sdi com)
where you can find an example of an exploit passing StackGuard on a double buffer
overflow.

> Alternatively (and higher performance?) Solaris 2 has a kernel
> parameter that can be set to make the stack non-executable.

    Again I can use the same example: BIND. The exploit for Solaris' BIND is not
trivial, and in fact uses a double buffer overflow, with the second part
overwritten being libc's code segment, which is executable (of course) and is
writeable in Solaris up to 2.51 (I don't know in 2.6 and 2.7, should be the same)

    So, while StackGuard is a solution for a lot of buffer overflows, you can't
feel secured to this kind of attacks just by using it.

    richie

--
A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0
Investigacion y Desarrollo - CoreLabs - Core SDI
http://www.core-sdi.com



--- For a personal reply use gera () core-sdi com