Article delegate-en/1527 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Announced DeleGate exploits
09 Feb 2002 10:14:07 GMT (Yutaka Sato)

On 02/09/02(01:50) you "Vasco Veloso" <> wrote
in <_A1525@delegate-en.ML_>
 |I'd basically like to know your response to the vulnerabilities reported by
 |Global InterSec LLC (see

I'm not sure whether the author of the report know how the defense
mechanisms of DeleGate works.  The report says:

>  In spite of attempts DeleGate makes to randomise the stack, we
>  were successful in overwriting the Extended instruction pointer.

The stack randomization has nothing to do to prevent stack overflow
to overwrite EIP.  It works to prevent buffer overflows from being
exploited for attack.

> In the case of a *real* exploit, the EIP could be a pointer to
> the attackers shellcode which would already be in memory.

The problem is how to know where the exploit code is.  It's not
easy because addresses of dynamic data (on stack and heap) are
randomized at run-time, and address of static data and text are
randomized at compile-time.  Thus I think it will not be easy to
make a certainly reproducible attack for a DeleGate on a remote
site.  And the attacker must succeed on the first trial since a
failure causes fatal signal on which DeleGate shuts down further
services for the attacker's host.

Anyway, if you wish you can terminate buffer overflows using a
bounds checking GCC
From my experience, the overhead by it with DeleGate is not
significant, several percent for example.

  @ @ Yutaka Sato <>
 ( - ) National Institute of Advanced Industrial Science and Technology (AIST)
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]