Hello Moritz,
The patch looks good :)
The LTS upload workflow is detailed at:
https://lts-team.pages.debian.net/wiki/Development.html
As a DD you can do everything by yourself, but if you want I can take
care of the administrative side (registering a DLA, announcing it, etc.).
How did you test the update?
There's a proof-of-concept for this CVE IIUC.
We also try to run tests at Salsa-CI, with a LTS config:
https://lts-team.pages.debian.net/git-workflow-lts.html#add-salsa-ci-yml
You can push at your own repo at Salsa or at the lts-team repo is you
wish to keep LTS/ELTS history separate.
Cheers!
Sylvain Beucler
Debian LTS Team
On 16/04/2025 11:19, Moritz Schlarb wrote:
Hi LTS Team,
I have prepared a fixed version of the package by backporting the upstream
patch to bookworm and bullseye.
For the latter, please see the attached debdiff to check for good practice and
please advise me how to continue, since this is my first security fix in LTS
land. ;)
Thanks,
Moritz
On Tue, 2025-04-08 at 22:05 +0200, Salvatore Bonaccorso wrote:
Source: libapache2-mod-auth-openidc
Version: 2.4.16.10-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team
<t...@security.debian.org>
Hi,
The following vulnerability was published for libapache2-mod-auth-openidc.
CVE-2025-31492[0]:
mod_auth_openidc is an OpenID Certified authentication and
authorization module for the Apache 2.x HTTP server that implements
the OpenID Connect Relying Party functionality. Prior to 2.4.16.11,
a bug in a mod_auth_openidc results in disclosure of protected
content to unauthenticated users. The conditions for disclosure are
an OIDCProviderAuthRequestMethod POST, a valid account, and there
mustn't be any application-level gateway (or load balancer etc)
protecting the server. When you request a protected resource, the
response includes the HTTP status, the HTTP headers, the intended
response (the self-submitting form), and the protected resource
(with no headers). This is an example of a request for a protected
resource, including all the data returned. In the case where
mod_auth_openidc returns a form, it has to return OK from
check_userid so as not to go down the error path in httpd. This
means httpd will try to issue the protected resource.
oidc_content_handler is called early, which has the opportunity to
prevent the normal output being issued by httpd.
oidc_content_handler has a number of checks for when it intervenes,
but it doesn't check for this case, so the handler returns DECLINED.
Consequently, httpd appends the protected content to the response.
The issue has been patched in mod_auth_openidc versions >=
2.4.16.11.
If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2025-31492
https://www.cve.org/CVERecord?id=CVE-2025-31492
[1]
https://github.com/OpenIDC/mod_auth_openidc/security/advisories/GHSA-59jp-rwph-878r
[2]
https://github.com/OpenIDC/mod_auth_openidc/commit/b59b8ad63411857090ba1088e23fe414c690c127
Please adjust the affected versions in the BTS as needed.
Regards,
Salvatore
