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 0x0048af80 in ap_http_header_filter (f=0x7fffc80061d0, b=0x7fffc09c2bd8) at http_filters.c:1262 #2156 0x004396d0 in ap_pass_brigade (next=0x7fffc80061d0, bb=0x7fffc09c2bd8) at util_filter.c:610 #2157 0x004408aa in ap_content_length_filter (f=0x7fffc8006198, b=0x7fffc09c2bd8) at protocol.c:1776 #2158 0x004396d0 in ap_pass_brigade (next=0x7fffc8006198, bb=0x7fffc09c2bd8) at util_filter.c:610 #2159 0x7fffe838daa5 in ap_headers_error_filter (f=0x7fffc09c2948, in=0x7fffc09c2bd8) at mod_headers.c:917 #2160 0x004396d0 in ap_pass_brigade (next=0x7fffc09c2948, bb=0x7fffc09c2bd8) at util_filter.c:610 #2161 0x7fffe6103dfc in session_output_filter (f=0x7fffc09c2910, in=0x7fffc09c2bd8) at mod_session.c:489 #2162 0x004396d0 in ap_pass_brigade (next=0x7fffc09c2910, bb=0x7fffc09c2bd8) at util_filter.c:610 #2163 0x00440b5e in ap_old_write_filter (f=0x7fffc09c29e0, bb=0x7fffc09c2bd8) at protocol.c:1845 #2164 0x004396d0 in ap_pass_brigade (next=0x7fffc09c29e0, bb=0x7fffc09c2bd8) at util_filter.c:610 #2165 0x004400a7 in end_output_stream (r=0x7fffc8004980) at protocol.c:1540 #2166 0x0044011f in ap_finalize_request_protocol (r=0x7fffc8004980) at protocol.c:1565 #2167 0x00486612 in ap_send_error_response (r=0x7fffc8004980, recursive_error=500) at http_protocol.c:1395 #2168 0x00486da8 in ap_die_r (type=500, r=0x7fffc8004980, recursive_error=500) at http_request.c:224 #2169 0x00486dd4 in ap_die (type=500, r=0x7fffc8004980) at http_request.c:229 #2170 0x0048af80 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 cove...@gmail.com
Re: 2.4 HEAD: some looping issue with check_headers()
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 wrote: > I am playing with check_headers() and injecting bad characters, and I > am getting some looping: > > #2155 0x0048af80 in ap_http_header_filter (f=0x7fffc80061d0, > b=0x7fffc09c2bd8) at http_filters.c:1262 > #2156 0x004396d0 in ap_pass_brigade (next=0x7fffc80061d0, > bb=0x7fffc09c2bd8) at util_filter.c:610 > #2157 0x004408aa in ap_content_length_filter > (f=0x7fffc8006198, b=0x7fffc09c2bd8) at protocol.c:1776 > #2158 0x004396d0 in ap_pass_brigade (next=0x7fffc8006198, > bb=0x7fffc09c2bd8) at util_filter.c:610 > #2159 0x7fffe838daa5 in ap_headers_error_filter (f=0x7fffc09c2948, > in=0x7fffc09c2bd8) at mod_headers.c:917 > #2160 0x004396d0 in ap_pass_brigade (next=0x7fffc09c2948, > bb=0x7fffc09c2bd8) at util_filter.c:610 > #2161 0x7fffe6103dfc in session_output_filter (f=0x7fffc09c2910, > in=0x7fffc09c2bd8) at mod_session.c:489 > #2162 0x004396d0 in ap_pass_brigade (next=0x7fffc09c2910, > bb=0x7fffc09c2bd8) at util_filter.c:610 > #2163 0x00440b5e in ap_old_write_filter (f=0x7fffc09c29e0, > bb=0x7fffc09c2bd8) at protocol.c:1845 > #2164 0x004396d0 in ap_pass_brigade (next=0x7fffc09c29e0, > bb=0x7fffc09c2bd8) at util_filter.c:610 > #2165 0x004400a7 in end_output_stream (r=0x7fffc8004980) at > protocol.c:1540 > #2166 0x0044011f in ap_finalize_request_protocol > (r=0x7fffc8004980) at protocol.c:1565 > #2167 0x00486612 in ap_send_error_response (r=0x7fffc8004980, > recursive_error=500) at http_protocol.c:1395 > #2168 0x00486da8 in ap_die_r (type=500, r=0x7fffc8004980, > recursive_error=500) at http_request.c:224 > #2169 0x00486dd4 in ap_die (type=500, r=0x7fffc8004980) at > http_request.c:229 > #2170 0x0048af80 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 > cove...@gmail.com -- Eric Covener cove...@gmail.com
Re: 2.4 HEAD: some looping issue with check_headers()
On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener 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 cove...@gmail.com
Re: 2.4 HEAD: some looping issue with check_headers()
On Thu, Dec 8, 2016 at 12:49 PM, Eric Covener wrote: > On Thu, Dec 8, 2016 at 1:46 PM, Eric Covener 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()
On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr 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 cove...@gmail.com
Re: 2.4 HEAD: some looping issue with check_headers()
On 12/08/2016 11:14 AM, Eric Covener wrote: On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr 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()
On Thu, Dec 8, 2016 at 2:34 PM, Jacob Champion wrote: > On 12/08/2016 11:14 AM, Eric Covener wrote: >> >> On Thu, Dec 8, 2016 at 1:58 PM, William A Rowe Jr >> 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 cove...@gmail.com
