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. In affected versions missing input validation on mod_auth_openidc_session_chunks cookie value makes the server vulnerable to a denial of service (DoS) attack. An internal security audit has been conducted and the reviewers found that if they manipulated the value of the mod_auth_openidc_session_chunks cookie to a very large integer, like 99999999, the server struggles with the request for a long time and finally gets back with a 500 error. Making a few requests of this kind caused our server to become unresponsive. Attackers can craft requests that would make the server work very hard (and possibly become unresponsive) and/or crash with minimal effort. This issue has been addressed in version 2.4.15.2. Users are advised to upgrade. There are no known workarounds for this vulnerability.
The product does not properly control the allocation and maintenance of a limited resource.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Mod_auth_openidc | Openidc | 2.0.0 (including) | 2.4.15.1 (including) |
| Red Hat Enterprise Linux 8 | RedHat | mod_auth_openidc:2.3-8100020240516071625.489197e6 | * |
| Red Hat Enterprise Linux 9 | RedHat | mod_auth_openidc-0:2.4.10-1.el9 | * |
| Libapache2-mod-auth-openidc | Ubuntu | bionic | * |
| Libapache2-mod-auth-openidc | Ubuntu | esm-apps/bionic | * |
| Libapache2-mod-auth-openidc | Ubuntu | esm-apps/focal | * |
| Libapache2-mod-auth-openidc | Ubuntu | esm-apps/jammy | * |
| Libapache2-mod-auth-openidc | Ubuntu | esm-apps/noble | * |
| Libapache2-mod-auth-openidc | Ubuntu | focal | * |
| Libapache2-mod-auth-openidc | Ubuntu | jammy | * |
| Libapache2-mod-auth-openidc | Ubuntu | mantic | * |
| Libapache2-mod-auth-openidc | Ubuntu | noble | * |
| Libapache2-mod-auth-openidc | Ubuntu | upstream | * |
| Libapache2-mod-auth-openidc | Ubuntu | xenial | * |
Mitigation of resource exhaustion attacks requires that the target system either:
The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
The second solution is simply difficult to effectively institute – and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.