Bug#995368: Bug in Package: libapache2-mod-proxy-uwsgi

Philippe Accorsi

unread,

Sep 30, 2021, 7:40:03 AM9/30/21

to

Package: libapache2-mod-proxy-uwsgi
Version: 2.0.14+20161117-3+deb9u4_amd64

Hi,

Since the last security update of this package, we can use us application because url is visible two time (ex: /api/auth/login (with old package version) => /api/auth/login/api/auth/login (with new package version)).
We build docker image with OS Debian Stretch and yesterday (2021/09/29 at 12 UTC) everything works good (building image and running application), but yesterday night, after the last build of docker image, the new version of the package is done.
Since this modification, we can't use us application.

I have tried this:

wget http://security.debian.org/debian-security/pool/updates/main/u/uwsgi/libapache2-mod-proxy-uwsgi_2.0.14+20161117-3+deb9u3_amd64.deb
dpkg -i libapache2-mod-proxy-uwsgi_2.0.14+20161117-3+deb9u3_amd64.deb
service stop apache2
service stop uwsgi
service start apache2
service start uwsgi

After that us application is working again.
I not seen why this security fix https://linuxsecurity.com/advisories/deblts/debian-lts-dla-2768-1-uwsgi-security-update-17-53-04 create this kind of bug.

What can be done to solved this "regression" ?

Thanks in advance.
Best regards
Philippe Accorsi

Josef Kejzlar, wpj s.r.o.

unread,

Oct 1, 2021, 10:30:03 AM10/1/21

to

I can confirm this regression.
After unattended security upgrades got applied during the night, all
our applications stopped working.

There is wrong request path sent to uwsgi server. Some times
duplicated leading slash.

I would classify this as critical problem, all servers using uwsgi and
libapache2-mod-proxy-uwsgi stopped working after secuity update.

Moritz Mühlenhoff

unread,

Oct 5, 2021, 4:40:03 AM10/5/21

to

reassign 995368 uwsgi
thanks

Hi Philippe and Josef,
thanks for reporting! This isn't a bug in Apache (source package name
apache2), but got introduced by an update in the uwsgi source package
(which is admittedly confusing since both build Apache modules with uwsgi
in their name).

I'm reassigning the bug and adding the debian-lts list to pick this up.

Cheers,
Moritz

Sylvain Beucler

unread,

Oct 5, 2021, 7:20:03 AM10/5/21

to

Thank you Moritz for forwarding the bug report.

Josef, Philippe, can you provide further information, such as Apache
configuration excerpts, and details about your apache/uwsgi setup?

I did not experience issues with my tests using a simple Django
application (cf. https://wiki.debian.org/LTS/TestSuites/uwsgi )
so currently I cannot reproduce the problem.

Regards,
Sylvain Beucler
Debian LTS Team

Sylvain Beucler

unread,

Oct 5, 2021, 10:10:03 AM10/5/21

to

affects 995368 apache2
thanks

@Philippe thank you for the detailed info.

@Moritz bookworm/apache2-2.4.49's behavior currently matches
uwsgi/stretch's (buggy) behavior, it looks like the upstream patch
introduced a regression.
(This 2.4.49 release appears to have been tested poorly upstream, that'd
make the 5th..)

KO: ProxyPass /uwsgi-pp uwsgi://localhost:8001/
OK: ProxyPass /uwsgi-pps/ uwsgi://localhost:8001/
KO: ProxyPassMatch ^/admin uwsgi://localhost:8001/

I'll open a ticket on bz.apache.org.

Cheers!

Sylvain Beucler
Debian LTS Team

On 05/10/2021 14:39, Philippe Accorsi wrote:
> Hi,
>
> I work on this project https://github.com/tracim/tracim and we saw the
> problem with the docker images created with files available here
> https://github.com/tracim/tracim/tree/develop/tools_docker/Debian_Uwsgi/ .
>
> We create docker images on Debian Stretch and install package
> libapache2-mod-proxy-uwsgi.
>
> We use socket connection between Apache and uwsgi. In Apache we use
> (more detail available directly in repository):
>
> ProxyPassMatch ^/$ uwsgi://localhost:8081/
>
> And in uwsgi configuration file we use (more detail available directly
> in repository):
>
> plugins = python3
> module = wsgi.web:application
> socket = :8081
>
> Regards,
> Philippe Accorsi

>
> Le 05/10/2021 à 13:04, Sylvain Beucler a écrit :
>> Thank you Moritz for forwarding the bug report.
>>

>> Josef, Philippe, can you provide further information, such anas Apache
>> configuration excerpts, d details about your apache/uwsgi setup?

> --
>
> Bien « collaborativement »,
>
> Accorsi Philippe
> Administrateur Système et Support Technique
>
>
> Le logiciel de collaboration Libre MadeinFrance conçu et édité par Algoo SAS
> e-Mail : philippe...@algoo.fr <mailto:philippe...@algoo.fr>
> Tel : 09 72 49 72 20
> Web : www.algoo.fr <https://www.algoo.fr>
>

Sylvain Beucler

unread,

Oct 5, 2021, 12:50:03 PM10/5/21

to

tags 995368 + upstream
forwarded 995368 https://bz.apache.org/bugzilla/show_bug.cgi?id=65616
thanks

Note: there doesn't seem to be actual path duplication at the UWSGI
level, AFAICS Django just gets confused by the additional '/' at the
start of PATH_INFO and incorrectly duplicates the path in the debug
error page.

Sylvain Beucler

unread,

Oct 9, 2021, 12:10:04 PM10/9/21

to

Hi,

On 05/10/2021 18:41, Sylvain Beucler wrote:
> forwarded 995368 https://bz.apache.org/bugzilla/show_bug.cgi?id=65616

The Apache developers say there's an incorrect configuration in the
first place. For example,
ProxyPassMatch ^/ui uwsgi://127.0.0.1:8081/
should be
ProxyPassMatch ^/ui uwsgi://127.0.0.1:8081
following the warning about slashes in the documentation:
http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass

However, they are currently considering an additional patch to restore
the previous (less strict) behavior.

Philippe, Josef, I prepared a build with the new patch, so you can test
early:
https://people.debian.org/~beuc/lts/uwsgi/
https://people.debian.org/~beuc/lts/uwsgi/libapache2-mod-proxy-uwsgi_2.0.14+20161117-3+deb9u5_amd64.deb

I'm interested in your feedback.

philippe...@algoo.fr

unread,

Oct 9, 2021, 4:20:02 PM10/9/21

to

Hi,

Thanks for your answer but also thanks for the information about wrong
configuration of apache.

I have tested both solution you explain here and both works good.

If I apply change in Apache configuration (like explain in the official
documentation about "/") my app works good.
If I just apply your Debian patch, app works good also.

So, we wait for the debian patch for the oldest installation and I now
can create a fix for Tracim project about wrong usage of "/" in apache2
configuration.

Thanks a lot for your solution :) :) :)

