Bug#316173: apache2: Security issues in HTTP proxy responses with both Transfer-Encoding and Content-Length headers

[Moritz Muehlenhoff]

Steve Kemp wrote:
  |Proxy HTTP: If a response contains both Transfer-Encoding
  |and a Content-Length, remove the Content-Length to eliminate
  |an HTTP Request Smuggling vulnerability and don't reuse the
  |connection, stopping some HTTP Request Spoofing attacks.
 
   Can I be the first to say that I don't understand the nature of this
  issue?

This seems to be an Apache specific variation of the HTTP Request Smuggling
attacks described in the original Watchfire paper:
http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf

Apache rejects packets with multiple Content-Length headers, but it
seems as if it uses size information constructed from the Transfer-
Encoding headers instead, which make this attack possible?

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#326435: CAN-2005-2728: DoS through overly long Range values passed to the byte-range filter

[Moritz Muehlenhoff]

Package: apache2
Severity: important
Tags: security

CAN-2005-2728 describes a DoS vulnerability through overly long values
in the Range field. Please see 
http://issues.apache.org/bugzilla/show_bug.cgi?id=29962
for a more complete description and a patch.

Cheers,
Moritz

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Apache 1 in Etch

[Moritz Muehlenhoff]

Dear Apache maintainers,
I suppose that six years after the release of Apache 2 Etch will
no longer ship with Apache 1?

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Apache 1 in Etch

[Moritz Muehlenhoff]

Matthew Wilcox wrote:
  Dear Apache maintainers,
  I suppose that six years after the release of Apache 2 Etch will
  no longer ship with Apache 1?
 
 We discussed that just the other day (which led to the most recent
 upload).  Apache 1.3 still has a use; in particular, some software is
 still not ported to Apache 2.0, let alone 2.2.

I'm not convinced that this is a good idea. Which packages in the archive
still don't work with Apache 2? No other distro ships Apache 1 in new
releases.
All site-local packages can be fixed until Dec. 2007, the time
security support for Sarge will end.

 There's still upstream
 security support for 1.3, so we intend to ship 1.3 with etch.

It has now, but if it's included in Etch it means that the Security Team
has to maintain it until at least June 2009. Historically most of
the vulnerabilities in Apache 1 applied to version 2 as well, so
it's twice the amount of work and should only be done for good reason.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Apache 1 in Etch

[Moritz Muehlenhoff]

Adam Conrad wrote:
 Moritz Muehlenhoff wrote:
  It has now, but if it's included in Etch it means that the Security Team
  has to maintain it until at least June 2009. Historically most of
  the vulnerabilities in Apache 1 applied to version 2 as well, so
  it's twice the amount of work and should only be done for good reason.

 Traditionally, I've had no issues with preparing stable-security updates
 of both apache1.3 and apache2, and would be happy to do this again in
 the future, if communication between the security team and debian-apache
 isn't too problematic for this to be a reality.

The offer is appreciated, but as long as there's no solid technical reason
we shouldn't duplicate it. Please point to the packages in the archive still
depending on Apache 1.3.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#357561: privilege escalation hole

[Moritz Muehlenhoff]

Joey Hess wrote:
 On the third hand, this bug has documented a security hole with exploit
 in apache for about 2 weeks without any reaction from its maintainers,
 and was open for many months before that without any reaction from them.
 If apache isn't being maintained, it might be better to drop it from
 etch anyway.

Indeed, I'm quite disappointed about apache 1.3 still being in Etch.
Debian is the _only_ distribution still shipping it; the maintainers
couldn't provide _any_ valid reason to still include it (like an important
module not ported to 2.x) and claimed that they would provide all security
updates for 1.3 issues. Well...

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#418266: apache: Should not be included in Lenny

[Moritz Muehlenhoff]

Package: apache
Severity: serious

Apache 1.3 is obsolete and should not be included in Lenny, which would
require to support it at least until 2011.

Cheers,
Moritz

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [OSRM] please review apache2 2.0.54-5sarge2

[Moritz Muehlenhoff]

On Wed, Jul 18, 2007 at 11:28:39PM +0200, Martin Zobel-Helas wrote:
 Hi, 
 
 On Wed Jul 18, 2007 at 23:24:19 +0200, Stefan Fritsch wrote:
  Hi,
  
  please review apache2 2.0.54-5sarge2 for the next sarge point release:
  
  
  apache2 (2.0.54-5sarge2) stable; urgency=low
  
