Re: Overview Of New Intel Core i7(Nehalem) Processor

On Wed, 17 Jun 2009 09:44:18 -0500, AZ Nomad
<aznomad.3@xxxxxxxxxxxxxxxxxxx> wrote:

On Wed, 17 Jun 2009 07:13:57 -0700, John Larkin <jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Wed, 17 Jun 2009 06:33:44 GMT, James Arthur
<bogusabdsqy@xxxxxxxxxxx> wrote:

Vladimir Vassilevsky wrote:


Nobody wrote:


Buffer overflows don't trash *code*, they trash return addresses (or,
less often, data). This can be used as a mechanism to execute code, but
you still have to put that code somewhere it can be executed, and the
number of systems where that includes the heap and stack is diminishing.

Also, you can mitigate return address corruption with canary-based
techniques (StackGuard, ProPolice, etc) and/or address randomisation.



This is a vain attempt to solve the non-technical problem by technical
means. If somebody breaks into the houses, this is not because the doors
are too weak.

With all the CPU cycles M$ wastes I never understood why buffer
overflows were even possible. Simple boundary-checking would
prevent the whole thing.

Cheers,
James Arthur

Horray! We only waited 20 years for this...

http://gizmodo.com/5256724/

Except that their lazy, bleary-eyed, underpaid-with-no-benefits
microserfs will get some structure off the web, look in its header to
determine its size, and use that as the memcpy_s() parameter. That's
what they call "efficient programming" in Microland.

You heard it here first.

There's no need. Put code in code pages, data in data pages. Intel
processors have had the ability to manage virtual memory mapping
for code vs. data since the 286. The 386 made it easier by using
demand paged virtual memory instead of the 286's silly segmented menory.
Make the code pages readonly and mapped separately and it is
impossible for buffer overflows to overwrite code.

You forgot about the stack. As long as data gets shoved to the return
stack you've left the barn door open.

Microsoft has never understood the difference between code and data.

....and stack.

All their documents have to have the ability to execute arbitrary code
so that you can get the stupid dancing bunnies and those lovely email
worms.

Yep. Why isolate executable code if you'll treat a .doc as an
executable.
.

Relevant Pages

  • Re: dynamic code, change code in cs
    ... > Modern OS/processors are getting better at stopping dubious operations ... execute code on the stack would fail in XP-SP2 is this the case? ...
    (borland.public.delphi.language.basm)
  • Re: XP SP2 will break applications
    ... The no execution flag introduced disallows to execute code on the stack. ... This means that any self-modifying code which is usually placed in a ...
    (borland.public.delphi.non-technical)
  • Exploiting Buffer Overflows on Compaq Tru64 and No-Exec Stack
    ... I have been testing buffer overflows on Compaq Tru64. ... examples execute code on the stack. ...
    (Vuln-Dev)
  • Re: Overview Of New Intel Core i7(Nehalem) Processor
    ... return addresses all on the same stack. ... Is there a C compiler that doesn't push everything on the stack when ... Buffer overflows don't trash *code*, they trash return addresses (or, ... This can be used as a mechanism to execute code, ...
    (sci.electronics.design)
  • Re: Why are variables stored on the stack?
    ... Only if you can execute code in the stack ... that's why C *implementations* typically use a hardware stack. ... A stack overflow occurs when (again, ...
    (comp.lang.c)