[1556] in linux-security and linux-alert archive
[linux-security] Re: cxterm buffer overrun
daemon@ATHENA.MIT.EDU (Albert D. Cahalan)
Tue May 27 05:31:59 1997
Date: Mon, 26 May 1997 23:03:22 -0400 (EDT)
From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
To: nate@millcomm.com, linux-security@redhat.com
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
>>> Quick fix? chmod -s /path/cxterm
>>
>> Better fix: I think you can stop that in the kernel and even
>> get a log of who tried to exploit it.
>>
>> http://www.linuxhq.com/lnxlists/linux-kernel/lk_9705_02/0453.html
>>
>> The patch is well thought out, with consideration for signals
>> and trampolines.
>
> Solar Designer's kernel patch to remove stack execution privilege,
> while a nice concept, is not a complete solution
Please don't discourage use of an excellent solution that
is not perfect in every way.
> and is only a fix for today's "find-unbounded-string-copy-insert-
> shellcode-into-return-address" write-code-in-10-min. stack
> smashing vulnerabilities. Since special considerations must be
> made to allow signals to have an executable stack,
WRONG. You have not seen the latest patch. Stack execution
does not get enabled ever. (you may enable trampoline detection
or set a flag in the executable header if needed) The signal
handlers were modified to use an illegal return address, which
the kernel detects.
> it is entirely possible that someone could write an exploit
> that takes advantage of the signal handlers.
No.
> Another approach might be to "string" an execve() call together,
> all from various places in the binary. Both of these approaches,
> while significantly more difficult to write, are not covered by
> a patch such as this one.
For the second problem, I think you can randomize the stack
starting location. Then an attacker would need to crash the
executable millions of times and not be able to reproduce
success without the same trial and error.