* Fix some less critical security issues:
* Denial of service for threaded MPMs:
  - CVE-2005-2970: mpm_worker memory leak
  - CVE-2005-3357: mod_ssl with custom errorpage
  - CVE-2007-1863: mod_cache
* Cross site scripting:
  - CVE-2005-3352: mod_imap
  - CVE-2006-3918: via Expect header
  - CVE-2006-5752: mod_status
* Add check for scoreboard PID protection (CVE-2007-3304)
  
   -- Stefan Fritsch [EMAIL PROTECTED]  Mon, 16 Jul 2007 23:12:36 +0200
 
 Moritz, will this be going via security?

No, none of these warrants a DSA.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Passing LDFLAGS to Apache modules for hardened build flags

[Moritz Muehlenhoff]

Hi,
I'm working on hardened build flags for Squeeze and I'm looking into
how to pass hardened build flags to Apache modules. 

According to the apxs2 manpage the following should work:

APACHE_CFLAGS = `dpkg-buildflags --get CFLAGS`
APACHE_CFLAGS += `dpkg-buildflags --get CPPFLAGS`
APACHE_LDFLAGS = `dpkg-buildflags --get LDFLAGS`

(..)

apxs2 -S CFLAGS=$(APACHE_CFLAGS) -S LDFLAGS_SHLIB=$(APACHE_LDFLAGS) (..)

The CFLAGS stuff is handled correctly. However for LDFLAGS, this
results in the following error:

apxs:Error: no config variable LDFLAGS_SHLIB
Usage: apxs -g [-S var=val] -n modname
   apxs -q [-S var=val] query ...
   apxs -c [-S var=val] [-o dsofile] [-D name[=value]]
   [-I incdir] [-L libdir] [-l libname] [-Wc,flags]
   [-Wl,flags] [-p] files ...
   apxs -i [-S var=val] [-a] [-A] [-n modname] dsofile ...
   apxs -e [-S var=val] [-a] [-A] [-n modname] dsofile ...
make: *** [install] Fehler 1

Any idea, what might be wrong here?

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/20120408201014.GA4193@pisco.westfalen.local

Bug#878920: IncludeOptional should deal gracefully with a missing directory in the specified path

[Moritz Muehlenhoff]

Source: apache2
Version: 2.4.25-3+deb9u3
Severity: normal

Hi,
libapache2-mod-security2 sets a Recommends: on modsecurity-crs and ships a
/etc/apache2/mods-enabled/security2.conf with the following directive:

-
# Include OWASP ModSecurity CRS rules if installed
IncludeOptional /usr/share/modsecurity-crs/owasp-crs.load
-

But when installing on a system where the installation of recommended packages
is disabled, modsecurity-crs isn't installed and as such the the
/usr/share/modsecurity-crs/ directory isn't present, which makes the
IncludeOptional directive fail and preventing the Apache startup:

-
Oct 17 14:57:17 foo systemd[1]: Starting The Apache HTTP Server...
Oct 17 14:57:17 foo apachectl[18942]: apache2: Syntax error on line 11 of 
/etc/apache2/apache2.conf: Syntax error on line 12 of 
/etc/apache2/mods-enabled/security2.conf:
Could not open config directory /usr/share/modsecurity-crs: No such file or 
directory
Oct 17 14:57:17 foo apachectl[18942]: Action 'start' failed.
-

Creating /usr/share/modsecurity-crs/ fixes it, but that seems like a 
misfeature/bug?
Shouldn't it also fail gracefully in the absence of one of the path elements?

Cheers,
Moritz

Bug#878920: IncludeOptional should deal gracefully with a missing directory in the specified path

[Moritz Muehlenhoff]

forwarded 878920 https://bz.apache.org/bugzilla/show_bug.cgi?id=57585
thanks

Hi,

On Tue, Oct 17, 2017 at 07:27:54PM +0200, Moritz Muehlenhoff wrote:
> Creating /usr/share/modsecurity-crs/ fixes it, but that seems like a 
> misfeature/bug?
> Shouldn't it also fail gracefully in the absence of one of the path elements?

It turns out this is already reported upstream:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57585

Cheers,
Moritz

Bug#879708: CVE-2017-12613 CVE-2017-12618

[Moritz Muehlenhoff]

Source: apr-util
Severity: important
Tags: security

I'm sure you're aware, but filing for completeness in the BTS anyway:
http://mail-archives.apache.org/mod_mbox/apr-dev/201710.mbox/%3CCACsi252POs4toeJJciwg09_eu2cO3XFg%3DUqsPjXsfjDoeC3-UQ%40mail.gmail.com%3E
 

