Bug#1068412: apache2: CVE-2024-27316 CVE-2024-24795 CVE-2023-38709
Source: apache2 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for apache2. CVE-2024-27316[0]: https://www.kb.cert.org/vuls/id/421644 https://www.openwall.com/lists/oss-security/2024/04/04/4 CVE-2024-24795[1]: https://www.openwall.com/lists/oss-security/2024/04/04/5 CVE-2023-38709[2]: https://www.openwall.com/lists/oss-security/2024/04/04/3 If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-27316 https://www.cve.org/CVERecord?id=CVE-2024-27316 [1] https://security-tracker.debian.org/tracker/CVE-2024-24795 https://www.cve.org/CVERecord?id=CVE-2024-24795 [2] https://security-tracker.debian.org/tracker/CVE-2023-38709 https://www.cve.org/CVERecord?id=CVE-2023-38709 Please adjust the affected versions in the BTS as needed.
Bug#1012513: apache2: CVE-2022-31813 CVE-2022-26377 CVE-2022-28614 CVE-2022-28615 CVE-2022-29404 CVE-2022-30522 CVE-2022-30556
Source: apache2
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security
Hi,
The following vulnerabilities were published for apache2.
CVE-2022-31813[0]:
| Apache HTTP Server 2.4.53 and earlier may not send the X-Forwarded-*
| headers to the origin server based on client side Connection header
| hop-by-hop mechanism. This may be used to bypass IP based
| authentication on the origin server/application.
CVE-2022-26377[1]:
| Inconsistent Interpretation of HTTP Requests ('HTTP Request
| Smuggling') vulnerability in mod_proxy_ajp of Apache HTTP Server
| allows an attacker to smuggle requests to the AJP server it forwards
| requests to. This issue affects Apache HTTP Server Apache HTTP Server
| 2.4 version 2.4.53 and prior versions.
CVE-2022-28614[2]:
| The ap_rwrite() function in Apache HTTP Server 2.4.53 and earlier may
| read unintended memory if an attacker can cause the server to reflect
| very large input using ap_rwrite() or ap_rputs(), such as with
| mod_luas r:puts() function.
CVE-2022-28615[3]:
| Apache HTTP Server 2.4.53 and earlier may crash or disclose
| information due to a read beyond bounds in ap_strcmp_match() when
| provided with an extremely large input buffer. While no code
| distributed with the server can be coerced into such a call, third-
| party modules or lua scripts that use ap_strcmp_match() may
| hypothetically be affected.
CVE-2022-29404[4]:
| In Apache HTTP Server 2.4.53 and earlier, a malicious request to a lua
| script that calls r:parsebody(0) may cause a denial of service due to
| no default limit on possible input size.
CVE-2022-30522[5]:
| If Apache HTTP Server 2.4.53 is configured to do transformations with
| mod_sed in contexts where the input to mod_sed may be very large,
| mod_sed may make excessively large memory allocations and trigger an
| abort.
CVE-2022-30556[6]:
| Apache HTTP Server 2.4.53 and earlier may return lengths to
| applications calling r:wsread() that point past the end of the storage
| allocated for the buffer.
As usual Apache fails to directly identify fixing commits at
https://httpd.apache.org/security/vulnerabilities_24.html
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2022-31813
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31813
[1] https://security-tracker.debian.org/tracker/CVE-2022-26377
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26377
[2] https://security-tracker.debian.org/tracker/CVE-2022-28614
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28614
[3] https://security-tracker.debian.org/tracker/CVE-2022-28615
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28615
[4] https://security-tracker.debian.org/tracker/CVE-2022-29404
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29404
[5] https://security-tracker.debian.org/tracker/CVE-2022-30522
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30522
[6] https://security-tracker.debian.org/tracker/CVE-2022-30556
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30556
Please adjust the affected versions in the BTS as needed.
Bug#995368: libapache2-mod-proxy-uwsgi 2.0.14+20161117-3+deb9u4 - duplicated request path
reassign 995368 uwsgi thanks Am Fri, Oct 01, 2021 at 04:16:05PM +0200 schrieb Josef Kejzlar, wpj s.r.o.: > 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. 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
Bug#881725: apache2: reload fails inside (libvirt) lxc container
On Mon, Apr 16, 2018 at 02:34:00PM -0400, Matthew Gabeler-Lee wrote: > On Sat, 14 Apr 2018, Stefan Fritsch wrote: > > > This seems to be a systemd bug. Changing PrivateTmp from true to false in > > apache2.service fixes the issue. But even with PrivateTmp it works for > > some time. It would be interesting what is the trigger to make it fail > > later on. > > Hmm ... I was having a problem on some systems where tmpreaper, in its > default configuration, will eventually delete all the directories systemd > creates to support PrivateTmp, which might explain this... Just for the record, we've also tracked it down to the use of PrivateTmp (but I hadn't followed up on this bug since we haven't analysed this to full extent). The workaround deployed is here: https://github.com/wikimedia/puppet/commit/388d0141ef3b78471eb81b59e1ccb196adf49872 It's specific to our configuration for Mediawiki application servers, but those are fairly complex to begin with (e.g. there's various Mediawiki extensions which shell out to external binaries (e.g. to convert musical typesheets edited in Wikimedia projects)). I wouldn't call this a bug in systemd, it's probably something local in the setup of the various components using /tmp (and we don't have this problem on our non-mediawiki stretch Apache setups). Using PrivateTmp in apache.service by default seems totally sensible to me. As such, I'd recommend to simply close this bug. Anyone searching for that error message via a search engine will hopefully find it as a useful reference. Cheers, Moritz
Re: Passing LDFLAGS to Apache modules for hardened build flags
On Mon, Apr 16, 2012 at 05:37:24PM +0200, Moritz Mühlenhoff wrote: On Sat, Apr 14, 2012 at 04:50:44PM +0200, Arno Töll wrote: On 14.04.2012 16:42, Moritz Mühlenhoff wrote: I can rebuild the Apache modules in the archive with test builds if that helps. I committed a fix to apxs in our VCS yesterday [1]. This will allow you to override LDFLAGS just like it is possible for CFLAGS. Moreover, this change automatically injects hardening flags through apxs if the Apache2 server was built itself with it. Consider this behavior highly experimental and not widely tested. It is probably included in our next upload to experimental and/or unstable unless I find problems with it. This only affects modules built against Apache 2.4 in experimental which we plan to release with Wheezy. This means there aren't too many where you could see this behavior already [2]. Let me know if that helps you, as that will mean all Apache modules in Wheezy (i.e. _after_ the transition) will be built by default with hardening flags unless the maintainer opted out by overriding CFLAGS/CPPFLAGS/LDFLAGS through apxs explicitly. Thank your for the nice and fast turnaround in addressing this, much appreciated! I'll run test builds of the Apache modules in the archive with 2.4.2-1 and followup on the individual bug reports. I was about to run test builds now. Since the plan is to no longer go with 2.4 for Wheezy, will you backport the changes to 2.2 or is this for post-Wheezy? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120527095358.GA25810@pisco.westfalen.local
Re: Passing LDFLAGS to Apache modules for hardened build flags
On Sat, Apr 14, 2012 at 04:50:44PM +0200, Arno Töll wrote: On 14.04.2012 16:42, Moritz Mühlenhoff wrote: I can rebuild the Apache modules in the archive with test builds if that helps. I committed a fix to apxs in our VCS yesterday [1]. This will allow you to override LDFLAGS just like it is possible for CFLAGS. Moreover, this change automatically injects hardening flags through apxs if the Apache2 server was built itself with it. Consider this behavior highly experimental and not widely tested. It is probably included in our next upload to experimental and/or unstable unless I find problems with it. This only affects modules built against Apache 2.4 in experimental which we plan to release with Wheezy. This means there aren't too many where you could see this behavior already [2]. Let me know if that helps you, as that will mean all Apache modules in Wheezy (i.e. _after_ the transition) will be built by default with hardening flags unless the maintainer opted out by overriding CFLAGS/CPPFLAGS/LDFLAGS through apxs explicitly. Thank your for the nice and fast turnaround in addressing this, much appreciated! I'll run test builds of the Apache modules in the archive with 2.4.2-1 and followup on the individual bug reports. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120416153721.GA4100@pisco.westfalen.local
Re: Passing LDFLAGS to Apache modules for hardened build flags
On Mon, Apr 09, 2012 at 10:15:23PM +0200, Arno Töll wrote: Hi Moritz, On 08.04.2012 22:10, Moritz Muehlenhoff wrote: Hi, I'm working on hardened build flags for Squeeze and I'm looking into how to pass hardened build flags to Apache modules. Perhaps we should add hardening flags to config_vars.mk which is where apxs gets defaults from. However, sadly both apr-config and apxs completely apparently ignore any override. We should address that for Wheezy but we probably need to patch upstreams apxs to achieve that. I can see how there are use cases to override linking flags at build time. The CFLAGS stuff is handled correctly. However for LDFLAGS, this results in the following error: Yes. If you look at the apxs source, you will see: # create link command ... my $apr_ldflags=`$apr_config --ldflags`; chomp($apr_ldflags); $opt .= -rpath $CFG_LIBEXECDIR -module -avoid-version $apr_ldflags; ... push(@cmds, $libtool $ltflags --mode=link --tag=disable-static $CFG_CC -o $dso_file $opt $lo); i.e. it reads linking flags from apr-config only, no way to override that, it does not even use shell override. You can override PREFIX, TARGET, SYSCONFDIR, CFLAGS, INCLUDEDIR, CC, LIBEXECDIR and SBINDIR only. I see. I got this impression from the apxs manpage, which indicates it should work out: Query Options -q Performs a query for apxs's knowledge about certain settings. The query parameters can be one or more of the following estrings: CC, CFLAGS, CFLAGS_SHLIB, INCLUDEDIR, LD_SHLIB, LDFLAGS_SHLIB, LIBEXECDIR, LIBS_SHLIB, SBINDIR, SYSCONFDIR, TARGET. .PP Use this for manually determining settings. For instance use INC=-I`apxs -q INCLUDEDIR` .PP inside your own Makefiles if you need manual access to Apache's C header files. I consider that a bug and I will see to patch that for the upcoming 2.4 package. This does not help you for Squeeze though. This is not for Squeeze, all the hardening efforts are targeted at Wheezy and beyond. Generally speaking I am not sure whether it makes sense to inject hardening flags per package individually. Maybe we should tweak apxs to use hardening flags by default instead. What do you think? We build Apache with hardening flags already, it wouldn't be much of a problem to provide the very same hardening flags used for the Apache package to modules built with apxs later. The only problem is that apxs makes it difficult to remove a flag from the defaults once provided as a default. Thus we should make sure they do not cause any problem to any module. I can rebuild the Apache modules in the archive with test builds if that helps. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120414144234.GA5872@pisco.westfalen.local
Bug#273412: Patch for this vulnerability
Attached patch brings the upstream fix in proper dpatch format for
debian/patches and compiles cleanly.
Cheers,
Moritz
--
Moritz Mühlenhoff [EMAIL PROTECTED] fon: +49 421 22 232- 0
DevelopmentLinux for Your Business
Univention GmbHhttp://www.univention.de/ fax: +49 421 22 232-99
--- build-tree.orig/apache2/server/core.c 2004/08/31 08:16:56 1.225.2.27
+++ build-tree/apache2/server/core.c 2004/09/21 13:21:16 1.225.2.28
@@ -351,9 +351,13 @@
/* Otherwise we simply use the base-sec_file array
*/
+/* use a separate -satisfy[] array either way */
+conf-satisfy = apr_palloc(a, sizeof(*conf-satisfy) * METHODS);
for (i = 0; i METHODS; ++i) {
if (new-satisfy[i] != SATISFY_NOSPEC) {
conf-satisfy[i] = new-satisfy[i];
+} else {
+conf-satisfy[i] = base-satisfy[i];
}
}
