Re: IP Level Encryption (kind of long)

From: Robert Wessel (robertwessel2_at_yahoo.com)
Date: 12/16/03 

Date: 15 Dec 2003 22:14:03 -0800

"Skybuck Flying" <nospam@hotmail.com> wrote in message news:<brj0fo$6hn$1@news1.tilbu1.nb.home.nl>...
> Ofcourse a hacker could still try to overwrite other data which contains
> pointers to executable code like Henrick mentioned.
>
> Ieewww... difficult problem !

Ahhh... You show insight, Grasshopper.

Trying to secure all of this in hardware inevitably leads to the
re-re-re-re-re-re-reinvention of capabilities. And even then, only
the more extreme versions of capabilities can deal fully with the
pointer-to-function problem.

Capabilities, of course, are quite out of fashion at the hardware
level. Moving the function to the compiler is probably a better idea,
especially as processors get faster and spend a higher and higher
fraction of their available execution resources idle (after all if
most of the CPU is waiting for memory, or whatever, why not execute
some bounds checking code). Of course, languages with unbounded
pointers present almost insurmountable problems under any scenario.

That being said, partial protection at the hardware level is probably
better than none. Requiring an "executable" bit at the page level
would noticeably increase the difficulty of directly injecting code
into a system. A feature sadly lacking on most x86s, and sadly
underutilized in most *nix systems on RISC boxes for compatibility
reasons.

Of course direct injection into memory is hardly the only way to
inject code into a system. For example, just rename an executable
image *.html, and point a link at it. It'll get downloaded and
probably stored in the browser's cache in a disk file. Now get
something to execute that file. Perhaps we could buffer overflow into
a string that is to be passed to system() - not a code pointer in
sight! OK, we can fix that by marking the cache directory as not
allowing code execution (a feature of most OS's). But now what about
scripts? As you said, "Ieewww... difficult problem !"

Relevant Pages

  • Re: Global Offset Table of a ELF executable
    ... > pointers to the shared library functions that the executable is using. ... > shared library function pointers consistent during execution once they ... the page protection to read-only after performing relocations to datums ...
    (comp.os.linux.development.apps)
  • Re: IP Level Encryption (kind of long)
    ... > pointers present almost insurmountable problems under any scenario. ... > would noticeably increase the difficulty of directly injecting code ... > allowing code execution. ... So before anyway can overwrite a pointer, you first have to unlock it:D ...
    (sci.crypt)
  • Re: Global Offset Table of a ELF executable
    ... >> pointers to the shared library functions that the executable is using. ... >> shared library function pointers consistent during execution once they ... > the page protection to read-only after performing relocations to datums ...
    (comp.os.linux.development.apps)
  • Re: global interpreter lock
    ... I doubt a language for thread-phobes has much of a future. ... require a fundamental redesign of the underlying execution hardware, ... All modern CPUs allow flow control through the use of machine-code/assembly instructions which branch, either conditionally or unconditionally, to either a relative or absolute memory address, i.e. a GOTO. ... To really have parallel execution with clean modularity requires a hardware redesign at the CPU level, where code units, executing in parallel, are fed a series of data/work-units. ...
    (comp.lang.python)
  • Re: Lockless file reading
    ... (especially if your hardware doesn't have cache coherency): ... CPU 0 stores the 24 bytes, and it splits across a cache line boundary. ... execution for operand accessibility that is performed before the execution of ... the instruction in which results are not stored. ...
    (Linux-Kernel)