[chrismeller]

It’s basically the list the master process keeps of the worker processes it has spun up. The workers can report back some stats that the master tracks about each. Apparently something in that report back process could be exploited to run arbitrary code.

[yrro]

Who on earth doesn't run CGI scripts, etc., as a separate user to the one that their apache workers run as?

[chrismeller]

While it might not be relevant to this particular issue (though it might, I didn’t dig too deeply), there’s a long standing history of running everything inline with Apache. I mean look at mod_php... sure we’ve all (hopefully) learned our lesson there, but it’s a hell of a hole to dig back out of as long as things keep working.

It’s one of the reasons I’m always suspicious any time I run into a company that runs Apache rather than nginx or one of the many other alternatives. There is absolutely nothing wrong with running Apache, but it always makes me wonder exactly why they are... is it because they’ve got this one app that won’t run on anything else because of crap like this? More often than not...

[rkeene2]

I think it's been very common for 15 years to use Apache's "suexec" to run each CGI process as the individual user rather than as a user related to Apache.

There's also suPHP which allows you to do the same thing for PHP processes.

[yrro]

Precisely. There's also PHP-FPM. I am astounded that people still rely on mod_php!

[tedunangst]

Probably most people. Who uses setuid CGI scripts?

[yrro]

You can't really have a setuid "script" anyway. But you can, at the bare minimum, launch CGI scripts via suEXEC. This prevents them from being able to attack the httpd worker processes, since they won't be running as the same user.

[arbitrage]

Welcome to reality. Please leave your principles at the door, you won't be needing them here.

[shawnz]

Would that actually mitigate this problem? It's not clear to me.

[yrro]

A process running as another user won't be able to modify the memory of the apache worker process.