Cheers,
Moritz

Bug#879708: CVE-2017-12613 CVE-2017-12618

[Moritz Muehlenhoff]

On Tue, Oct 24, 2017 at 10:28:02PM +0200, Moritz Muehlenhoff wrote:
> Source: apr-util
> Severity: important
> Tags: security
> 
> I'm sure you're aware, but filing for completeness in the BTS anyway:
> http://mail-archives.apache.org/mod_mbox/apr-dev/201710.mbox/%3CCACsi252POs4toeJJciwg09_eu2cO3XFg%3DUqsPjXsfjDoeC3-UQ%40mail.gmail.com%3E
>  

Actually CVE-2017-12618 is in apr-util and CVE-2017-12613 in apr

I don't think any of those need a DSA, but let me know if you disagree.

Cheers,
Moritz

Bug#881725: apache2: reload fails inside (libvirt) lxc container

[Moritz Muehlenhoff]

Stefan Fritsch wrote:
> On Monday, 16 April 2018 20:34:00 CEST 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...
> 
> That seems a likely explanation. I have tmpreaper installed, too. The default 
> keep time is 7 days, which explains why the issue does not appear immediately.
> 
> So tmpreaper should exclude systemd-private-* files by default. Moritz, do 
> you 
> also have some cron job cleaning up stale files in /tmp ?

Good catch, in fact we do! And it's only enabled for our mediawiki 
installations,
which would also explain why we don't run into it with our other Apache 
installations
on stretch:
https://github.com/wikimedia/puppet/blob/production/modules/profile/manifests/mediawiki/common.pp#L16
and 
https://github.com/wikimedia/puppet/blob/production/modules/tmpreaper/manifests/init.pp

Cheers,
Moritz

Bug#881725: apache2: reload fails inside (libvirt) lxc container

[Moritz Muehlenhoff]

On Mon, Apr 23, 2018 at 09:48:03PM +0200, Stefan Fritsch wrote:
> On Monday, 16 April 2018 21:51:36 CEST Stefan Fritsch wrote:
> > So tmpreaper should exclude systemd-private-* files by default. Moritz, do
> > you also have some cron job cleaning up stale files in /tmp ?
> 
> tmpreaper needs to exclude dirs inside the  systemd-private-* dir, too (there 
> is a tmp dir inside). There does not seem to be a recursive mode and
> 
> TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private*'
> 
> did not help. Probably something like
> 
> TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private*/*'
> 
> should work better.

I've run some initial tests and that seems to fix it, but I'll do some more
tests tomorrow.

Cheers,
Moritz

Bug#881725: apache2: reload fails inside (libvirt) lxc container

[Moritz Muehlenhoff]

reassign 881725 tmpreaper
retitle 881725 tmpreaper breaks systemd services using PrivateTmp=true
severity 881725 important
tags 881725 patch
thanks

On Tue, Apr 24, 2018 at 07:17:32PM +0200, Moritz Muehlenhoff wrote:
> On Mon, Apr 23, 2018 at 09:48:03PM +0200, Stefan Fritsch wrote:
> > On Monday, 16 April 2018 21:51:36 CEST Stefan Fritsch wrote:
> > > So tmpreaper should exclude systemd-private-* files by default. Moritz, do
> > > you also have some cron job cleaning up stale files in /tmp ?
> > 
> > tmpreaper needs to exclude dirs inside the  systemd-private-* dir, too 
> > (there 
> > is a tmp dir inside). There does not seem to be a recursive mode and
> > 
> > TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private*'
> > 
> > did not help. Probably something like
> > 
> > TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private*/*'
> > 
> > should work better.
> 
> I've run some initial tests and that seems to fix it, but I'll do some more
> tests tomorrow.

Yeah, confirmed that this fixes it. I'm reassigning the bug to tmpreaper.

Summary:
tmpreaper disrupts systemd services using PrivateTmp=true since those are using
a private filesystem namespace which tmpreaper is unaware of. This was noticed
with Apache (which uses PrivateTmp=true in stretch), but should equally apply
to other services.

Supporting these to full extent would either require to add support to 
tmpreaper to 
support reaping those (or maybe rather add an option to systemd to support 
similar 
functionality), but I think a good interim solution is to skip those private 
tmps
in tmpreaper for now.

