You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Reindl Harald <h....@thelounge.net> on 2014/10/01 19:05:40 UTC
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Am 16.09.2013 um 19:33 schrieb Yehuda Katz:
> I can sort-of confirm this.
>
> Apache 2.4.3 on Windows 7 x64 (ApacheLounge build)
> For me, the PHP is executed, not displayed.
>
> Stock configuration with mod_php and only this added:
> <Location "/phpinfo.php">
> LimitRequestBody 1
> </Location>
>
> The built in error is displayed with the processed PHP (in my case, just phpinfo() ) appended. I could not
> replicate this with any other directive.
2.4.10
that issue still exists and the only safe way in context
of mod_php and httpd is stay at "LimitRequestBody 0" because
even a file-upload exceeding that limit leads in spit
out the content of the php script instead a error page
mod_security and "SecRequestBodyLimit" works as expected
blocking the request - so it hardly is a bug in mod_php
which should not be called at all if "LimitRequestBody"
takes action
if it can't be re-produced there should be at least
a big fat warning in the documenetation that it has
the opposite effect in some environments
> On Mon, Sep 16, 2013 at 7:56 AM, Reindl Harald <h.reindl@thelounge.net <ma...@thelounge.net>> wrote:
>
> why in the world does Apache add the *sourcode* of the called PHP
> script after the sepcified ErrorDocument? this is a major problem
> and exactly *not* what should happen by a security option
> ________________________________________________
>
> <Location "/cms.php">
> LimitRequestBody 10
> </Location>
>
> ErrorDocument 413 "<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'
> 'http://www.w3.org/TR/html4/loose.dtd'><html><head><title>Error 413 - Request Entity Too Large</title><style
> type='text/css'>* {font-family:Arial,Helvetica; text-decoration:none; font-size:16px;} body {margin:0px;
> padding:15px;}</style></head><body><h1 style='margin-top:0px; font-size:18px;'>Error 413</h1><p>Request Entity Too
> Large / Anfrage zur Bearbeitung zu lang<br />Tech. Contact: <a
> href='mailto:server-admins@thelounge.net
> <ma...@thelounge.net>?subject=Server-Error-413'>server-admins@thelounge.net
> <ma...@thelounge.net></a></p></body></html>"
> ________________________________________________
>
> OUTPUT TO THE BROWER (stripped, yes it adds the complete PHP sript)
>
> <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'
> 'http://www.w3.org/TR/html4/loose.dtd'><html><head><title>Error 413 - Request Entity Too Large</title><style
> type='text/css'>* {font-family:Arial,Helvetica; text-decoration:none; font-size:16px;} body {margin:0px;
> padding:15px;}</style></head><body><h1 style='margin-top:0px; font-size:18px;'>Error 413</h1><p>Request Entity Too
> Large / Anfrage zur Bearbeitung zu lang<br />Tech. Contact: <a
> href='mailto:admin@rhsoft.net <ma...@rhsoft.net>?subject=Server-Error-413'>admin@rhsoft.net
> <ma...@rhsoft.net></a></p></body></html><?php
> /**
> CONTENT MANAGMENT SYSTEM / CONTENTLOUNGE
> ------------------------------------------------------------------
> AENDERUNGEN UND WEITERGABE DIESER DATEI OHNE RUECKSPRACHE MIT DEM
> ENTWICKLER SIND LIZENZRECHTLICH NICHT GESTATTET!
> ---------------------------------------------------
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Reindl Harald <h....@thelounge.net>.
Am 03.10.2014 um 02:18 schrieb Eric Covener:
> On Thu, Oct 2, 2014 at 7:02 PM, Reindl Harald <h.reindl@thelounge.net wrote:
>
> Am 03.10.2014 um 00:09 schrieb Eric Covener:
> > On Thu, Oct 2, 2014 at 5:06 PM, Reindl Harald <h.reindl@thelounge.net wrote:
> >
> > however, control that by modsec gives you even the option to
> > select the status code without leak source code - if a module
> > can do that why not the core itself unconditional?
> >
> > The core or any other module could check the content-length earlier
> > and return an error a different way, but it doesn't
>
> so that's a bug according to the intention of the option
>
> IMHO the core should stop the request and discard any output
> not part of the error response independent from where it is
> coming from similar to exit(ob_end_clean()) in a php script
>
> http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody
>
> Unfortunately there are considerations beyond what would make it easiest on Reindl Harald
no idea where that polemic comes from
what makes it "easiest on Reindl Harald" is just "LimitRequestBody 0"
as already happened and so it's hardly about me, it's about others
use the option to increase security unfortunately leak code with passwords
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Eric Covener <co...@gmail.com>.
On Thu, Oct 2, 2014 at 7:02 PM, Reindl Harald <h....@thelounge.net>
wrote:
>
> Am 03.10.2014 um 00:09 schrieb Eric Covener:
> > On Thu, Oct 2, 2014 at 5:06 PM, Reindl Harald <h.reindl@thelounge.net
> wrote:
> >
> > however, control that by modsec gives you even the option to
> > select the status code without leak source code - if a module
> > can do that why not the core itself unconditional?
> >
> > The core or any other module could check the content-length earlier
> > and return an error a different way, but it doesn't
>
> so that's a bug according to the intention of the option
>
> IMHO the core should stop the request and discard any output
> not part of the error response independent from where it is
> coming from similar to exit(ob_end_clean()) in a php script
>
> http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody
>
>
Unfortunately there are considerations beyond what would make it easiest
on Reindl Harald.
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Reindl Harald <h....@thelounge.net>.
Am 03.10.2014 um 00:09 schrieb Eric Covener:
> On Thu, Oct 2, 2014 at 5:06 PM, Reindl Harald <h.reindl@thelounge.net wrote:
>
> however, control that by modsec gives you even the option to
> select the status code without leak source code - if a module
> can do that why not the core itself unconditional?
>
> The core or any other module could check the content-length earlier
> and return an error a different way, but it doesn't
so that's a bug according to the intention of the option
IMHO the core should stop the request and discard any output
not part of the error response independent from where it is
coming from similar to exit(ob_end_clean()) in a php script
http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Eric Covener <co...@gmail.com>.
On Thu, Oct 2, 2014 at 5:06 PM, Reindl Harald <h....@thelounge.net>
wrote:
> however, control that by modsec gives you even the option to
> select the status code without leak source code - if a module
> can do that why not the core itself unconditional?
>
The core or any other module could check the content-length earlier and
return an error a different way, but it doesn't.
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Reindl Harald <h....@thelounge.net>.
Am 02.10.2014 um 22:36 schrieb Joe Orton:
> On Wed, Oct 01, 2014 at 02:16:17PM -0400, Eric Covener wrote:
>> The default handler (static file handler) is a fall-through, and there is
>> not currently a way to tell it NOT to respond for something because a
>> configured module unexpectedly passed control back. It is a relatively
>> easy opt-in feature to add, but not something that is safe for a shipped
>> release to change by default.
>
> The PHP SAPI doesn't handle any errors while reading request body data
> (php_apache_sapi_read_post), which it should. The result of that is
> that the PHP script is executed as normal, and you get a 413 response
> with the ErrorDocument first, then the script output.
>
> I can't see any more serious bug here, Reindl, we lack a working repro
> case for dumping unprocessed source here. Can you reproduce without
> mod_security loaded/configured? Something must be de-configuring the
> mod_php handler, and I can't imagine how exactly that is happening
i need to modify several configurations to make mod_security
conditional and will give feedback as soon that has happened
is there any useful way in case of httpd-prefork to get an
strace showing what happens internally on non-debug builds?
maybe it's something obvious in the direction "why is B even
called after A"
however, control that by modsec gives you even the option to
select the status code without leak source code - if a module
can do that why not the core itself unconditional?
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Oct 01, 2014 at 02:16:17PM -0400, Eric Covener wrote:
> The default handler (static file handler) is a fall-through, and there is
> not currently a way to tell it NOT to respond for something because a
> configured module unexpectedly passed control back. It is a relatively
> easy opt-in feature to add, but not something that is safe for a shipped
> release to change by default.
The PHP SAPI doesn't handle any errors while reading request body data
(php_apache_sapi_read_post), which it should. The result of that is
that the PHP script is executed as normal, and you get a 413 response
with the ErrorDocument first, then the script output.
I can't see any more serious bug here, Reindl, we lack a working repro
case for dumping unprocessed source here. Can you reproduce without
mod_security loaded/configured? Something must be de-configuring the
mod_php handler, and I can't imagine how exactly that is happening.
Regards, Joe
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Graham Dumpleton <gr...@apache.org>.
On 22 October 2014 13:51, Yehuda Katz <ye...@ymkatz.net> wrote:
> On Wed, Oct 1, 2014 at 2:19 PM, Eric Covener <co...@gmail.com> wrote:
>
>>
>> On Wed, Oct 1, 2014 at 2:16 PM, Eric Covener <co...@gmail.com> wrote:
>>
>>> To me, this does not exonerate mod_php, it implicates it. I suspect
>>> your source code is served because PHP swallowed the LimitRequestBody and
>>> then passed control back to Apache. I'm fairly certain I responded to you
>>> privately with similar information already.
>>
>>
>> I should add that I don't understand your scenario completely, where the
>> file is not processed. I think my own test result was the same as Yehuda
>> ITT which is not the same as what I just described with the default handler
>> taking over.
>>
>
> 1. Is this result (PHP executed) still a bug (could be in mod_php)? If a
> 413 comes up, shouldn't no other content be returned?
> I am considering setting up a new VM to do some testing, but I want to
> make sure this is not the expected behavior (whether the PHP is executed or
> not).
>
> 2. Is there another module that hooks in with a similar way to mod_php
> that might also show this behavior (mod_lua for example)?
>
FWIW, I noted similar behaviour in implementing mod_wsgi many years ago.
Since then I have code in mod_wsgi in the handler before anything is done
which specifically does:
/*
* Check to see if the request content is too large if the
* Content-Length header is defined then end the request here. We do
* this as otherwise it will not be done until first time input data
* is read in by the application. Problem is that underlying HTTP
* output filter will also generate a 413 response and the error
* raised from the application will be appended to that. The call to
* ap_discard_request_body() is hopefully enough to trigger sending
* of the 413 response by the HTTP filter.
*/
lenp = apr_table_get(r->headers_in, "Content-Length");
if (lenp) {
char *endstr;
apr_off_t length;
if (wsgi_strtoff(&length, lenp, &endstr, 10)
|| *endstr || length < 0) {
wsgi_log_script_error(r, apr_psprintf(r->pool,
"Invalid Content-Length header value of '%s' was "
"supplied.", lenp), r->filename);
return HTTP_BAD_REQUEST;
}
limit = ap_get_limit_req_body(r);
if (limit && limit < length) {
ap_discard_request_body(r);
return OK;
}
}
So in the case of mod_wsgi it wasn't that the source code was being
appended, but that any error response from the hosted Python WSGI
application, generated in reaction to the reading of the request content
failing because of the length check by the input filter, that got appended
to the end of the 413 error response that the HTTP filter had already
caused to be delivered back.
Graham
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Yehuda Katz <ye...@ymkatz.net>.
On Wed, Oct 1, 2014 at 2:19 PM, Eric Covener <co...@gmail.com> wrote:
>
> On Wed, Oct 1, 2014 at 2:16 PM, Eric Covener <co...@gmail.com> wrote:
>
>> To me, this does not exonerate mod_php, it implicates it. I suspect your
>> source code is served because PHP swallowed the LimitRequestBody and then
>> passed control back to Apache. I'm fairly certain I responded to you
>> privately with similar information already.
>
>
> I should add that I don't understand your scenario completely, where the
> file is not processed. I think my own test result was the same as Yehuda
> ITT which is not the same as what I just described with the default handler
> taking over.
>
1. Is this result (PHP executed) still a bug (could be in mod_php)? If a
413 comes up, shouldn't no other content be returned?
I am considering setting up a new VM to do some testing, but I want to make
sure this is not the expected behavior (whether the PHP is executed or not).
2. Is there another module that hooks in with a similar way to mod_php that
might also show this behavior (mod_lua for example)?
- Y
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Reindl Harald <h....@thelounge.net>.
Am 01.10.2014 um 20:36 schrieb Eric Covener:
> On Wed, Oct 1, 2014 at 2:24 PM, Reindl Harald <h.reindl@thelounge.net <ma...@thelounge.net>> wrote:
>
> i don't know what happens internally
>
> That's what's on-topic for the development list
agreed - but ship source code to a client is serious and
in that case easily controlled by any client with enough
upstream to send some 100 MB of data to a specific URL
in case of open source systems with known config paths it
reverses the option to the opposite of admins intention
> just that "SecRequestBodyLimit" opens a large security hole
> because on just needs to send large data to any script
> on the server to get the source, even scripts only
> working as includes and contain credentials
>
> IMHO if a restriciton like "SecRequestBodyLimit" is triggered
> any output should be thrown away and the error handler called
> delivering the 403 default error page
>
> I think you mean LimitRequestBody
indeed - sorry - that's the modsec value working as expected
> I don't think anyone has done enough homework to see what goes wrong under
> mod_php to see if a change to LimitRequestBody is needed. It currently
> detects the size breach and returns an error to whoever is reading the body.
> In other words handlers have access to all kinds of filter errors,
> so changes there are intrusive
agreed - sorry that i can't do the needed homework
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Eric Covener <co...@gmail.com>.
On Wed, Oct 1, 2014 at 2:24 PM, Reindl Harald <h....@thelounge.net>
wrote:
> i don't know what happens internally
>
That's what's on-topic for the development list.
>
> just that "SecRequestBodyLimit" opens a large security hole
> because on just needs to send large data to any script
> on the server to get the source, even scripts only
> working as includes and contain credentials
>
> IMHO if a restriciton like "SecRequestBodyLimit" is triggered
> any output should be thrown away and the error handler called
> delivering the 403 default error page
>
I think you mean LimitRequestBody. I don't think anyone has done enough
homework to see what goes wrong under mod_php to see if a change to
LimitRequestBody is needed. It currently detects the size breach and
returns an error to whoever is reading the body. In other words handlers
have access to all kinds of filter errors, so changes there are intrusive.
--
Eric Covener
covener@gmail.com
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Reindl Harald <h....@thelounge.net>.
Am 01.10.2014 um 20:19 schrieb Eric Covener:
> On Wed, Oct 1, 2014 at 2:16 PM, Eric Covener <covener@gmail.com <ma...@gmail.com>> wrote:
>
> To me, this does not exonerate mod_php, it implicates it. I suspect your source code is served because PHP
> swallowed the LimitRequestBody and then passed control back to Apache. I'm fairly certain I responded to you
> privately with similar information already.
>
> I should add that I don't understand your scenario completely, where the file is not processed. I think my own
> test result was the same as Yehuda ITT which is not the same as what I just described with the default handler
> taking over
i don't know what happens internally
just that "SecRequestBodyLimit" opens a large security hole
because on just needs to send large data to any script
on the server to get the source, even scripts only
working as includes and contain credentials
IMHO if a restriciton like "SecRequestBodyLimit" is triggered
any output should be thrown away and the error handler called
delivering the 403 default error page
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Eric Covener <co...@gmail.com>.
On Wed, Oct 1, 2014 at 2:16 PM, Eric Covener <co...@gmail.com> wrote:
> To me, this does not exonerate mod_php, it implicates it. I suspect your
> source code is served because PHP swallowed the LimitRequestBody and then
> passed control back to Apache. I'm fairly certain I responded to you
> privately with similar information already.
I should add that I don't understand your scenario completely, where the
file is not processed. I think my own test result was the same as Yehuda
ITT which is not the same as what I just described with the default handler
taking over.
Re: MAJOR SECURITY-PROBLEM Apache 2.4.6
Posted by Eric Covener <co...@gmail.com>.
On Wed, Oct 1, 2014 at 1:05 PM, Reindl Harald <h....@thelounge.net>
wrote:
> mod_security and "
>
> SecRequestBodyLimit" works as expected
> blocking the request - so it hardly is a bug in mod_php
> which should not be called at all if "LimitRequestBody"
> takes action
>
SecRequestBodyLimit reads the content-length in a hook that precedes PHPs
handler.
LimitRequestBody acts as a filter during the read of the body during the
execution of the PHP handler.
To me, this does not exonerate mod_php, it implicates it. I suspect your
source code is served because PHP swallowed the LimitRequestBody and then
passed control back to Apache. I'm fairly certain I responded to you
privately with similar information already.
The default handler (static file handler) is a fall-through, and there is
not currently a way to tell it NOT to respond for something because a
configured module unexpectedly passed control back. It is a relatively
easy opt-in feature to add, but not something that is safe for a shipped
release to change by default.