All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Jensen <kernel@millcreeksys.com>
To: Valdis.Kletnieks@vt.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: [2.7 "thoughts"] V0.3
Date: Fri, 10 Oct 2003 19:54:06 -0600	[thread overview]
Message-ID: <1065837246.3f8762bedd4db@secure.millcreeksys.com> (raw)
In-Reply-To: <200310102313.h9ANDtRX009446@turing-police.cc.vt.edu>

Thanks for setting me straight.  For some reason I thought that whenever a
binary was executed (even through a buffer overflow), an exec() was issued.

Don't ask what I've been smoking...





Quoting Valdis.Kletnieks@vt.edu:

> On Fri, 10 Oct 2003 16:33:09 MDT, Michael Jensen said:
> 
> > I agree that it wouldn't have any effect on buffer overflows.  It would
> prevent
> > further abuse of the system unless the perpetrator was able to install and
> load
> > a modified kernel.  Even if they had root access, they would be unable to
> > execute backdoor binaries because they would not be signed with a trusted
> key. 
> > This would also thwart rootkits.
> 
> Umm... let me see if I got this straight...  They already exploited the
> system once
> to get in originally, and you think that the same method that didn't stop
> them
> from executing code to get in will also stop them from exploiting further?
> 
> All they need to do is park their code-to-execute in a file *anywhere* on the
> box,
> and then invoke any of the numerous programs that have local buffer
> overflows,
> and then use that program and an overflow sled to act as a poor-man's
> replacement
> for /lib/ld-linux.
> 
> Hmm.. /bin/ls segfaults under some overflow conditions?  Just set up the
> conditions, run /bin/ls, get the signed binary to run, and use it to load
> your
> code. Game over. /bin/ls isn't exploitable?  Wander over to packetstorm and
> pick and choose a ready-made exploit for lots of other stuff..
> 
> The basic problem here is that you're assuming that "the code loaded by
> exec()"
> is trusted, therefor the code actually executed is trusted.  Given that most
> modern
> processors are Von Neumann architectures rather than Harvard machines, that's
> a
> problematic assumption.  That's why things like exec-shield or SELinux are
> probably
> more productive directions - they are taking a different model:
> 
> exec-shield - We don't care if you're a trusted program, you're not executing
> off the stack.
> 
> SELinux - We don't care what binary you are, if you started in this security
> domain,
> you're staying in it and having the restrictions enforced (yes, I know I'm
> simplifying
> the issues with 'newrole' and the like)...

  reply	other threads:[~2003-10-11  1:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-10  7:54 [2.7 "thoughts"] V0.3 Frederick, Fabian
2003-10-10  8:01 ` Jens Axboe
2003-10-10  8:13 ` John Bradford
2003-10-10 14:38   ` Rik van Riel
2003-10-10  9:11 ` William Lee Irwin III
2003-10-10 21:17 ` Uncle Jens
2003-10-10 21:59   ` Jeff Sipek
2003-10-10 22:05   ` Valdis.Kletnieks
2003-10-10 22:33     ` Michael Jensen
2003-10-10 23:13       ` Valdis.Kletnieks
2003-10-11  1:54         ` Michael Jensen [this message]
2003-10-11  2:23   ` Greg KH
2003-10-11  2:04 ` ---
2003-10-11  2:13   ` William Lee Irwin III
2003-10-11  2:30     ` ---
2003-10-11  6:24 ` Gabor MICSKO
2003-10-11  6:43   ` Zwane Mwaikambo
2003-10-11 10:56   ` Meelis Roos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1065837246.3f8762bedd4db@secure.millcreeksys.com \
    --to=kernel@millcreeksys.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.