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

[DeleGate-En] Re: Delegate Security - Buffer Overflows
18 Nov 1999 10:12:44 GMT ysato@etl.go.jp (Yutaka Sato)


On 11/18/99(15:56) you "J. Francois" <ppmbabdyi-dyd2yvf7w5xr.ml@ml.delegate.org> wrote
in <_A635@delegate-en.ML_>
<URL:http://www.delegate.org/mail-lists/delegate-en/635>
 |I have recently shut down my public proxy operations until the
 |buffer overflows in DeleGate that have been published on BugTraq
 |are fixed.

At least the problem demonstrated in the report cannot occur in
DeleGates with explicitly specified SERVER=xxxx parameter.  And
at least the overflow in the report was fixed anyway in DeleGate/5.9.7.
I suppose most of DeleGate users can make practical protection
from rogue client hosts by access control mechanism or interface
restriction by -Phost:port, except users like you running public
proxy servers...

 |I will try to compile DeleGate on OpenBSD and if that works I will
 |resume operation as soon as possible on that platform.

I think that kind of attacks can be feasible for any platforms where
execution on non-text segment (on stack in this case) is possible.
If such execution can be disabled by a computer architecture, I think
it is the most generic solution.

Where such execution cannot be protected by an architecture, next
solution can be provided by operating systems.  If an operating system
have a switch to disable any execve() system call or spawn() in the
child process, I can use it.  Maybe Win32 provides such switch. 

Possibly ptrace() system call can be used to watch execve() in child
process to trap and kill a child process which did execve().
Also if protected "close-on-exec" flag is in kernel, I can apply it
for the file descriptor of client-socket.

But all of these are platform dependent thus are hard to be portable.
So I thought a simple and portable solution out now which may be
feasible for a while, that is "stack-base randomization".  I enclosed
a path in this message and hope this will work.

Of course I will try gradually repairing possible buffer overflows, or
drastically by removing usage of buffers.  The main source of buffer
overflows is host name processing and they will be removed in
DeleGate/6.X where an integrated data type for host name and IPvX
addresses will be introduced.

 |Until then I will wait to hear that the buffer overflow exploits
 |available in such a fantastic piece of software have been corrected.
 |I have already started going over the source code so that I may
 |try to contribute some fixes of my own.

I will appreciate such reports.  You might find some core dump log
at your LOGDIR/abort/ which might show such practical overflows.

Cheers,
Yutaka
--
Yutaka Sato <ysato@etl.go.jp> http://www.etl.go.jp/~ysato/   @ @ 
Computer Science Division, Electrotechnical Laboratory      ( - )
1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan            _<   >_


/** STACK BASE RANDOMIZER FOR DeleGate *****************************
  This patch makes the stack base of DeleGate process for each
  invocation and for each client request.

  1. rename main() to delegate_main() in src/delegated.c
  2. rename execGeneralist() to execGeneralist1() in src/service.c
  3. insert following code into src/delegated.c
 *******************************************************************/
#include <stdlib.h>
int RANDSTACK_MAX = 1024;

main(ac,av)
	char *av[];
{	int code;
	char *buff;
	unsigned int size;

	srandom(getuid()+getpid()+time(NULL));
	size = random() % RANDSTACK_MAX;
	buff = alloca(size);
	return delegate_main(ac,av);
}
execGeneralist(Conn,fromC,toC,svsock)
	void *Conn;
{	char *buff;
	unsigned int size;

	srandom(getuid()+getpid()+time(NULL));
	size = random() % RANDSTACK_MAX;
	buff = alloca(size);
	return execGeneralist1(Conn,fromC,toC,svsock);
}
/*******************************************************************/

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