[Apache] [[email protected]] LD_LIBRARY_PATH issue in 2.2.22 and earlier

I got caught the same way in March (re PCI scanning). Guess my guy is more
up to date than yours!

There should be no reason that I found not to update to 2.4.2 BUT BE
CAREFUL OF THE CONFIG FILE CHANGES! For example the "order deny allow"
format directives no longer work in 2.4.*. There are a few other changes.

Also, do not be tempted to update to PHP 5.4.0 as it will cause segfaults
in all the child processes for reasons that escape me completely. Use a
5.3.x version. This may be my problem but someone on this list was able to
confirm the issue and said that it is a PHP issue. It may be resolved by
now.

Hope that's useful.

John
======================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

The upgrade to 2.4.2 is non-trivial in my environment (particularly due to the config changes) and if 2.2.23 is going to patch it, I'd just as soon wait. Thus the request for some guess at release date.

But that's likely not forthcoming, so I'll reconsider the upgrade.

---

Bibliopolis, LLC
Berkeley | Pittsburgh

http://www.bibliopolis.com

That's a little bit unclear.
In their release announcement they said it is fixed
"Fixed bug #61172 (Add Apache 2.4 support)."
<http://www.php.net/archive/2012.php#id2012-04-26-1>

But in the changelog #61172 is only listed for 5.3.11,
but not for 5.4.1.

Hendrik

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

I think this memo is really directed to me and the comment about PHP 5.4.0
not working with Apache 2.4.1 and 2.4.2.

If so, what happened (documented in a closed request to this list) was that
I compiled both these Apache versions in late March against PHP 5.4.0 which
was the latest version at the time. Haven't looked since. Apache worked
fine but the PHP scripts were displayed in raw form on the client instead of
the expected result. These are scripts that have been working properly for
years. I finally discovered from the Apache error log that whenever a PHP
script was processed one of the child processes segfaulted. I wrote up a
request to this forum and someone was able to confirm it was a PHP problem
so I reported it to their help but was unable to figure out how to get the
documentation that was required (traces and so forth) so the report was
closed.

What happened beyond that I can't say. Hope that is useful.

Regards,

John
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

The actual text is, "envvars (aka envvars-std) in the Apache HTTP Server
before 2.4.2 places a zero-length directory name in the LD_LIBRARY_PATH,
which allows local users to gain privileges via a Trojan horse DSO in
the current working directory during execution of apachectl."

And envvars-std (envvars) appears to only be used by apachectl. So,
instead of upgrading, what about changing the owner of apachectl to root
and the permissions to 700? Then tell your auditor that you have
implemented a compensating control for CVE-2012-0883 such that apachectl
can only be run by the trusted root user.

Am I misunderstanding the vulnerability?

Or, alternatively, edit /usr/sbin/envvars and/or apachectl to fix
LD_LIBRARY_PATH, if it is in fact being handled insecurely on your
system (it appeared to be fine on the two older systems where I checked
for this vulnerability).

Modify your installed envvars (and envvars-std) script and apachectl (or equivilant
script provided by your application vendor) to ensure that this code is changed;


@@ -18,6 +18,10 @@
#
# This file is generated from envvars-std.in
#
-LD_LIBRARY_PATH="/path/to/httpd/lib:$LD_LIBRARY_PATH"
+if test "x$LD_LIBRARY_PATH" != "x" ; then
+ LD_LIBRARY_PATH="/path/to/httpd/lib:$LD_LIBRARY_PATH"
+else
+ LD_LIBRARY_PATH="/path/to/httpd/lib"
+fi
export LD_LIBRARY_PATH
#

On oddball platforms this may be LIBPATH or SHLIB_PATH instead of LD_LIBRARY_PATH.
If your platform's apachectl script invokes envvars, you are done. If it doesn't,
there may be an insecure LD_LIBRARY_PATH assignment, just use the example above.

Upgrading for this defect is frankly silly, although effective. There is no planned
date yet for 2.2.23 although it will come along sometime in the not too distant
future.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]