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)...
next prev parent 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