enterprise-support team mailing list archive

[Daniele Gozzi <2073515@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

= ubuntu release =

Description:	Ubuntu 22.04.3 LTS
Release:	22.04

= package version =

2.4.52-1ubuntu4.11

= what I expected to happen =

I have a RewriteRule as such
  ErrorDocument 503 /cgi-bin/503_cgi/503_cgi.py
  RewriteRule ^/cgi-bin/503_cgi/503_cgi.py$ "unix:/run/instance_starter-cgi-instance_starter/socket|fcgi:/home/instance_starter/503_cgi/503_cgi.py" [QSA,P,L,NE]
  RewriteCond %{HTTP_HOST} ^([^.]+)\.${APACHE_RP_DOMAIN}(:[0-9]+)?$
  RewriteRule ^(.+) %{HTTP_HOST}$1 [C]
  RewriteRule ^([^.]+)\.${APACHE_RP_DOMAIN}(:[0-9]+)?(.*)$ "http://$1:8000$3"; [P,L]

(/run/instance_starter-cgi-instance_starter/socket being the listening
socket of a FastCGI daemon)

I expect that setup to serve a specific FastCGI script in case of a 503
error, proxying to an external HTTP server normally otherwise. The name
of the proxied HTTP server is taken as the first part of the hostname in
the original request, separating that with dots.

= what happened instead =

After the last security updates this configuration is no longer working. It is instead logging in apache:
AH01083: error parsing URL http://: Invalid host/port

I think I can actually pinpoint the release that introduced the bug as
2.4.52-1ubuntu4.10 , based on my logs.

Actually, there are probably two incompatibilities with this
configuration:

Incompatibility 1. The last RewriteRule is the first one producing the AH01083 error and it had to be rewritten with a leading slash on the search pattern as in
  RewriteRule ^/([^.]+)\.${APACHE_RP_DOMAIN}(:[0-9]+)?(.*)$ "http://$1:8000$3"; [P,L]

which is less than optimal given my aim to have the hostname as part of
the pattern matching that I could use in the rewritten path - the slash
is preposterous but I could live with that, as it works.

Incompatibility 2. The first RewriteRule that uses unix: as the start of
the rewritten path

I had not been able to ever use mod_proxy_fcgi in this way again. Even
changing The RewriteRule as I did in several other mod_proxy_http
setups, the path was only reachable through the canonical request path
and would not trigger as an effect of a 503 error.

Just for context I'm explaining a bit the mod_proxy_http changes I had
to perform as a consequence of the same security patches.

I have several other apache web servers which use an internal web application server with a RewriteRule as such:
  RewriteRule ^(/.*)$ "proxy:unix:/run/username-gunicorn-username/socket|http://%{HTTP_HOST}$1"; [QSA,L,NE]

They all had to be rewritten as 
  RewriteRule ^(/.*)$ "unix:/run/username-gunicorn-username/socket|http://%{HTTP_HOST}$1"; [QSA,L,NE,P]

And I kind of see the point. I could also live with that. But a similar bug in the same package bit us two years ago and I would really appreciate some regression tests on the security fixes applied with the Canonical backports.
As far as I can tell, my configuration was not inherently vulnerable so the incident could be avoided having tests which cover similar integrations with external HTTP/FastCGI server server processes on Unix sockets.

This problem also affects the backports for Ubuntu 20.04.

** Affects: apache2 (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Server/Client Support Team, which is subscribed to apache2 in Ubuntu.
Matching subscriptions: Ubuntu Server/Client Support Team
https://bugs.launchpad.net/bugs/2073515

Title:
  functionality loss in mod_proxy rewritten path

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/2073515/+subscriptions