Topic: Segmentation Fault on Custom 413

[balia]

First, I added the following lines to my .htaccess file:

[James Blond]

Enable the PHP error log in your php.ini and see what causes PHP to crash.

[balia]

I do have log_errors=On and error_log=logFile both in php.ini and in the php code itself using the ini_set() function.
However, in this case there are no errors logged by PHP, jut the segmentation error in the Apache log.

[James Blond]

Do you have the core dump?

[balia]

No I don't. I've seen several forums explaining how to generate it. Many say I need to recompile apache to get the dump.
Would you be able to point the best resource explaining how to do this?

[James Blond]

As far as I know you don't need to recompile apache.

Just configure the path like

[balia]

Sorry for the late reply.

Did the following:
- Added CoreDumpDirectory /tmp/apacheDump to apache2.conf
- mkdir -p /tmp/apacheDump
- chmod 777 /tmp/apacheDump
- Restarted apache

Reproduced the error.

In error.log, I have the following line:

[balia]

Tried to follow the instructions in the following post:
http://sysadmin.carlusgg.com/?p=197

Installed apache2-dbg and php5-dbg

But still no dump ...

[balia]

Also tried the following post:
https://stackoverflow.com/questions/7745578/notice-child-pid-xxxx-exit-signal-segmentation-fault-11-in-apache-error-lo

[James Blond]

For having the correct data, you need to reduce apache to a single process

[balia]

I added the following to apache2.conf

StartServers 1
MinSpareServers 1
MaxSpareServers 1
MaxClients 1

After restarting apache, when I run ps aux, I still get 6 apache processes running, one owned by root and 5 by www-data

I only found one post with a similar problem:
https://stackoverflow.com/questions/25651659/how-do-i-configure-apache-to-only-fork-one-child-process-worker
But it doesn't have a good answer.

[James Blond]

Sorry I forgot about this, but there is a command line option -X

example

[gmoniker]

Hello Balia,

Coredumps on Ubuntu 12.04 can get intercepted by the apport program. You can see if something like apport is set by doing:

[gmoniker]

It just so happens that I have been looking into the Apache handler for PHP after having some segfaults in a different situation, see https://bugs.php.net/bug.php?id=68486 for that.

Basically what happens, is the PHP handler in the case of 413 errors that happened when you called a PHP script tries to reuse the execution engine that was started for that first script. The reasoning will have been that it was needed to avoid throwing a 413 error all over again and ending up with a precooked Apache error message. And maybe this was true sometime in the past.

But the script that you install as the ErrorDocument for 413 is then starting in an improper environment. Adding symbols just about succeeds and calling echo, but anything that introspects the symbol table like your call to defined() will crash the execution environment.

You will see that it does function if you call some static html and cause a 413.

The patch that is available at the bug report I mentioned will solve the segfault for this case also.

However there still is another thing which makes Entity too large in Apache 2.4 very strange if PHP is active. If you call a php script with too large a request body for example, it will show the ErrorDocument whatever it is, but then goes on to happily run your PHP script. Even though the request body is unset, this seems unwanted behaviour to me and it doesn't happen if you call a static html file or in any of those cases with Apache 2.2. Nor does it happen with a header that is too long.

So, in short with Apache 2.4 and PHP you cannot depend on a LimitRequestBody to stop PHP from running, and you can experience segfaults when you call a PHP script and set a PHP script as 413 handler (In Apache 2.2 as well).

[Jan-E]

In case some of you experience segfaults on Windows: all my builds are patched with this oneliner:
https://bugs.php.net/patch-display.php?bug_id=68486&patch=sapi_apache2.gmoniker.patch&revision=latest

I applied the patch last Friday. See http://www.apachelounge.com/viewtopic.php?t=6359 for my builds

[balia]

Thank you for all the responses and very sorry for the delay in processing them.

[James Blond]
I stopped apache2 : service apache2 stop

[Jan-E]

Try upgrading to PHP 5.6.8. This version has gmoniker's patch
https://github.com/php/php-src/commit/809610f5ea38a83b284e1125d1fff129bdd615e7

[balia]

Sorry; this issue on the back burner for a while.
Looking at it again, I updated PHP from v5.6.6 to v5.6.10.
This did not resolve anything: the segmentation fault didn't disappear.

I resolved the issue as follows:
Reading through the Apache documentation gave me some clues.
http://httpd.apache.org/docs/2.2/custom-error.html

Unlike 404, 413.php was not a replacement script for the original script (in the case of a 404 error, there is obviously no original script).
When 413.php ends, execution doesn't stop there.
The original uploading script is called again (when no segmentation fault occurs).
$_POST and $_FILE are empty, and there is no obvious ways for the original script to know that an error occurred.
In addition nothing in the environment variables points to an error.

413.php is just provided as a replacement for the built-in 413 error message.
It allows to echo a different 413 error message at the top of the HTML page, but not much more.
Any non "elementary" code in 413.php generates a segmentation fault.
For example, 413.php doesn't accept any function call.
Calling any function such as define() or any text function results in a segmentation fault.
Only echos and basic assignment operators seem acceptable.

Fortunately, global variables can be defined in 413.php. These global variables can be picked up by the original uploading script.

Another important consideration, is that 413.php must echo something before exiting.
If there are no echos and 413.php ends with exit(); or exit(integer); then a segmentation fault will occur.
I chose to end 413.php with exit(' ');
The blank space seems so far to be a good compromise to prevent the browser from getting in quirk mode.

Obviously, segmentation faults are not the best way to communicate with developers and maybe this can be addressed in the future by the Apache team.
It is not clear why you would restrict non "elementary" PHP code in 413.php and this is not explained in the documentation.

On a last note, for very large files, Firefox keeps trying to upload the file and never returns a 413 error.
See https://github.com/freedomofpress/securedrop/issues/992

[James Blond]