Any chanse to get Openwall port feature back ?

[vovik]

Dear Spender,

first of all - thank you a lot for the really great job.

but could you please place Openwall feature back to the grsec patch ?

Thank you beforehand

Vovik

[spender]

Nope. The openwall non-exec stack is outdated. PaX is much cleaner and does many more things. The only reason I can see why you would want to use the openwall non-exec stack instead of something that is clearly better is because you don't want to take the .5 seconds it takes to turn it off on XFree86 or java or whatever. If we let people take the easy way out and use something that isn't nearly as effective, some people are still going to take that route. Same reason why we won't let you make stupid mistakes with the ACL system. If we let you, you're going to make them. Security is pointless if the administrator can make it useless unknowingly.

-Brad

[DMZ]

Does the openwall non-exec stack function in applications like java where PaX needs to be disabled, or does it silently fail? If it does function as expected, that alone is an undeniable case for enabling it as an additional layer of protection.

As an aside, any thoughts on the performance hit of enforcing a non-write policy beneath the current stack frame?

[spender]

just because java doesn't work with pageexec or segmexec doesn't mean you have to remove all the other things you can enable on it, like randomized mmap, stack, etc. The randomization itself is more powerful than openwall's non-exec stack.

As for the second issue, I don't see how that could be done without causing a huge performance hit. Most likely it would require recompilation of all the software on the system as well. The kernel would probably have to set the protection bits on the stack in such a way that every access would cause a fault, and would then have to be analyzed. This would get very expensive, unless there was some way to offload the work from software.

-Brad

[PaX Team]

Does the openwall non-exec stack function in applications like java where PaX needs to be disabled, or does it silently fail? If it does function as expected, that alone is an undeniable case for enabling it as an additional layer of protection.

what do you mean by 'function'? if you mean whether it can catch code execution attempts on the stack, then it certainly does work, just like PaX.

if you mean whether such attempts occur with java, then the answer is that 'i don't know' as i never tried it (all i know is that with PaX enabled it will be killed because of a code execution attempt in the data segment during some early initialization, so god knows what it would do later on the stack).

if the problem is that you and vovik would like to get a non-exec stack only feature (and leave the heap/etc executable) then it is possible to create with PaX as well, but we're not going to do it because it is against our design. if you or someone else wants to work on it, i can tell you where to look though.

in any case, i really don't see where you're worse off with the more generic non-exec feature than with openwall's stack only one.

As an aside, any thoughts on the performance hit of enforcing a non-write policy beneath the current stack frame?

why would you want to write protect the stack *below* the current frame? if you meant protecting the current frame (presumably to catch write attempts to the saved EIP and all the other goodies), then the answer is what Brad told you: big impact because every write attempt would enter the kernel (page fault) and the offending instruction would have to be analyzed and then emulated. a better approach (at least performance-wise) would be something similar to the DynamoRIO project which operates entirely in userland and has much less impact (although they don't do this kind of stack write checking).

[DMZ]

what do you mean by 'function'? if you mean whether it can catch code execution attempts on the stack, then it certainly does work, just like PaX.

if you mean whether such attempts occur with java, then the answer is that 'i don't know' as i never tried it (all i know is that with PaX enabled it will be killed because of a code execution attempt in the data segment during some early initialization, so god knows what it would do later on the stack).

if the problem is that you and vovik would like to get a non-exec stack only feature (and leave the heap/etc executable) then it is possible to create with PaX as well, but we're not going to do it because it is against our design. if you or someone else wants to work on it, i can tell you where to look though.

Well, no, I've nothing to do with vovik, nor would I want a non-exec stack only feature. I was just interested in whether it would peacefully coexist as an additional feature alongside PaX, and if there were any point in it doing so. I believe Spender's already covered the answer to this, though, thanks.

why would you want to write protect the stack *below* the current frame? if you meant protecting the current frame (presumably to catch write attempts to the saved EIP and all the other goodies),

To be pedantic, then, the lower half of the current frame containing the EIP and below.

the answer is what Brad told you: big impact because every write attempt would enter the kernel (page fault) and the offending instruction would have to be analyzed and then emulated. a better approach (at least performance-wise) would be something similar to the DynamoRIO project which operates entirely in userland and has much less impact (although they don't do this kind of stack write checking).

If you look back over the USENIX archives, for example, you'll find yet more ideas for protecting the stack from this form attack - like encrypting the EIP using an XOR cookie. I wouldn't expect the speed to be anything other than glacial. Again, the point has already been covered, though.

[PaX Team]

If you look back over the USENIX archives, for example, you'll find yet more ideas for protecting the stack from this form attack - like encrypting the EIP using an XOR cookie. I wouldn't expect the speed to be anything other than glacial. Again, the point has already been covered, though.

this kind of protection can be done in plain userland, no need for a kernel patch (+associated overhead). we've been already discussing to explore such protection methods, we'll probably get there in the future (there's still work to do in kernel land). in the meantime people interested in further protection are encouraged to try out the propolice gcc patch.