Alexey Zakhlestin schrieb: > the problem is, that, in this case, code is not broken. it is not an > error to use large stack. > it is an error to let someone use the low-level side-effects of a > problem in a high-level language. Uhmm you only look at the MOPB #2 issue. The main point of this whole thread is however the performance impact through the #1 issue that does not depend on stack usage, but allows PHP userspace code to execute arbitrary machine code.
The problem here is that some voices inside the PHP team and community claim that you can takeover the system through the execution of high level PHP code anyway and therefore using a local PHP vulnerability to execute arbitrary machine code would not be an issue. If you see it this way there is actually no reason to do this performance impact. However it should be obvious that I see this all a little bit different, because I think about defense in depth and realise that to attack tightly secured systems you NEED direct memory manipulation and/or execute arbitrary machine code. For example to get around non-executable HEAP situation you first need to poke the right offsets in memory to "reenable" the dl() function (NOT possible with plain PHP code), find some writeable diskspace, dump a shared library there and load it. From there you can execute whatever kernel exploit you want, to get for example out of the chroot, to disable SELINUX... And here is the problem with the OS hardening argument of the PHP developers. OS hardening is useless if I can use exploits in PHP to simply disable/get around this hardening. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
