From: Ingo Molnar <mingo@elte.hu>
To: Gabor MICSKO <gmicsko@szintezis.hu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Test] exec-shield-2.6.0-test5-G2 vs. paxtest & libsafe
Date: Sat, 27 Sep 2003 22:30:32 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.56.0309272220020.25371@localhost.localdomain> (raw)
In-Reply-To: <1064693831.1792.9.camel@sunshine>
On Sat, 27 Sep 2003, Gabor MICSKO wrote:
> > redhat.com/~mingo/exec-shield/exec-shield-2.6.0-test5-G3
> > redhat.com/~mingo/exec-shield/exec-shield-2.6.0-test5-bk12-G3
>
> Yes, this patch really better.
> Linux sunshine 2.6.0-test5-exec-shield-nptl #3 SMP 2003. sze. 27.,
> http://www.research.avayalabs.com/project/libsafe/src/libsafe-2.0-16.tgz
[all libsafe exploits fail - good.]
> http://pageexec.virtualave.net/paxtest-0.9.1.tar.gz
> sunshine:/home/trey/exec/paxtest-0.9.1# ./paxtest
> It may take a while for the tests to complete
> Test results:
> Executable anonymous mapping : Killed
> Executable bss : Killed
> Executable data : Killed
> Executable heap : Killed
> Executable stack : Killed
ok.
> Executable anonymous mapping (mprotect) : Killed
this is a testsuite bug i think - anonmap.c mprotanon.c differ in nothing
but the name string of the test.
> Executable bss (mprotect) : Vulnerable
> Executable data (mprotect) : Vulnerable
> Executable heap (mprotect) : Vulnerable
> Executable shared library bss (mprotect) : Vulnerable
> Executable shared library data (mprotect): Vulnerable
> Executable stack (mprotect) : Vulnerable
these are 'vulnerable' by design. There can be legitimate reasons to
mprotect() any of these regions. And if an attacker has enough control
over the target to execute mprotect() with precise arguments then the game
is mostly over anyway. Does anyone know the rationale of these mprotect()
tests?
> Return to function (strcpy) : Vulnerable
> Return to function (memcpy) : Vulnerable
it needs gcc level changes to change the stackframe layout - out of the
scope of exec-shield.
> Writable text segments : Vulnerable
this is a variant of the mprotect() tests too - so possible by design.
Ingo
prev parent reply other threads:[~2003-09-27 20:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-27 16:05 Gabor MICSKO
2003-09-27 18:02 ` Ingo Molnar
2003-09-27 18:13 ` Breno
2003-09-27 20:17 ` Gabor MICSKO
2003-09-27 20:24 ` Onstream DI-30 locks up PC when in use Stef van der Made
2003-09-28 10:20 ` Ookhoi
2003-09-27 20:30 ` Ingo Molnar [this message]
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=Pine.LNX.4.56.0309272220020.25371@localhost.localdomain \
--to=mingo@elte.hu \
--cc=gmicsko@szintezis.hu \
--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
all inboxes | Powered by JetHome®