[Posted only on LKML, this has become humour.]
On Thu, Feb 10, 2005 at 09:03:00PM +0100, David Weinehall wrote:
> On Thu, Feb 10, 2005 at 04:21:49PM +0100, Ingo Molnar wrote:
> >
> > * Jakob Oestergaard <[EMAIL PROTECTED]> wrote:
> > > > PaX cannot be a 'little bit pregnant'. (you might argue t
On Thu, Feb 10, 2005 at 04:21:49PM +0100, Ingo Molnar wrote:
>
> * Jakob Oestergaard <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Feb 10, 2005 at 02:43:14PM +0100, Ingo Molnar wrote:
> > >
> > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > > > the bigger problem is however that you're o
* Jakob Oestergaard <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 10, 2005 at 02:43:14PM +0100, Ingo Molnar wrote:
> >
> > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > > the bigger problem is however that you're once again fixing the
> > > symptoms, instead of the underlying problem - not
On Thu, Feb 10, 2005 at 02:43:14PM +0100, Ingo Molnar wrote:
>
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > the bigger problem is however that you're once again fixing the
> > symptoms, instead of the underlying problem - not the correct
> > approach/mindset.
>
> i'll change my approac
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> the bigger problem is however that you're once again fixing the
> symptoms, instead of the underlying problem - not the correct
> approach/mindset.
i'll change my approach/mindset when it is proven that "the underlying
problem" can be solved. (in
Followup to: <[EMAIL PROTECTED]>
By author:Ingo Molnar <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> This, on the face of it, seems like a ridiculous possibility as the
> chances of that are reverse proportional to the number of bits necessary
> to implement the simplest Turing Machi
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> http://pax.grsecurity.net/docs/pax-future.txt
>
>To understand the future direction of PaX, let's summarize what we
>achieve currently. The goal is to prevent/detect exploiting of
>software bugs that allow arbitrary read/write access to th
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > but what this discussion was about was the _dl_make_stack_executable()
> > function.
>
> the jury is still out on that one, i just don't have the time and beer
> to do the full research that a real exploit writer would do. in
> security, unless
* Julien TINNES <[EMAIL PROTECTED]> wrote:
> But if you consider code injection as in your previous post:
>
> >btw., do you consider PaX as a 100% sure solution against 'code
> >injection' attacks (meaning that the attacker wants to execute an
> >arbitrary piece of code, and assuming the attacke
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > btw., do you consider PaX as a 100% sure solution against 'code
> > injection' attacks (meaning that the attacker wants to execute an
> > arbitrary piece of code, and assuming the attacked application has a
> > stack overflow)? I.e. does PaX avoi
i'm just curious, assuming that all those conditions are true, do you
consider PaX a 100% sure solution against 'code injection' attacks?
(assuming that the above PaX and access-control feature implementations
are correct.) Do you think the upstream kernel could/should integrate it
as a solution a
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > btw., do you consider PaX as a 100% sure solution against 'code
> > injection' attacks (meaning that the attacker wants to execute an
> > arbitrary piece of code, and assuming the attacked application has a
> > stack overflow)? I.e. does PaX avoi
> yes, i agree with you, __libc_dlopen_mode() is an easier target (but not
> _that_ easy of a target, see further down), and your code looks right
actually, line 25 is crap (talk about 'coding while intoxicated' ;-),
it should be 'if (dlerror())' of course. also, you should really try
to run the c
> btw., do you consider PaX as a 100% sure solution against 'code
> injection' attacks (meaning that the attacker wants to execute an
> arbitrary piece of code, and assuming the attacked application has a
> stack overflow)? I.e. does PaX avoid all such attacks in a guaranteed
> way?
your question
btw., do you consider PaX as a 100% sure solution against 'code
injection' attacks (meaning that the attacker wants to execute an
arbitrary piece of code, and assuming the attacked application has a
stack overflow)? I.e. does PaX avoid all such attacks in a guaranteed
way?
Ingo
-
To unsub
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > still wrong. What you get this way is a nice, complicated NOP.
>
> not only a nop but also a likely crash given that i didn't adjust
> the declaration of some_function appropriately ;-). let's cater
> for less complexity too with the following p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
> On Mon, 2005-01-31 at 13:57 +0100, Peter Busser wrote:
>
>>Hi!
[...]
> the paxtest 0.9.6 that John Moser mailed to this list had this gem in
> it:
> @@ -39,8 +42,6 @@
> */
> int paxtest_mode = 1;
>
> +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roman Zippel wrote:
> Hi,
>
> On Thu, 3 Feb 2005, Peter Busser wrote:
>
>
>>- What happens when you run existing commercial applications which have not
>>been compiled using GCC.
>
>
>>From http://pax.grsecurity.net/docs/pax.txt:
>
>The go
> still wrong. What you get this way is a nice, complicated NOP.
not only a nop but also a likely crash given that i didn't adjust
the declaration of some_function appropriately ;-). let's cater
for less complexity too with the following payload (of the 'many
other ways' kind):
[field1 and other
> From http://pax.grsecurity.net/docs/pax.txt:
>
>The goal of the PaX project is to research various defense mechanisms
>against the exploitation of software bugs that give an attacker arbitrary
>read/write access to the attacked task's address space.
>
> Could you please explain how
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > dl_make_stack_executable() will nicely return into user_input
> > > (at which time the stack has already become executable).
> >
> > wrong, _dl_make_stack_executable() will not return into user_input() in
> > your scenario, and your exploit wi
Hi,
On Thu, 3 Feb 2005, Peter Busser wrote:
> - What happens when you run existing commercial applications which have not
> been compiled using GCC.
>From http://pax.grsecurity.net/docs/pax.txt:
The goal of the PaX project is to research various defense mechanisms
against the exploitatio
> > dl_make_stack_executable() will nicely return into user_input
> > (at which time the stack has already become executable).
>
> wrong, _dl_make_stack_executable() will not return into user_input() in
> your scenario, and your exploit will be aborted. Check the glibc sources
> and the implementa
On Wednesday 02 February 2005 23:08, [EMAIL PROTECTED] wrote:
> > and how do you force a program to call that function and then to execute
> > your shellcode? In other words: i challenge you to show a working
> > (simulated) exploit on Fedora (on the latest fc4 devel version, etc.)
> > that does th
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > You can simulate the overflow itself so no need to find any real
> > application vulnerability, but show me _working code_ (or a convincing
> > description) that can call glibc's do_make_stack_executable() (or the
> > 'many ways of doing this'),
> and how do you force a program to call that function and then to execute
> your shellcode? In other words: i challenge you to show a working
> (simulated) exploit on Fedora (on the latest fc4 devel version, etc.)
> that does that.
i don't have any Fedora but i think i know roughly what you're
On Wed, Feb 02, 2005 at 10:18:27PM +1000, [EMAIL PROTECTED] wrote:
> your concerns would be valid if this was impossible to achieve by an
> exploit, sadly, you'd be wrong too, it's possible to force an exploited
> application to call something like dl_make_stack_executable() and then
> execute the
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> your concerns would be valid if this was impossible to achieve by an
> exploit, sadly, you'd be wrong too, it's possible to force an
> exploited application to call something like
> dl_make_stack_executable() and then execute the shellcode. [...]
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi!
> one thing that paxtest didn't get right in the 'kiddie' mode is that
> it still ran with an executable stack, that was not the intention but
> rather an oversight, it'll be fixed in the next release. still, this
> shouldn't leave you with a warm and fuzzy feeling about the security
> of intr
> Umm, so exactly how many applications use multithreading (or otherwise
> trigger the GLIBC mprotect call), and how many applications use nested
> functions (which is not ANSI C compliant, and as a result, very rare)?
i think you're missing the whole point of paxtest. it's not about what
glibc et
On Wednesday 02 February 2005 09:26, Theodore Ts'o wrote:
> On Tue, Feb 01, 2005 at 07:15:49PM -0500, Theodore Ts'o wrote:
> > Umm, so exactly how many applications use multithreading (or otherwise
> > trigger the GLIBC mprotect call),
>
> For the record, I've been informed that the glibc mprotect(
On Wed, 2005-02-02 at 10:35 +0100, Peter Busser wrote:
> Hi!
>
> > Umm, so exactly how many applications use multithreading (or otherwise
> > trigger the GLIBC mprotect call), and how many applications use nested
> > functions (which is not ANSI C compliant, and as a result, very rare)?
> >
> > Do
Hi!
> Umm, so exactly how many applications use multithreading (or otherwise
> trigger the GLIBC mprotect call), and how many applications use nested
> functions (which is not ANSI C compliant, and as a result, very rare)?
>
> Do the tests both ways, and document when the dummy() re-entrant
> func
On Tue, Feb 01, 2005 at 07:15:49PM -0500, Theodore Ts'o wrote:
> Umm, so exactly how many applications use multithreading (or otherwise
> trigger the GLIBC mprotect call),
For the record, I've been informed that the glibc mprotect() call
doesn't happen in any modern glibc's; there may have been o
On Tue, Feb 01, 2005 at 10:44:39AM +0100, Peter Busser wrote:
> Again, this is a *simulation* of the way real-life applications could
> interact
> with the underlying system. Again people complained that the results shown
> were not accurate. And that has been fixed.
>
> I am well aware of comp
El Tue, 1 Feb 2005 10:44:39 +0100 Peter Busser <[EMAIL PROTECTED]> escribió:
> > which is clearly there to sabotage any segmentation based approach (eg
> > execshield and openwall etc); it cannot have any other possible use or
> > meaning.
>
> Ah, so you are s
On Tuesday 01 February 2005 12:46, you wrote:
> * Peter Busser <[EMAIL PROTECTED]> wrote:
> > > ok the paxtest 0.9.5 I downloaded from a security site (not yours) had
> > > this gem in:
> > >
> > > + do_mprotect((unsigned long)argv & ~4095U, 4096,
> > > PROT_READ|PROT_WRITE|PROT_EXEC)
* Peter Busser <[EMAIL PROTECTED]> wrote:
> > ok the paxtest 0.9.5 I downloaded from a security site (not yours) had
> > this gem in:
> > + do_mprotect((unsigned long)argv & ~4095U, 4096,
> > PROT_READ|PROT_WRITE|PROT_EXEC);
> > which is clearly there to sabotage any segmentation
gt;
> which is clearly there to sabotage any segmentation based approach (eg
> execshield and openwall etc); it cannot have any other possible use or
> meaning.
Ah, so you are saying that I sabotaged PaXtest? Sorry to burst your bubble,
but the PaXtest tests are no real attacks. They are *si
As you may or may not know, I am the author of PaXtest. Please tell me what a
> ``desabotaged'' version of PaXtest exactly is. I've never seen a
> ``sabotaged'' PaXtest and I'm interested in finding out who sabotaged it and
> for what purpose.
>
>
#x27; version of PaXtest exactly is. I've never seen a
``sabotaged'' PaXtest and I'm interested in finding out who sabotaged it and
for what purpose.
Come to think of it, sabotaging a test program seems to be a rather stupid
concept. I mean, if you don't like the result
42 matches
Mail list logo