Best regards.
Philippe
Sys Admin Algoo

Philipp Hahn

unread,

Oct 14, 2021, 6:50:02 AM10/14/21

to

After installing the Apache2 security update yesterday Mainman3-web is
no longe reachable:

> tail /var/log/mailman3/web/mailman-web.log
…> WARNING 2021-10-14 10:13:30,753 3319 django.request Not Found: /mailman//
> WARNING 2021-10-14 10:13:30,753 3319 django.request Not Found: /mailman//
> [pid: 3319|app: 0|req: 8/8] REDACTED () {162 vars in 5356 bytes} [Thu Oct 14 10:13:30 2021] GET /mailman3/ => generated 5501 bytes in 13 msecs (HTTP/1.1 404) 5 headers in 170 bytes (2 switches on core 0)

> # cat /etc/mailman3/apache.conf
…
> <IfModule mod_proxy_uwsgi.c>
> ProxyPass /mailman3/favicon.ico !
> ProxyPass /mailman3/static !
> ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
> </IfModule>

> # dpkg-query -W mailman3-web apache2
> apache2 2.4.51-1~deb11u1
> mailman3-web 0+20200530-2

Apache2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995368#48
Mailman: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996105

Jo Valentine-Cooper

unread,

Oct 17, 2021, 2:10:03 PM10/17/21

to

Can confirm that mailman3 in oldstable/buster also appears affected by this regression, and the same mitigation (removing the trailing slash from the ProxyPass directive) works around it. (Found out while trying a fourth time to finish procrastinating on migrating my mailman2 system to mailman3 in prep for a procrastinated update to bullseye; the resulting stress was... not fun. :( )

Same symptoms in the mailman3-web log:

WARNING 2021-10-17 17:01:08,583 12164 django.request Not Found: /mailman//
WARNING 2021-10-17 17:01:08,583 12164 django.request Not Found: /mailman//

Since uwsgi in oldstable, so far as I can tell, hasn't been so much as glanced at in two and a half years but Apache was security-updated within the last week or two, that has me wondering about where the bug really lies...

uswgi versions:

$ dpkg -l | grep uwsgi
ii uwsgi 2.0.18-1 i386 fast, self-healing application container server
ii uwsgi-core 2.0.18-1 i386 fast, self-healing application container server (core)
ii uwsgi-plugin-python3 2.0.18-1 i386 WSGI plugin for uWSGI (Python 3)

mailman3 versions:

$ dpkg -l | grep mailman3
ii mailman3 3.2.1-1 all Mailing list management system
ii mailman3-doc 3.2.1-1 all Mailing list management system documentation
ii mailman3-full 3.2.1-1 all Full Mailman3 mailing list management suite (metapackage)
ii mailman3-web 0+20180916-8 all Django project integrating Mailman3 Postorius and HyperKitty
ii python3-django-mailman3 1.2.0-3 all Django library to help interaction with Mailman3 (Python 3 version)

apache versions:

$ dpkg -l | grep apache
ii apache2 2.4.38-3+deb10u6 i386 Apache HTTP Server
ii apache2-bin 2.4.38-3+deb10u6 i386 Apache HTTP Server (modules and other binary files)
ii apache2-data 2.4.38-3+deb10u6 all Apache HTTP Server (common files)
ii apache2-utils 2.4.38-3+deb10u6 i386 Apache HTTP Server (utility programs for web servers)

Hope this helps.

-jo

--

Jo Valentine-Cooper (j...@nwcs.com)
Of course, I don't know how interesting any of this really is,
but now you've got it in your brain cells so you're stuck with it.
--Gary Larson

Sylvain Beucler

unread,

Dec 1, 2021, 12:40:03 PM12/1/21

to

The regression fix is now officially staged upstream for 2.4.52:
https://github.com/apache/httpd/commit/8966e290a6e947fad0289bf4e243b0b552e13726