Re: real security - no foreign binaries

From: John Sage (jsage@finchhaven.com)
Date: 03/09/02

  • Next message: NonSense: "I would like to connect my Linux Mandrake 7.2 to Internet. But I Have problems! 8-()" 

    From: "John Sage" <jsage@finchhaven.com>
Date: Sat, 09 Mar 2002 05:02:39 GMT

    hmm..

    ..let's see:

    From: Dr. Joel M. Hoffman (joel@EXC.COM)
    Date: Sun Sep 12 1999 - 02:37:00 BST

    I was thinking --- it wouldn't be too hard to make buffer overflow
    attacks impossible. The basic idea is to do away with binary
    compatibility.
    In particular, I was thinking that part of building a kernel would
    involve assigning a random number to each syscall, and creating a
    syscall.h file with these random numbers. A binary would only run if
    it was compiled with the proper syscall.h, so all binaries would have
    to be recompiled for the new kernel, but then, syscall.h could be
    removed, and the system would be impervious to buffer overflow
    attacks. (One step further would involve random magic numbers in
    every function call.)
    I would be happy to give up binary compatilibyt for the added security
    it would add.
    Comments?
    -Joel Hoffman
    (joel@exc.com)

    I think it's time to give it up and move on...

    ...three years have gone by, and no one's bought in, yet.

    - John 

    -- 
Most people don't type their own logfiles;  but, what do I care?

    > I've had two Linux machines running for 8 years, and neither one has
> every been successfully hacked.  I just installed RedHat 7.2, and it
> took less than two weeks for someone to break in.  I believe the reason
> my old systems have never been sucessfully broken into is that they only
> support a.out binaries, and all run such old s/w that none of the
> current hacks work.  So I have two observations:
> 1.  It's time to re-think security.  The real security problems are no
> longer potentially insecure programs like telnet vs more secure programs
> like ssh.  The real security problems are s/w bugs that lead to root
> compromise.
> 2.  It's time we design a system that doesn't let ANY foreign code be
> run.  The way to do this, I think, is to randomize kernel calls and
> syscalls on a per-computer basis.  The idea is that I would build my own
> kernel and libraries using a nice big random number.  Then only binaries
> that knew that random number would be able to run at all. Presto!  No
> buffer-overflow attacks.
> -Joel

    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: [patch] Add basic sanity checks to the syscall execution patch
      ... that the check returns -ENOSYS and thus makes rootkit attacks _more ... so] that tries to hide itself from the general kernel scope as much ... unrecognizable from the general entropy of randomization. ... the only other option would be for a rootkit to transparently switch to ...
      (Linux-Kernel)
    • Re: ISS Proventia email overflow
      ... In buffer overflow attacks, an attacker supplies data that is longer ... with real-world attacks from CORE IMPACT. ...
      (Focus-IDS)
    • Re: Somebody is keep trying to ssh into my systems, how can I stop that?
      ... HAS been vulnerable to bufferoverflow attacks that would not require anyone ... The problems ssh has had with buffer ... mainstream netfilter distribution has proven that. ... have been reported vs. buffer overflow attacks of an open ssh port???? ...
      (comp.os.linux.security)
    • Re: Problem compiling binutils
      ... article, Stan R. wrote: ... That sorta looks like a Red Hat kernel - what does 'rpm -qi kernel' ... IE, DoS attacks. ...
      (comp.unix.admin)
    • Quantcast