public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox