Re: Privilege-escalation attacks on NT-based Windows are unfixable

From: Barry Margolin (barmar@genuity.net)
Date: 08/27/02 

From: Barry Margolin <barmar@genuity.net>
Date: Tue, 27 Aug 2002 15:26:54 GMT

In article <7xhehhkws5.fsf@ruckus.brouhaha.com>,
Paul Rubin <phr-n2002b@NOSPAMnightsong.com> wrote:
>Benjamin Goldberg <goldbb2@earthlink.net> writes:
>> > JIT compilation in Java
>> > Binary emulation like VMware
>> > Automatic code generation in GNU Lightning (same idea as JIT)
>> > Et cetera.
>>
>> All of these would put their data on the heap, not on the stack.
>>
>> This explains why one might want an executable heap, by doesn't explain
>> why one would want an executable stack.
>
>I'd expect some programs like that might want to put code on the stack
>instead of the heap.
>
>> Furthermore, even with such things, what's wrong with making the heap
>> non-executable by default, and having a special instruction which would
>> make small segments of it executable, on an as-needed basis?
>
>The argument against it is that you're trying to guard against
>deliberate attack, not random error. Closing one door just leads
>attackers to choose another. The only solution is fix the language
>and libraries and program carefully enough to not leave leaks.

No, you're trying to guard against deliberate attacks that take advantage
of well-known programming errors.

Buffer overflow attacks only work if the buffer is in a part of memory that
can be executed. If you have separate memory segments for stacks, normal
data and runtime-generated executable code, the buffers are going to be in
one of the first two segments. The attacker will never be able to use one
of these buffers to inject his own code.

It's remotely conceivable that someone would be stupid enough to put their
input buffer in the executable heap rather than the nonexecutable heap. If
someone is going out of their way to make their code exploitable, there's
only so much you can do to stop them. 

-- 
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Relevant Pages

  • RE: considerations about exploits tricks
    ... you can attempt to fix the stack for a start. ... This still does not stop heap attacks - ... the heap area and other data areas - not just the stack. ... any buffer overflow exploit that overflows ...
    (Security-Basics)
  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... >> All of these would put their data on the heap, not on the stack. ... you're trying to guard against deliberate attacks that take advantage ... Buffer overflow attacks only work if the buffer is in a part of memory that ...
    (comp.os.ms-windows.nt.admin.security)
  • Re: Why are variables stored on the stack?
    ... Buffer overflows are a more serious security problem on the stack ... not the heap, so that a malicious stack overflow can execute arbitrary ...
    (comp.lang.c)
  • Re: Why are variables stored on the stack?
    ... Buffer overflows are a more serious security problem on the stack ... than on the heap, because the program counter is stored on the stack ...
    (comp.lang.c)
  • Re: Why are variables stored on the stack?
    ... Buffer overflows are a more serious security problem on the stack ... not the heap, so that a malicious stack overflow can execute arbitrary ...
    (comp.lang.c)