Steps to reproduce:
- Install apache2
- A "systemctl reload apache2" should work fine
- Add a dummy file to /tmp
- Set TMPREAPER_TIME=1m in /etc/tmpreaper.conf so that the next tmpreaper run 
removes
  the dummy file
- Wait a minute and run /etc/cron.daily/tmpreaper
- Dummy file should be gone now
- systemctl reload apache2" should work fine should now fail with the error
  "Failed at step NAMESPACE spawning /usr/sbin/apachectl"

Fix:

Since systemd is Debian's default init system and given that PrivateTmp is an 
increasingly
used option, I'd suggest that it's at least added to the existing directories 
using
--protect in /etc/cron.daily/tmpreaper.

Maybe also add it to TMPREAPER_PROTECT_EXTRA by default, but I think adding it 
to
the default cron is the more important change:

--- /etc/cron.daily/tmpreaper.orig  2018-04-25 12:52:52.353639990 +
+++ /etc/cron.daily/tmpreaper   2018-04-25 12:53:30.385144805 +
@@ -105,5 +105,6 @@
   --protect '/tmp/lost+found' \
   --protect '/tmp/journal.dat' \
   --protect '/tmp/quota.{user,group}' \
+  --protect '/tmp/systemd-private*/*' \
   `for i in $TMPREAPER_PROTECT_EXTRA; do echo --protect "$i"; done` \
   $TMPREAPER_DIRS

Cheers,
   Moritz

Bug#1012513: apache2: CVE-2022-31813 CVE-2022-26377 CVE-2022-28614 CVE-2022-28615 CVE-2022-29404 CVE-2022-30522 CVE-2022-30556

[Moritz Muehlenhoff]

On Wed, Jun 08, 2022 at 07:51:28PM +0200, Yadd wrote:
> Hi,
> 
> those CVEs are tagged low/moderate by upstream, why did you tag this bug as 
> grave ?

Anything moderate or above should get fixed by the next Debian release IOW RC 
severity.

Cheers,
Moritz

Bug#1032476: apache2: CVE-2023-25690 CVE-2023-27522

[Moritz Muehlenhoff]

On Wed, Mar 08, 2023 at 07:09:20AM +0400, Yadd wrote:
> On 3/7/23 23:46, Salvatore Bonaccorso wrote:
> > Source: apache2
> > Version: 2.4.55-1
> > Severity: grave
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerabilities were published for apache2.
> > 
> > CVE-2023-25690[0]:
> > 
> > CVE-2023-27522[1]:
> 
> Hi,
> 
> here is the debdiff for Bullseye

I'm fine with a DSA, but we've seen a fair amount of regressions in 2.4.x 
releases,
so let's wait a few days for regressions reported in sid (and Ondreys PHP repo).

You can already upload the new version, though (we can reject/reupload if 
needed).

Cheers,
Moritz

Re: CVE-2023-25690: Apache2 mod_proxy for old(old)stable?

[Moritz Muehlenhoff]

Hi Philipp,

>  lists
> "2.4.38-3+deb10u9" from Debian-10-Buster as still vulnerable.
> Are there any plans to back-port the change to that older version, e.g.
> - Debian-10-Buster Security
> - Debian-9-Stretch ELTS (Freexian)
> 
> If this is already some work-in-progress maybe you can share some
> information on the progress and if there is an estimated time frame.
> 
> According to my own research 
> 
> and 
> 
> apply cleanly also to both 2.4.25-3+deb9u14 and 2.4.38-3+deb10u9. Ubuntu
> seems to go with just these two commits:
> 
> 
> Thank you for your work and time

Buster is in LTS stage at this point, you should direct your question
to debian-lts@l.d.o instead.

Greetings to Horn-Lehe :-)

Moritz

Bug#1068412: apache2: CVE-2024-27316 CVE-2024-24795 CVE-2023-38709

[Moritz Muehlenhoff]

On Fri, Apr 05, 2024 at 08:16:43AM +0400, Yadd wrote:
> On 4/4/24 22:51, Moritz Mühlenhoff wrote:
> > 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.
> 
> Hi,
> 
> I'm ready to push 2.4.59 into bookworm-security. Note that this includes a
> test-framework update

Target distribution needs to be bookworm-security, with that please upload.
Can you also preparea the equivalent change for bullseye-security?

The uploads can already happen, but let's keep the update unreleased until
next week, then we can look for regressions reported in unstable (and check
with Ondrej if we received reports based on his repo)

Cheers,
Moritz