
Exploiting memory corruption bugs in PHP - 2510c39011c5
http://www.inulledmyself.com/2015/02/exploiting-memory-corruption-bugs-in_23.html
======
pearjuice
Theoretically this is a big problem on shared hosts, no? Since they share the
same memory, you could potentially compromise other users of the host? Or is
it locked at a virtual level?

~~~
maplesyrupguy
I believe it would depend on how PHP is setup for that particular host. If
each user has their own executable, they're more than likely fine. If they
share one, then it's definitely a problem.

------
adaml_623
So how is that a 'remote' exploit? Or is the definition of remote that you can
already execute code on the server?

~~~
deweller
If your app takes user input (like from a POSTed form variable or a URL
parameter) and then calls unserialize on it, it becomes a remote exploit.

~~~
noir_lord
To be fair, If your program takes user input and calls unserialize on it then
whoever wrote the program is an idiot at best __* .

> Warning

> Do not pass untrusted user input to unserialize(). Unserialization can
> result in code being loaded and executed due to object instantiation and
> autoloading, and a malicious user may be able to exploit this. Use a safe,
> standard data interchange format such as JSON (via json_decode() and
> json_encode()) if you need to pass serialized data to the user.

 __* Unless there is an absolute and specific case where you would need to do
this, there might be but I 'm struggling to think of one.

~~~
feld
It's a good thing there's no poorly written PHP in the wild and everyone is
really, really good at patching PHP immediately upon update. /s

edit: [http://blog.ircmaxell.com/2014/12/php-install-
statistics.htm...](http://blog.ircmaxell.com/2014/12/php-install-
statistics.html)

