3 ms·

From linked article "It seems that the cause was apache and mod_php sending back un-interpreted source code as opposed to output, due to either a server misconf

by elwell 13y ago

From linked article "It seems that the cause was apache and mod_php sending back un-interpreted source code as opposed to output, due to either a server misconfiguration or high load (this is a known issue)." Does anyone know what he is referring to when he says this can happen via high load?

smsm42 13y ago
It is a myth. High load has nothing to do with it. However if you configure apache wrongly, it will serve .php files as text. Only connection to load is if you have one broken server among N proper ones, a number of times that the broken one is hit depends on load - I.e. on low load, it may be configured so that it is never hit at all. I guess the story about apache serving php source under high load came from the idea tha Facebook is a high load site (true) and they couldn't just have made as obvious screwup as misconfiguring a production server (false) so it must be apache/php bug that happens only in high load sites (false)
- nikcub 13y ago
  this was a real issue, here is the bug: https://bugs.php.net/bug.php?id=26810 https://bugs.php.net/bug.php?id=26810 there were many related bugs as well. it didn't get fixed for a while, and when it was fixed it was over a number of revisions and wasn't tagged.
  - deleted 13y ago
    [deleted]
  - smsm42 13y ago
    That issue was fixed 3 years before (Jan 2004) and from what I can see only happened in configs which use +x bit or config values to turn php engine on and off, and didn't really depend on load on these too much either - it's just load made it more probable you will hit the right sequence in the same process randomly, but if you know what to hit, it could be done on any load. So it would be correct to say "there was a bug 3 years ago which in certain configurations made mod_php serve source after certain sequence of requests". It was never happening just "due to high load", as far as I can see. And as far as I know (and nobody so far presented any evidence to the contrary, AFAIK) Facebook case had nothing to do with it anyway. It would be really weird for Facebook to run random 3-years-old PHP in production too.
nikcub 13y ago
It was a rare bug in the 4.2.x and 4.3.x branches of the Apache module running on 2.0.x. The real way this code was leaked was via a plain text version of the file being stored on the server that the hacker found by trying a bunch of URLs I was speculating at the time, and had recent experience with the bug where source code would be exposed. I found out a little later how it was actually leaked, but then forgot all about it.

by elwell 13y ago

smsm42 13y ago

It is a myth. High load has nothing to do with it. However if you configure apache wrongly, it will serve .php files as text. Only connection to load is if you have one broken server among N proper ones, a number of times that the broken one is hit depends on load - I.e. on low load, it may be configured so that it is never hit at all. I guess the story about apache serving php source under high load came from the idea tha Facebook is a high load site (true) and they couldn't just have made as obvious screwup as misconfiguring a production server (false) so it must be apache/php bug that happens only in high load sites (false)

nikcub 13y ago
this was a real issue, here is the bug: https://bugs.php.net/bug.php?id=26810 https://bugs.php.net/bug.php?id=26810 there were many related bugs as well. it didn't get fixed for a while, and when it was fixed it was over a number of revisions and wasn't tagged.
- deleted 13y ago
  [deleted]
- smsm42 13y ago
  That issue was fixed 3 years before (Jan 2004) and from what I can see only happened in configs which use +x bit or config values to turn php engine on and off, and didn't really depend on load on these too much either - it's just load made it more probable you will hit the right sequence in the same process randomly, but if you know what to hit, it could be done on any load. So it would be correct to say "there was a bug 3 years ago which in certain configurations made mod_php serve source after certain sequence of requests". It was never happening just "due to high load", as far as I can see. And as far as I know (and nobody so far presented any evidence to the contrary, AFAIK) Facebook case had nothing to do with it anyway. It would be really weird for Facebook to run random 3-years-old PHP in production too.

nikcub 13y ago

It was a rare bug in the 4.2.x and 4.3.x branches of the Apache module running on 2.0.x. The real way this code was leaked was via a plain text version of the file being stored on the server that the hacker found by trying a bunch of URLs I was speculating at the time, and had recent experience with the bug where source code would be exposed. I found out a little later how it was actually leaked, but then forgot all about it.