Re: [users@httpd] CVE-2023-25690: Apache HTTP Server: HTTP request splitting with mod_rewrite and mod_proxy
On Mon, Mar 13, 2023 at 7:38 AM Thomas Åkesson wrote: > > > Try e.g. [R,B= ?,...] > > The question mark is to avoid the issue of not being able to have " " > as the final character in this syntax. > >>> > >> > >> Sorry, the above doesn't work. Someone reported in another thread: [R,B=\ ] > > > > The real trick seems to be quoting the entirety of the flags, then > > finding any 2nd character to escape. > > RewriteRule ... "[B= ?]" > > Thanks for pointing that out. Quoting the entirety of the flags works. Would > be great to get that into the documentation. > > https://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_b There is now some text and an example there at the bottom. You may need to shift-refresh to see it. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] CVE-2023-25690: Apache HTTP Server: HTTP request splitting with mod_rewrite and mod_proxy
>>> Thanks for the suggestion. I am unable to make 2.4.52 (Ubuntu) accept space >>> for the B-flag. I have tried first, middle, last, only flag but always >>> getting "RewriteRule: bad flag delimiters". >>> >>> I am also having concerns whether this would work (unable to test at this >>> time). >>> - The spaces would likely be double-encoded unless adding NE >> >> In your case, with just B you'd end up with space->+ and the default >> escaping w/o NE does not touch a +. > > After some additional experiments I was leaning towards "[R,B= +,...]" since > a plus character would otherwise be confused with space (was actually a bug > before when using [R, ...]). To be clear, with "bug" I meant a bug in the platform that I maintain where httpd is a component. I am not saying it's a bug in httpd. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] CVE-2023-25690: Apache HTTP Server: HTTP request splitting with mod_rewrite and mod_proxy
Try e.g. [R,B= ?,...] The question mark is to avoid the issue of not being able to have " " as the final character in this syntax. >>> >> >> Sorry, the above doesn't work. Someone reported in another thread: [R,B=\ ] > > The real trick seems to be quoting the entirety of the flags, then > finding any 2nd character to escape. > RewriteRule ... "[B= ?]" Thanks for pointing that out. Quoting the entirety of the flags works. Would be great to get that into the documentation. https://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_b >> Thanks for the suggestion. I am unable to make 2.4.52 (Ubuntu) accept space >> for the B-flag. I have tried first, middle, last, only flag but always >> getting "RewriteRule: bad flag delimiters". >> >> I am also having concerns whether this would work (unable to test at this >> time). >> - The spaces would likely be double-encoded unless adding NE > > In your case, with just B you'd end up with space->+ and the default > escaping w/o NE does not touch a +. After some additional experiments I was leaning towards "[R,B= +,...]" since a plus character would otherwise be confused with space (was actually a bug before when using [R, ...]). However, the plus character will then be double escaped into %252b. Sigh. >> - Adding NE would suppress encoding of all other characters that should be >> encoded in the query string > > A colleague proposed a fix to this scenario, where the new check could > be omitted if redirecting and escaping. That would be great in order to maintain the historical behavior and keep a simpler syntax (but the plus character is still a challenge). - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] CVE-2023-25690: Apache HTTP Server: HTTP request splitting with mod_rewrite and mod_proxy
On Fri, Mar 10, 2023 at 5:56 PM Eric Covener wrote: > > > > Try e.g. [R,B= ?,...] > > > > > > The question mark is to avoid the issue of not being able to have " " > > > as the final character in this syntax. > > > > Sorry, the above doesn't work. Someone reported in another thread: [R,B=\ ] The real trick seems to be quoting the entirety of the flags, then finding any 2nd character to escape. RewriteRule ... "[B= ?]" - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] CVE-2023-25690: Apache HTTP Server: HTTP request splitting with mod_rewrite and mod_proxy
> > Try e.g. [R,B= ?,...] > > > > The question mark is to avoid the issue of not being able to have " " > > as the final character in this syntax. > Sorry, the above doesn't work. Someone reported in another thread: [R,B=\ ] > Thanks for the suggestion. I am unable to make 2.4.52 (Ubuntu) accept space > for the B-flag. I have tried first, middle, last, only flag but always > getting "RewriteRule: bad flag delimiters". > > I am also having concerns whether this would work (unable to test at this > time). > - The spaces would likely be double-encoded unless adding NE In your case, with just B you'd end up with space->+ and the default escaping w/o NE does not touch a +. I think BNP would result in double-escaping, as & seems to be escaped. > - Adding NE would suppress encoding of all other characters that should be > encoded in the query string A colleague proposed a fix to this scenario, where the new check could be omitted if redirecting and escaping. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] CVE-2023-25690: Apache HTTP Server: HTTP request splitting with mod_rewrite and mod_proxy
> On 10 Mar 2023, at 16:32, Eric Covener wrote: > > On Fri, Mar 10, 2023 at 8:56 AM Thomas Åkesson > wrote: >> >> Hi, >> >> We are experiencing the effect that a RewriteRule resulting in R (redirect) >> are blocked (403) with AH10410 despite being encoded before 2.4.56 (the >> resulting Location header was ok). Is this change intentional? >> >> Example: >> RewriteRule ^/here/([^/]+)(/.*)$ >> http://example.com:8080/elsewhere/?base=$1=$2 [R,QSA,L] >> >> We are evaluating this workaround: >> [R,B,BNP,NE,QSA,L] >> >> This results in encoded slashes which is not necessary. Any ideas how to >> achieve the previous result? Also found that many additional characters are encoded that were not encoded before 2.4.56 (parentheses, period, ...). The primary concern is loss of URL readability. > You can limit the characters B will escape. I assume spaces in the > URL are the original problem? Yes, they are the problem that we have seen. I am not sure if the "control characters" mentioned would ever appear in normal use. > Try e.g. [R,B= ?,...] > > The question mark is to avoid the issue of not being able to have " " > as the final character in this syntax. Thanks for the suggestion. I am unable to make 2.4.52 (Ubuntu) accept space for the B-flag. I have tried first, middle, last, only flag but always getting "RewriteRule: bad flag delimiters". I am also having concerns whether this would work (unable to test at this time). - The spaces would likely be double-encoded unless adding NE - Adding NE would suppress encoding of all other characters that should be encoded in the query string - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] CVE-2023-25690: Apache HTTP Server: HTTP request splitting with mod_rewrite and mod_proxy
On Fri, Mar 10, 2023 at 8:56 AM Thomas Åkesson wrote: > > Hi, > > We are experiencing the effect that a RewriteRule resulting in R (redirect) > are blocked (403) with AH10410 despite being encoded before 2.4.56 (the > resulting Location header was ok). Is this change intentional? > > Example: > RewriteRule ^/here/([^/]+)(/.*)$ > http://example.com:8080/elsewhere/?base=$1=$2 [R,QSA,L] > > We are evaluating this workaround: > [R,B,BNP,NE,QSA,L] > > This results in encoded slashes which is not necessary. Any ideas how to > achieve the previous result? You can limit the characters B will escape. I assume spaces in the URL are the original problem? Try e.g. [R,B= ?,...] The question mark is to avoid the issue of not being able to have " " as the final character in this syntax. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
RE: [users@httpd] CVE-2023-25690: Apache HTTP Server: HTTP request splitting with mod_rewrite and mod_proxy
Hi, We are experiencing the effect that a RewriteRule resulting in R (redirect) are blocked (403) with AH10410 despite being encoded before 2.4.56 (the resulting Location header was ok). Is this change intentional? Example: RewriteRule ^/here/([^/]+)(/.*)$ http://example.com:8080/elsewhere/?base=$1=$2 [R,QSA,L] We are evaluating this workaround: [R,B,BNP,NE,QSA,L] This results in encoded slashes which is not necessary. Any ideas how to achieve the previous result? Tested on the Ubuntu 22.04 and 20.04 backport of this fix. Thanks, Thomas Å. On 2023/03/07 12:55:07 Eric Covener wrote: > > Severity: important > > Description: > > Some mod_proxy configurations on Apache HTTP Server versions 2.4.0 through > 2.4.55 allow a HTTP Request Smuggling attack. > > > > > Configurations are affected when mod_proxy is enabled along with some form of > RewriteRule > or ProxyPassMatch in which a non-specific pattern matches > some portion of the user-supplied request-target (URL) data and is then > re-inserted into the proxied request-target using variable > substitution. For example, something like: > > > > > RewriteEngine on > RewriteRule "^/here/(.*)" " http://example.com:8080/elsewhere?$1; > http://example.com:8080/elsewhere ; [P] > ProxyPassReverse /here/ http://example.com:8080/ http://example.com:8080/ > > > Request splitting/smuggling could result in bypass of access controls in the > proxy server, proxying unintended URLs to existing origin servers, and cache > poisoning. > > Credit: > > Lars Krapf of Adobe (finder) > > References: > > https://httpd.apache.org/ > https://www.cve.org/CVERecord?id=CVE-2023-25690 > > Timeline: > > 2023-02-02: reported > > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
