[14743] in bugtraq
Re: Solaris 7 x86 lpset exploit.
daemon@ATHENA.MIT.EDU (Casper Dik)
Tue May 2 16:35:20 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <200005010810.KAA22470@romulus.Holland.Sun.COM>
Date: Mon, 1 May 2000 10:10:30 +0200
Reply-To: Casper Dik <Casper.Dik@HOLLAND.SUN.COM>
From: Casper Dik <Casper.Dik@HOLLAND.SUN.COM>
X-To: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Sat, 29 Apr 2000 12:24:44 EDT."
<200004291624.MAA19828@Twig.Rodents.Montreal.QC.CA>
>>> set noexec_user_stack = 1
>
>> [...], there is a reason, why SUN does enable stack execution by
>> default, if i am correctly informed this is due to some fortran or
>> rare/old compiler issue, and might break some fortran or other alien
>> language code...
>
>It'll also break gcc's nested function support, since it's implemented
>with stack trampolines. (It doesn't *have* to be; in principle
>function pointers could be widened to carry the same information. But
>doing that would break function-pointer compatability with code
>compiled with other compilers...not to mention meaning that most
>function pointers would carry a bunch of unnecessary-for-them extra
>data around. Another possible way around it would be to cause gcc to
>keep part of the stack in the data segment, out of what the kernel
>thinks of as the stack, and have it do its trampolines there. This
>runs into big problems with setjmp and other nonlocal exits, and
>possibly with signal handlers as well.)
It's wrong to say it affects all nested functions; it only affects
nested functions passed as parameter.
In current gcc releases this has been fixed. The trampoline code
now calls "mprotect()" after putting a trampoline on the stack.
Casper
