e randomisation (ET_DYN) : 12 bits (guessed)
Shared library randomisation test: 12 bits (guessed)
Stack randomisation test (SEGMEXEC) : 17 bits (guessed)
Stack randomisation test (PAGEEXEC) : 17 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to funct
work on that. also, you did
break userland yourself as well, otherwise how would you explain the
patches RedHat made to the XFree86 server? see, there're just cases
when userland is plain wrong and must be fixed. on another note, how
did you get java to work under Exec-Shield while mai
> >first of all, it's multithreaded. [...]
>
> paxtest does not link to libpthread, nor does it create threads, at all.
> How can you claim it's multithreaded?
i did not. if you quote my post like this:
>let me get back to the topic of java as i promised above. java
>is a nice animal
> > [...] also, you did break userland yourself as well, otherwise how would
> > you explain the patches RedHat made to the XFree86 server?
>
> actually, unmodified XFree86 works just fine. It will have an executable
> stack but it will work out of box - so no app was broken.
false! my unmodified
> You are trying to make a big fuss about this for no good reason.
Ingo, please. it was *you* who objected to PaX's default enforcement
policy because it broke Linus's rule. yet you did the same with your
own default *and* contested the fact that you hadn't broken anything.
i don't have a problem
> > [...] randomization serves NO purpose in the grand scheme, it does not
> > provide guaranteed protection against the PaX attack model (arbitrary
> > read/write access to the address space). [...]
>
> there's another, practical aspect of address-space randomization which i
> find to be the most
> > It is in fact a simulation of a multithreaded application. [...]
>
> The test incorrectly assumes that thread stacks are executable. I suspect
> we both agree that it's desirable to have thread stacks non-executable as
> well.
while i agree with you on this one, it is in stark contrast to wha
> "The test incorrectly assumes that thread stacks are executable" is not
> equivalent to "thread stacks are non-executable". And there's no conflict
> in what i say above.
ok, i was quoting too much and you interpreted the wrong part. the bit
i was referring to is this:
> I suspect we both agree
8 matches
Mail list logo
