You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2016/12/08 18:46:01 UTC
2.4 HEAD: some looping issue with check_headers()
I am playing with check_headers() and injecting bad characters, and I
am getting some looping:
#2155 0x000000000048af80 in ap_http_header_filter (f=0x7fffc80061d0,
b=0x7fffc09c2bd8) at http_filters.c:1262
#2156 0x00000000004396d0 in ap_pass_brigade (next=0x7fffc80061d0,
bb=0x7fffc09c2bd8) at util_filter.c:610
#2157 0x00000000004408aa in ap_content_length_filter
(f=0x7fffc8006198, b=0x7fffc09c2bd8) at protocol.c:1776
#2158 0x00000000004396d0 in ap_pass_brigade (next=0x7fffc8006198,
bb=0x7fffc09c2bd8) at util_filter.c:610
#2159 0x00007fffe838daa5 in ap_headers_error_filter (f=0x7fffc09c2948,
in=0x7fffc09c2bd8) at mod_headers.c:917
#2160 0x00000000004396d0 in ap_pass_brigade (next=0x7fffc09c2948,
bb=0x7fffc09c2bd8) at util_filter.c:610
#2161 0x00007fffe6103dfc in session_output_filter (f=0x7fffc09c2910,
in=0x7fffc09c2bd8) at mod_session.c:489
#2162 0x00000000004396d0 in ap_pass_brigade (next=0x7fffc09c2910,
bb=0x7fffc09c2bd8) at util_filter.c:610
#2163 0x0000000000440b5e in ap_old_write_filter (f=0x7fffc09c29e0,
bb=0x7fffc09c2bd8) at protocol.c:1845
#2164 0x00000000004396d0 in ap_pass_brigade (next=0x7fffc09c29e0,
bb=0x7fffc09c2bd8) at util_filter.c:610
#2165 0x00000000004400a7 in end_output_stream (r=0x7fffc8004980) at
protocol.c:1540
#2166 0x000000000044011f in ap_finalize_request_protocol
(r=0x7fffc8004980) at protocol.c:1565
#2167 0x0000000000486612 in ap_send_error_response (r=0x7fffc8004980,
recursive_error=500) at http_protocol.c:1395
#2168 0x0000000000486da8 in ap_die_r (type=500, r=0x7fffc8004980,
recursive_error=500) at http_request.c:224
#2169 0x0000000000486dd4 in ap_die (type=500, r=0x7fffc8004980) at
http_request.c:229
#2170 0x000000000048af80 in ap_http_header_filter (f=0x7fffc80061d0,
b=0x7fffc09c2798) at http_filters.c:1262
This is even after trying to zap the offending header before ap_die.
--
Eric Covener
covener@gmail.com
Re: 2.4 HEAD: some looping issue with check_headers()
Posted by Eric Covener <co...@gmail.com>.
On Thu, Dec 8, 2016 at 2:34 PM, Jacob Champion <ch...@gmail.com> wrote:
> On 12/08/2016 11:14 AM, Eric Covener wrote:
>>
>> On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr <wr...@rowe-clan.net>
>> wrote:
>>>
>>> Still, I think we want to add a guard to rip out the offending header
>>> and not ap_die() in handling a 500 error, that's quite the loop, and
>>> if you could create the problem, so can another unsuspecting admin.
>>
>>
>> Is 500 status code and status line w/ original body but zapped "bad"
>> headers reasonable?
>
>
> Seems reasonable to me...
>
> Is there something lower-level than ap_die() that doesn't actually go back
> through the filter system again? Having strong guarantees on behavior would
> be useful in this situation.
>
I didn't see anything too promising. I committed the ugly thing I had
because I will be tied up for a bit.
--
Eric Covener
covener@gmail.com
Re: 2.4 HEAD: some looping issue with check_headers()
Posted by Jacob Champion <ch...@gmail.com>.
On 12/08/2016 11:14 AM, Eric Covener wrote:
> On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>> Still, I think we want to add a guard to rip out the offending header
>> and not ap_die() in handling a 500 error, that's quite the loop, and
>> if you could create the problem, so can another unsuspecting admin.
>
> Is 500 status code and status line w/ original body but zapped "bad"
> headers reasonable?
Seems reasonable to me...
Is there something lower-level than ap_die() that doesn't actually go
back through the filter system again? Having strong guarantees on
behavior would be useful in this situation.
--Jacob
Re: 2.4 HEAD: some looping issue with check_headers()
Posted by Eric Covener <co...@gmail.com>.
On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Still, I think we want to add a guard to rip out the offending header
> and not ap_die() in handling a 500 error, that's quite the loop, and
> if you could create the problem, so can another unsuspecting admin.
Is 500 status code and status line w/ original body but zapped "bad"
headers reasonable?
--
Eric Covener
covener@gmail.com
Re: 2.4 HEAD: some looping issue with check_headers()
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Dec 8, 2016 at 12:49 PM, Eric Covener <co...@gmail.com> wrote:
> On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener <co...@gmail.com> wrote:
> > This is even after trying to zap the offending header before ap_die.
>
> I think this is more about how I am injecting the bad characters -- It
> is re-running after the ap_die.
>
Still, I think we want to add a guard to rip out the offending header
and not ap_die() in handling a 500 error, that's quite the loop, and
if you could create the problem, so can another unsuspecting admin.
Re: 2.4 HEAD: some looping issue with check_headers()
Posted by Eric Covener <co...@gmail.com>.
On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener <co...@gmail.com> wrote:
> This is even after trying to zap the offending header before ap_die.
I think this is more about how I am injecting the bad characters -- It
is re-running after the ap_die.
--
Eric Covener
covener@gmail.com
Re: 2.4 HEAD: some looping issue with check_headers()
Posted by Eric Covener <co...@gmail.com>.
I should mention I was actually "on" trunk because I thought there'd
be a quick fix. But the relevant stuff is recently backported
On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener <co...@gmail.com> wrote:
> I am playing with check_headers() and injecting bad characters, and I
> am getting some looping:
>
> #2155 0x000000000048af80 in ap_http_header_filter (f=0x7fffc80061d0,
> b=0x7fffc09c2bd8) at http_filters.c:1262
> #2156 0x00000000004396d0 in ap_pass_brigade (next=0x7fffc80061d0,
> bb=0x7fffc09c2bd8) at util_filter.c:610
> #2157 0x00000000004408aa in ap_content_length_filter
> (f=0x7fffc8006198, b=0x7fffc09c2bd8) at protocol.c:1776
> #2158 0x00000000004396d0 in ap_pass_brigade (next=0x7fffc8006198,
> bb=0x7fffc09c2bd8) at util_filter.c:610
> #2159 0x00007fffe838daa5 in ap_headers_error_filter (f=0x7fffc09c2948,
> in=0x7fffc09c2bd8) at mod_headers.c:917
> #2160 0x00000000004396d0 in ap_pass_brigade (next=0x7fffc09c2948,
> bb=0x7fffc09c2bd8) at util_filter.c:610
> #2161 0x00007fffe6103dfc in session_output_filter (f=0x7fffc09c2910,
> in=0x7fffc09c2bd8) at mod_session.c:489
> #2162 0x00000000004396d0 in ap_pass_brigade (next=0x7fffc09c2910,
> bb=0x7fffc09c2bd8) at util_filter.c:610
> #2163 0x0000000000440b5e in ap_old_write_filter (f=0x7fffc09c29e0,
> bb=0x7fffc09c2bd8) at protocol.c:1845
> #2164 0x00000000004396d0 in ap_pass_brigade (next=0x7fffc09c29e0,
> bb=0x7fffc09c2bd8) at util_filter.c:610
> #2165 0x00000000004400a7 in end_output_stream (r=0x7fffc8004980) at
> protocol.c:1540
> #2166 0x000000000044011f in ap_finalize_request_protocol
> (r=0x7fffc8004980) at protocol.c:1565
> #2167 0x0000000000486612 in ap_send_error_response (r=0x7fffc8004980,
> recursive_error=500) at http_protocol.c:1395
> #2168 0x0000000000486da8 in ap_die_r (type=500, r=0x7fffc8004980,
> recursive_error=500) at http_request.c:224
> #2169 0x0000000000486dd4 in ap_die (type=500, r=0x7fffc8004980) at
> http_request.c:229
> #2170 0x000000000048af80 in ap_http_header_filter (f=0x7fffc80061d0,
> b=0x7fffc09c2798) at http_filters.c:1262
>
> This is even after trying to zap the offending header before ap_die.
> --
> Eric Covener
> covener@gmail.com
--
Eric Covener
covener@gmail.com