I've recently been fuzzing the PHP interpreter, and took a UaF bug all the way from crashing-sample to weaponized code execution. Here is the first of several blog posts I plan to write about the process. https://blog.jmpesp.org/2020/01/fuzzing-php-with-domato.html …
-
-
Replying to @Rewzilla
Very cool stuff! But when you say "weaponized", that sort of implies there's a vulnerability that can be attacked. Are there scenarios where a PHP author doesn't already have code execution, e.g. via system() or exec()?
2 replies 0 retweets 0 likes -
Replying to @wdormann
Maybe a generous use of the term. :) But yes, often settings like disable_functions will be enabled, restricting what the script can do. This bypasses those restrictions.
1 reply 0 retweets 1 like -
Replying to @Rewzilla
Thx. My understanding was that even the PHP folks themselves claim that locking down what you can do with PHP (i.e. a shared server with an untrusted PHP dev) using PHP itself isn't viable. But perhaps this isn't an accurate representation of what's expected in the real world.pic.twitter.com/JWlM95d71F
1 reply 0 retweets 1 like -
Replying to @wdormann
Correct, and I tend to agree in theory. In fact this isn't even classified as a "security" bug due to the need for custom code. Makes sense. That said, as long as disable_functions is offered, users should reasonably expect it to be effective. This violates that control.pic.twitter.com/yVPo4OYiR0
1 reply 0 retweets 1 like
Indeed. If safe_mode doesn't even exist anymore because it's not feasible, it seems a little counter-intuitive that disable_functions is still advertised as fine, and a viable way of preventing the use of unsafe PHP capabilities. https://www.php.net/manual/en/ini.core.php#ini.disable-functions … https://www.php.net/manual/en/ini.sect.safe-mode.php#ini.safe-mode …
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.