Am 29.07.2017 um 14:28 schrieb Timo Paulssen:
Actually what they are refering to is that dyncall and libffi both
require an executable stack. We can't get around that without making
changes to libffi and dyncall, sadly.
Ah okay, that was outside the bounds of my knowledge.
And I agree it's unfortunate.
OTOH if these calls are constructed at runtime, we can't avoid W|X
memory. The best we can do is to limit its size, and move it off the
normal call stack so that forcing an array overflow doesn't instantly
give the attacker access to an executable area of which he can control
the content.
Question is: Is Perl's bytecode guaranteed to never smash an array
bound? E.g. JVM bytecode does an array bounds check before any access.
There's a simlar question about object type mixups, which can cause code
to access offsets beyond the end of the object. (The JVM prevents this
kind of object bound smashing via type validation, mostly at code load
time and the remaining cases when dereferencing.)
