* [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
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
* [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
> 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
> 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?
your question is
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
* [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 avoid all
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
* 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 attacked
* [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 proven
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
* [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
-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
> 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
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 PaX
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
-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 goal of the PaX
* [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 payload
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
* [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
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
> > 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
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
* [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'),
* [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_
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 that.
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 implementation of
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 exploitation
* [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 will be
> 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
> 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
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
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)?
> >
> >
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
>
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
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
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
function
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 the tests
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() call
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
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
* [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/
* [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. [...]
and
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
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 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
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 saying that I sabotaged PaXtest?
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,
> > >
* 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
On Monday 31 January 2005 17:41, you wrote:
> On Mon, 2005-01-31 at 13:57 +0100, Peter Busser wrote:
> > Hi!
> >
> > > I'm not entirely happy yet (it shows a bug in mmap randomisation) but
> > > it's way better than what you get in your tests (this is the
> > > desabotaged
> > > 0.9.6 version
On Monday 31 January 2005 17:41, you wrote:
On Mon, 2005-01-31 at 13:57 +0100, Peter Busser wrote:
Hi!
I'm not entirely happy yet (it shows a bug in mmap randomisation) but
it's way better than what you get in your tests (this is the
desabotaged
0.9.6 version fwiw)
ok the paxtest
* 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 based
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);
which is
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 saying that I sabotaged PaXtest? Sorry to burst
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
>>Why not compromise, if possible? 256M of randomization, but move the
>>split up to 3.5/0.5 gig, if possible. I seem to recall seeing an option
>>(though I think it was UML) to do 3.5/0.5 before; and I'm used to "a
On Mon, 2005-01-31 at 13:57 +0100, Peter Busser wrote:
> Hi!
>
> > I'm not entirely happy yet (it shows a bug in mmap randomisation) but
> > it's way better than what you get in your tests (this is the
> > desabotaged
> > 0.9.6 version fwiw)
>
> As you may or may not know, I am the author of
Hi!
> I'm not entirely happy yet (it shows a bug in mmap randomisation) but
> it's way better than what you get in your tests (this is the
> desabotaged
> 0.9.6 version fwiw)
As you may or may not know, I am the author of PaXtest. Please tell me what a
``desabotaged'' version of PaXtest exactly
> Why not compromise, if possible? 256M of randomization, but move the
> split up to 3.5/0.5 gig, if possible. I seem to recall seeing an option
> (though I think it was UML) to do 3.5/0.5 before; and I'm used to "a
> little worse" meaning "microbenches say it's worse, but you won't notice
>
On Sat, Jan 29, 2005 at 01:10:54PM -0500, John Richard Moser wrote:
> > Yeah, I guess your extensive compiler internals experience and knowledge
> > of gcc internals weights a lot more than the opinion of the gcc team..
> >
>
> I read "implementation" as "the way it's implemented," not as "the
>
On Sat, 29 Jan 2005, John Richard Moser wrote:
Did I miss the target? *Aims in the other direction then?*
Depends. If you aimed to kick your own arse, you did pretty well.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Hellwig wrote:
> On Sat, Jan 29, 2005 at 12:49:05PM -0500, John Richard Moser wrote:
>
>>>The ideas in IBM's ProPolice changes are good and worth
>>>implementing, but the current implementation is bad.
>>>
>>
>>Lies. I've read the paper
On Sat, Jan 29, 2005 at 12:49:05PM -0500, John Richard Moser wrote:
> > The ideas in IBM's ProPolice changes are good and worth
> > implementing, but the current implementation is bad.
> >
>
> Lies. I've read the paper on the current implementation, it's
> definitely good. It only operates on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jakub Jelinek wrote:
> On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
>
>>Finally, although an NX stack is nice, you should probably take into
>>account IBM's stack smash protector, ProPolice. Any attack that can
>>evade SSP
On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
> Finally, although an NX stack is nice, you should probably take into
> account IBM's stack smash protector, ProPolice. Any attack that can
> evade SSP reliably can evade an NX stack; but ProPolice protects from
> other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
> On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
>
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>
>>
>>Arjan van de Ven wrote:
>>
I actually just tried to paxtest a fresh Fedora Core 3,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
> On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
>
>>-BEGIN PGP SIGNED MESSAGE-
>
>
>>These are the only places mprotect() is mentioned; a visual scan
>>confirms no trickery:
>>
>>if( fork()
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Arjan van de Ven wrote:
> >>I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
> >>that I installed, and it FAILED every test. After a while, spender
>
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> These are the only places mprotect() is mentioned; a visual scan
> confirms no trickery:
>
> if( fork() == 0 ) {
> /* Perform a dirty (but not unrealistic) trick to
> I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
> that I installed, and it FAILED every test. After a while, spender
> reminded me about PT_GNU_STACK. It failed everything but the Executable
> Stack test after execstack -c *. The randomization tests gave
>
I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
that I installed, and it FAILED every test. After a while, spender
reminded me about PT_GNU_STACK. It failed everything but the Executable
Stack test after execstack -c *. The randomization tests gave
13(heap-etexec),
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
These are the only places mprotect() is mentioned; a visual scan
confirms no trickery:
if( fork() == 0 ) {
/* Perform a dirty (but not unrealistic) trick to circumvent
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
that I installed, and it FAILED every test. After a while, spender
reminded me about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
These are the only places mprotect() is mentioned; a visual scan
confirms no trickery:
if( fork() == 0 ) {
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
On Sat, 2005-01-29 at 11:21 -0500, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
that I installed,
On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
Finally, although an NX stack is nice, you should probably take into
account IBM's stack smash protector, ProPolice. Any attack that can
evade SSP reliably can evade an NX stack; but ProPolice protects from
other overflows.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jakub Jelinek wrote:
On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
Finally, although an NX stack is nice, you should probably take into
account IBM's stack smash protector, ProPolice. Any attack that can
evade SSP reliably
On Sat, Jan 29, 2005 at 12:49:05PM -0500, John Richard Moser wrote:
The ideas in IBM's ProPolice changes are good and worth
implementing, but the current implementation is bad.
Lies. I've read the paper on the current implementation, it's
definitely good. It only operates on C/C++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Hellwig wrote:
On Sat, Jan 29, 2005 at 12:49:05PM -0500, John Richard Moser wrote:
The ideas in IBM's ProPolice changes are good and worth
implementing, but the current implementation is bad.
Lies. I've read the paper on the current
On Sat, 29 Jan 2005, John Richard Moser wrote:
Did I miss the target? *Aims in the other direction then?*
Depends. If you aimed to kick your own arse, you did pretty well.
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as
On Sat, Jan 29, 2005 at 01:10:54PM -0500, John Richard Moser wrote:
Yeah, I guess your extensive compiler internals experience and knowledge
of gcc internals weights a lot more than the opinion of the gcc team..
I read implementation as the way it's implemented, not as the
quality of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alright, I'll bite.
Someone told me to bring this up after reading all the complaints about
breakage, so again we get back to PaX. I'm more interested in "this
patch is bad" than "PaX is better" for this argument, but whatever.
Compatibility has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rik van Riel wrote:
> On Thu, 27 Jan 2005, John Richard Moser wrote:
>
>> Arjan van de Ven wrote:
>
>
Is this one any worse?
>>>
>>> yes.
>>>
>>> oracle, db2 and similar like to mmap 2Gb or more *in one chunk*.
>>
>>
>> Special case?
>
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar wrote:
> * Paulo Marques <[EMAIL PROTECTED]> wrote:
>
>
>>I really shouldn't feed the trolls, but this must be the most silly
>>piece of code I saw on this mailing list in a very long time (and
>>there have been some good examples over
On Thu, 27 Jan 2005, John Richard Moser wrote:
Arjan van de Ven wrote:
Is this one any worse?
yes.
oracle, db2 and similar like to mmap 2Gb or more *in one chunk*.
Special case?
Absolutely, but ...
Can I get this put into perspective? How much more important is "Good"
randomization versus "not
TECTED]>, linux-kernel@vger.kernel.org,
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Patch 4/6 randomize the stack pointer
* Jirka Kosina <[EMAIL PROTECTED]> wrote:
Also, besides security implications of stack randomization, there is
one more aspect that should not be forgott
* Paulo Marques <[EMAIL PROTECTED]> wrote:
> I really shouldn't feed the trolls, but this must be the most silly
> piece of code I saw on this mailing list in a very long time (and
> there have been some good examples over time).
yeah.
> The stack randomization doesn't prevent some sort of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paulo Marques wrote:
> John Richard Moser wrote:
>
>> In other words, no :)
>>
>> Here's self-exploiting code to discover its own return address offset
>> and exploit itself. It'll lend some insight into how this stuff works.
>
>
> I really
John Richard Moser wrote:
In other words, no :)
Here's self-exploiting code to discover its own return address offset
and exploit itself. It'll lend some insight into how this stuff works.
I really shouldn't feed the trolls, but this must be the most silly
piece of code I saw on this mailing
Horst von Brand wrote:
Julien TINNES <[EMAIL PROTECTED]> said:
Not very important but ((get_random_int() % 4096) << 4) could be
optimized into get_random_int() & 0xFFF0.
Check first if the compiler doesn't do it by itself.
The compiler cannot guess that get_random_int() gives a random result.
Horst von Brand wrote:
Julien TINNES [EMAIL PROTECTED] said:
Not very important but ((get_random_int() % 4096) 4) could be
optimized into get_random_int() 0xFFF0.
Check first if the compiler doesn't do it by itself.
The compiler cannot guess that get_random_int() gives a random result.
%4096
John Richard Moser wrote:
In other words, no :)
Here's self-exploiting code to discover its own return address offset
and exploit itself. It'll lend some insight into how this stuff works.
I really shouldn't feed the trolls, but this must be the most silly
piece of code I saw on this mailing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paulo Marques wrote:
John Richard Moser wrote:
In other words, no :)
Here's self-exploiting code to discover its own return address offset
and exploit itself. It'll lend some insight into how this stuff works.
I really shouldn't feed
1 - 100 of 192 matches
Mail list logo
