[1549] in linux-security and linux-alert archive
[linux-security] Re: Re: cxterm buffer overrun
daemon@ATHENA.MIT.EDU (nate)
Thu May 15 12:01:22 1997
Date: Thu, 15 May 1997 10:26:02 -0400 (EDT)
From: nate <nate@millcomm.com>
To: acahalan@NO-SPAM.cs.uml.edu
cc: linux-security@redhat.com
In-Reply-To: <199705142045.QAA19899@orion.cs.uml.edu>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
On Wed, 14 May 1997, Albert D. Cahalan wrote:
> > 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 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, it is entirely possible that someone could write an exploit that
takes advantage of the signal handlers. 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. A very nice patch,
unfortunately it's only a kluge to prevent against the latest. BUGTRAQ
has been discussing this on and off for about the last month, and many
people have brought up some interesting points check out:
http://geek-girl.com/bugtraq/1997_2/
Patches such as this are great, if you realize that it's no substitution
for fixing the offending program, and you understand its shortcomines.
IMO, the OpenBSD folks seem like the only people (Theo, esp.) who are
attacking this problem the Right Way (complete code audits, fixing,
re-writing insecure function call instances), it's about time we (us
humble linux folk ;-) assumed this approach and level of awareness.
I'm publishing a paper detailing the UNIX buffer overflow problem, and
it includes some linux specific information.. it's not quite done yet,
if anyone would like to read a perliminary copy, drop me some mail.
--
-Nate Smith <nate@millcomm.com> | http://millcomm.com/~nate/
CoffeedrinkinHardcorePunkrockinSecuritymindedFreeUNIXgeek :-)
