[Bug 63437] MergeSlashes option breaks protocol specifier in URIs

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63437

--- Comment #9 from chris@familie-hilgers.com <ch...@familie-hilgers.com> ---
Here is a reproducer to show the impact of the fix on a forward Proxy using
ProxyRequests On


quoting from: https://httpd.apache.org/security/vulnerabilities_24.html
Apache httpd URL normalization inconsistincy (CVE-2019-0220)

When the _path_ component of a request URL contains multiple consecutive
slashes ('/'), directives such as LocationMatch and RewriteRule must account
for duplicates in regular expressions while other aspects of the servers
processing will implicitly collapse them.

The path component is defined here: https://tools.ietf.org/html/rfc1738
3.3. HTTP

   The HTTP URL scheme is used to designate Internet resources
   accessible using HTTP (HyperText Transfer Protocol).

   The HTTP protocol is specified elsewhere. This specification only
   describes the syntax of HTTP URLs.

   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>  <<<<------

   where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed.  <path> is an HTTP selector, and <searchpart> is a query
   string. The <path> is optional, as is the <searchpart> and its
   preceding "?". If neither <path> nor <searchpart> is present, the "/"
   may also be omitted.

   Within the <path> and <searchpart> components, "/", ";", "?" are
   reserved.  The "/" character may be used within HTTP to designate a
   hierarchical structure.


The CVE Fix does not only merge slashes in the path part but does it on
http://, too.

Her a reproducer based on a fresh Debian 10 installation.

install debian 10
a2enmod proxy rewrite proxy_http ssl
cd /etc/apache2/sites-available

add to 000-default.conf:
...

        LogLevel rewrite:trace4
        ProxyRequests On
        ProxyVia On
        SSLProxyEngine on

        #w/a2
        #MergeSlashes off
        <Proxy *>
                RewriteEngine On
                #w/a1
                #RewriteCond %{REQUEST_URI} http:/httpd.apache.org/(.*)
                RewriteCond %{REQUEST_URI} http://httpd.apache.org/(.*)
                RewriteRule .*             https://httpd.apache.org/%1  [P]
        </Proxy>


</VirtualHost>


apachectl configtest
apachectl graceful

curl -x localhost:80  http://httpd.apache.org/weg/

Test 1:
with  RewriteCond %{REQUEST_URI} http://httpd.apache.org/(.*)

results in: /var/log/apache2/error.log:
[Tue Mar 24 17:25:43.905466 2020] [rewrite:trace4] [pid 2995:tid
139950494312192] mod_rewrite.c(483): [client ::1:36732] ::1 - -
[httpd.apache.org/sid#7f48cb4a1d20][rid#7f48c83180a0/initial] [perdir */]
RewriteCond: input='http:/httpd.apache.org/weg/'
pattern='http://httpd.apache.org/(.*)' => not-matched

input='http:/httpd.apache.org/weg/  <<-- http:/


Test 2: w/a1 or w/a2 activated MergeSlashes ON or http:/httpd....
[Tue Mar 24 17:26:47.457483 2020] [rewrite:trace4] [pid 3069:tid
139978218665728] mod_rewrite.c(483): [client ::1:36736] ::1 - -
[httpd.apache.org/sid#7f4f3ca36d20][rid#7f4f3c0ac0a0/initial] [perdir */]
RewriteCond: input='http://httpd.apache.org/weg/'
pattern='http://httpd.apache.org/(.*)' => matched

input='http://httpd.apache.org/weg/' <<-- http://


workaround3 would be replace REQUEST_URI with REQUEST_FILENAME

To me this is either an incomplete fix as REQUEST_FILENAME is not affected. If
the CVE does
indicate REQUEST_FILENAME then it looks like a not optimal fix as it breaks
existing installations
without warning.


Kind regards
Christian

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org