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

[Yadd]

On 4/5/24 15:58, Moritz Muehlenhoff wrote:

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


Both Bullseye and Bookworm uploaded. Bullseye version embeds also a 
copyright fix

Re: Need Some Help

[Yadd]

On 3/7/24 20:52, Ali Ramzan wrote:

Hi,

I am currently using Debian Apache version on my Debian server, but when 
I perform a scan, I am alerted to several vulnerabilities. Specifically, 
the Apache version 2.4.x is vulnerable to multiple CVEs, including 
2023-31122, 2023-43622, and 2023-45802.


I have a couple of questions: When will Debian release Apache version 
2.4.58, which resolves these vulnerabilities? Also, where can I find a 
link to this release and its release date? Finally, is there any way for 
me to fix these vulnerabilities in the meantime?


Hi,

version 2.4.58 doesn't contain important CVE fixes, only minor/medium. 
So it will be updated during a Debian point release and not in security 
branch.


Cheers,
Yadd

Bug#1018718: marked as pending in apache2

[Yadd]

On 4/2/23 07:56, Christoph Anton Mitterer wrote:

Hey.

Thanks for the fix.

Am I right that this *generally* does not longer enable apache2-
doc.conf per default (i.e. also on fresh installs)?


Hi,

yes you're right


Causes that would also make it fix #977014.


Sure, thanks for the link

I saw in this issue that you were a little frustrated by the lack of 
responsiveness in apache2 maintenance. But apache2 is "RFH" and I'm not 
C expert neither apache user so I try to do my best until someone more 
qualified takes over.


Best regards,
Yadd

Bug#1033770: bullseye-pu: package apache2/2.4.56-1~deb11u2

[Yadd]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: apac...@packages.debian.org
Control: affects -1 + src:apache2

[ Reason ]
apache2 silently reenable apache2-doc.conf despite having been disabled
(#1018718)

[ Impact ]
This behavior  overwrites local changes on upgrade, which is a
release-critical bug as it’s a Policy violation

[ Tests ]
No change

[ Risks ]
No risk here

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Drop apache2-doc.postinst

[ Other ]
Fixed in testing/Bookworm in version 2.4.54-3.

Cheers,
Yadd
diff --git a/debian/NEWS b/debian/NEWS
new file mode 100644
index ..c048ae45
--- /dev/null
+++ b/debian/NEWS
@@ -0,0 +1,9 @@
+apache2 (2.4.56-1~deb11u2) bullseye; urgency=medium
+
+  This version does not automatically enable the apache2 config snippet for
+  /manual anymore. If you want to have it enabled you will need to do this
+  yourself, e.g. with
+
+/usr/sbin/a2enconf apache2-doc
+
+ -- Yadd   Sat, 01 Apr 2023 08:17:08 +0400
diff --git a/debian/apache2-doc.postinst b/debian/apache2-doc.postinst
deleted file mode 100644
index e7e1e5a7..
--- a/debian/apache2-doc.postinst
+++ /dev/null
@@ -1,17 +0,0 @@
-#! /bin/sh
-
-set -e
-
-# conffiles must be moved before invoking rc.d
-#DEBHELPER#
-
-# This code should use dh_apache2 once it is available as build dependency
-
-if [ "$1" = "configure" ] ; then
-   if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
-   . /usr/share/apache2/apache2-maintscript-helper
-   apache2_invoke enconf apache2-doc || true
-   fi
-fi
-
-exit
diff --git a/debian/changelog b/debian/changelog
index 41c3a7cc..1c0d3659 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+apache2 (2.4.56-1~deb11u2) bullseye; urgency=medium
+
+  [ Hendrik Jäger ]
+  * Don't automatically enable apache2-doc.conf (Closes: #1018718)
+
+ -- Yadd   Sat, 01 Apr 2023 08:24:10 +0400
+
 apache2 (2.4.56-1~deb11u1) bullseye-security; urgency=medium
 
   * New upstream version (Closes: #1032476, CVE-2023-27522, CVE-2023-25690)

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

[Yadd]

On 3/8/23 22:39, Moritz Muehlenhoff wrote:

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


Hi,

thanks, I just uploaded it.

Regards,

Bug#967010: apache2: Did not reporoduce

[Yadd]

Le Mardi, Novembre 08, 2022 16:01 CET, Shai Berger  a écrit:
> Package: apache2
> Followup-For: Bug #967010
>
> Dear Maintainer,
>
> I just installed Apache2 and did not encounter the problem
> as reported in this bug.
>
> It is an old bug, and for some reason full of spam.
>
> Please close and/or delete it.
>
> Thanks.

Hi, it's a Buster-only bug, not a Bullseye's one

Bug#1014056: apache2: /var/run/apache2 permissions too narrow for cgid

[Yadd]

On 29/06/2022 16:51, MK wrote:

Package: apache2
Version: 2.4.53-1~deb11u1
Severity: minor


Dear Maintainer,


*** Reporter, please consider answering these questions, where appropriate ***


Enabling cgid in apache2 (with a2enmod cgid) results in an error when using 
mpm_event:
     [cgid:error] [pid 8943:tid 140189712234240] (22)Invalid argument: [client 
x.x.x.x:49364] AH01257: unable to connect to cgi daemon after multiple tries: 
/usr/lib/cgi-bin/xx
Meanwhile, the user receives a 503 HTTP error, rather than the CGI content.

Upon launch, Apache creates /var/run/apache2/cgisock.PID (where PID is the PID 
in question), however it does that as the www-data user and root group, who 
does not have write access to /var/run/apache2 (where only the root user has 
write permission).

To fix this, chmod g+rwx /var/run/apache2 fixes the issue.  Since we're only 
adding the root group, this likely has a minimal security effect.

Alternately, the default directive of
     /etc/apache2/mods-available/cgid.conf:    ScriptSock 
${APACHE_RUN_DIR}/cgisock
Should not point to a folder that does not have write access by www-data user 
and a subfolder with more open permission should be created.


Hi,

Thanks for the report. Alternative: I tried to move cgid socket into 
${APACHE_RUN_DIR}/socks/cgisock, created now by apache2ctl and owned by 
www-data 
(https://salsa.debian.org/apache-team/apache2/-/pipelines/395609). Then 
no security changes.


Let's wait for pipeline result

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

[Yadd]

Hi,

those CVEs are tagged low/moderate by upstream, why did you tag this bug as 
grave ?

Cheers,
Yadd

Le Mercredi, Juin 08, 2022 17:49 CEST, Moritz Mühlenhoff  a 
écrit:

> 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.
>

Re: Dependancy broken on apache2-dev with libldap-2.4-2 (libaprutil1-dev)

[Yadd]

Le Lundi, Mai 30, 2022 10:34 CEST, Vincent GUESNARD 
 a écrit:
> Hello,
>
> First, thanks you very much for all you did and do for Apache2, it's a real 
> amazing job.
>
> It's my first report, so i apologize if it's not < the good manner >.
>
> This security release : 
> https://tracker.debian.org/news/1326206/accepted-openldap-2457dfsg-3deb11u1-source-into-stable-security-embargoed-stable-security/
>  has broken apache2-dev by broking libaprutil1-dev
>
> apt install -f  apache2-dev
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> The following packages have unmet dependencies:
> libldap2-dev : Depends: libldap-2.4-2 (= 2.4.57+dfsg-3) but 
> 2.4.57+dfsg-3+deb11u1 is to be installed
> E: Unable to correct problems, you have held broken packages.

Hi,

1 - problem is in openldap only (fixed dependency between 2 openldap packages)
2 - this will be automatically fixed when package will be published: 
libldap-2.4 will be updated in the same time than libldap2-dev

Cheers,
Yadd

> I don't know who must be warn so i warn on 
> debian-apache@lists.debian.org<mailto:debian-apache@lists.debian.org> hoping 
> it will be handled by the good maintainer.
>
> Nothing urgent or serious since there is a simple temporary workarround by 
> holding  2.4.57+dfsg-3+deb11u1
>
> Thanks you,
>
> Kind regards,
>
> Vincent
>
>

Bug#1000114: apache2: depends on obsolete pcre3 library

[Yadd]

On 28/12/2021 19:40, Yadd wrote:

On 28/12/2021 08:25, Sebastiaan Couwenberg wrote:

On Sun, 21 Nov 2021 17:17:32 + Matthew Vernon wrote:

On 19/11/2021 21:46, Yadd wrote:

> Sadly pcre2 does not provide /usr/bin/pcre-config, I'm unable to do 
this

> change

Well, there is pcre2-config, but that's a little beside the point - 
pcre2 is not a drop-in replacement for pcre, so it is likely some 
code work will be required, probably by upstream.


There is support for pcre2 on trunk:

  https://github.com/apache/httpd/blob/trunk/include/ap_regex.h
  https://github.com/apache/httpd/blob/trunk/server/util_pcre.c

See also:


https://helperbyte.com/questions/457338/how-to-make-pcre2-support-for-apache-24 



Kind Regards,

Bas



Thanks,

I still have a problem with this part of the patch

@@ -115,7 +127,7 @@

  AP_DECLARE(void) ap_regfree(ap_regex_t *preg)
  {
-    (pcre_free)(preg->re_pcre);
+    pcre2_code_free(preg->re_pcre);
  }

I don't find any pcre2_code_free function, there are many pcre2*_free 
functions, which one is the good ?


Found, was a LDPATH problem

Bug#1000114: apache2: depends on obsolete pcre3 library

[Yadd]

On 28/12/2021 08:25, Sebastiaan Couwenberg wrote:

On Sun, 21 Nov 2021 17:17:32 + Matthew Vernon wrote:

On 19/11/2021 21:46, Yadd wrote:

> Sadly pcre2 does not provide /usr/bin/pcre-config, I'm unable to do 
this

> change

Well, there is pcre2-config, but that's a little beside the point - 
pcre2 is not a drop-in replacement for pcre, so it is likely some code 
work will be required, probably by upstream.


There is support for pcre2 on trunk:

  https://github.com/apache/httpd/blob/trunk/include/ap_regex.h
  https://github.com/apache/httpd/blob/trunk/server/util_pcre.c

See also:


https://helperbyte.com/questions/457338/how-to-make-pcre2-support-for-apache-24 



Kind Regards,

Bas



Thanks,

I still have a problem with this part of the patch

@@ -115,7 +127,7 @@

 AP_DECLARE(void) ap_regfree(ap_regex_t *preg)
 {
-(pcre_free)(preg->re_pcre);
+pcre2_code_free(preg->re_pcre);
 }

I don't find any pcre2_code_free function, there are many pcre2*_free 
functions, which one is the good ?

Re: Fix for CVE-2021-40438 in bullseye missing?

[Yadd]

Le 26/11/2021 à 14:31, Holger Mickler a écrit :
> Dear apache maintainers,
> 
> as far as I can see in the changelog of apache2 in bullseye
> (https://packages.debian.org/bullseye/apache2)
> ->
> https://metadata.ftp-master.debian.org/changelogs//main/a/apache2/apache2_2.4.48-3.1+deb11u1_changelog
> 
> the latest version is as of Thu, 12 Aug 2021 13:51:47 +0200 and there is
> no patch for the above mentioned CVE yet?
> 
> As buster has it already - can you please provide the patch for
> bullseye, too?
> 
> Thanks and sorry if I overlooked sth.
> Holger

Hi,

Apache2 in Bullseye follows upstream changes, so no need to produce a
patch. See https://security-tracker.debian.org/tracker/CVE-2021-40438

Cheers,
Yadd

Bug#1000627: apache2: missing dependency setting

[Yadd]

Le 26/11/2021 à 03:03, westlake a écrit :
> Package: apache2
> Version: 2.4.48-3.1+deb11u1
> Severity: important
> 
> apache2 can fail to start if the user defines a specific interface.
> 
> the workaround meanwhile is to add "network-online.target" to the
> systemd unit.
> 
> The issue noticeably occurs when the user decides to use
> "systemd-networkd" for the configuration rather than
> /etc/network/interfaces.
> 
> A bugreport was initially provided to systemd explaining the problem in
> greater detail, however a lead maintainer replied that the bug is to be
> forwarded to the server package in question.
>  -- a copy of this original bugreport to systemd/systemd-networkd is
> here for further referencing:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000510
> 
> A server should not fail to "start" just because it is using a specific
> interface.
> 
> I attempted to provide the suggestion for systemd/systemd-networkd
> maintainers to give a policy of having "network-online.target" for
> server programs but I was told that the issue is the specific
> server-package in question. (only two server packages that I use often
> have this problem, openssh-server and apache2)
> 
> journalctl -xe -u [package]  -- shows nothing revealing than ".. failed
> to bind to address x.x.x.x". "networkctl" -- all shows green
> highlighting --- the .network definitions are all correct.
> 
> the problem seems to me the systemd policy of having
> network-online.target as a practice for server unit files is not
> enforced enough..
> 
> though the traditional ifup-networking scripts doesn't have this issue
> afaict.
> 
> .. it happens more often when the user opts not to be using the default
> networking.service and instead go with the newer systemd-networkd method
> for bringing up interfaces during the bootup.
> 
> the user here is not at fault, and should be allowed to set specific
> interfaces for the apache2 and ssh service.
> 
> (fwiw, -- prior setting up the workaround, both ssh and apache2 servers
> will both exhibit the same binding-interface error, as shown in journalctl.
> 
> However when starting these services manually: such as,
> systemctl start apache2.service, and
> systemctl start ssh.service
> 
> there is no problem at all starting these up
> 
> The interfaces are set at the system-level.  There is no
> dbus-triggered/Desktop-login interface settings.
> 
> The problem is systemd++network-online.target not set in the unit files.
> 
> Systemd and Server package maintainers should enforce a better policy so
> that simple changes do not affect the ability to start the service.
> )
> (this bugreport is getting cc'd to the ssh package -- as the problem
> also exists with that package)
> thanks

Hi,

I've no talent in systemd, how can I do that? With:

  Wants=network-online.target
  After=network-online.target

in debian/apache*.service?

Bug#1000114: apache2: depends on obsolete pcre3 library

[Yadd]

Control: tags -1 + moreinfo

Le 18/11/2021 à 12:49, Matthew Vernon a écrit :
> Source: apache2
> Severity: important
> User: matthew-pcre...@debian.org
> Usertags: obsolete-pcre3
> 
> Dear maintainer,
> 
> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev). This has been end of life for a while now, and
> upstream do not intend to fix any further bugs in it. Accordingly, I
> would like to remove the pcre3 libraries from Debian, preferably in
> time for the release of Bookworm.
> 
> The newer PCRE2 library was first released in 2015, and has been in
> Debian since stretch. Upstream's documentation for PCRE2 is available
> here: https://pcre.org/current/doc/html/
> 
> Many large projects that use PCRE have made the switch now (e.g. git,
> php); it does involve some work, but we are now at the stage where
> PCRE3 should not be used, particularly if it might ever be exposed to
> untrusted input.
> 
> This mass bug filing was discussed on debian-devel@ in
> https://lists.debian.org/debian-devel/2021/11/msg00176.html
> 
> Regards,
> 
> Matthew [0] Historical reasons mean that old PCRE is packaged as
> pcre3 in Debian 

Sadly pcre2 does not provide /usr/bin/pcre-config, I'm unable to do this
change

Bug#868861: Mitigation

[Yadd]

Le 22/09/2021 à 13:54, Michiel Hazelhof a écrit :
> The complete and better walkthrough (systemd users only!), some parts
> might be redundant if you allready migrated to the proper systemd
> invocations:
> 
> This completely fixed the "There are processes named 'apache2' running
> which do not match your pid file which are left untouched in the name of
> safety, Please review the situation by hand. ..." warning (and the
> application kill that follows).
> 
> 0: systemctl disable apache2-instancename && systemctl stop
> apache2-instancename
> 1: delete /etc/init.d/apache2 and /etc/init.d/apache2-instancename
> 3: ln -s /usr/sbin/apache2 /usr/sbin/apache2-instancename
> 4: edit /usr/sbin/apache2ctl:
> - Find: HTTPD=${APACHE_HTTPD:-/usr/sbin/apache2}
> - Replace with: HTTPD=${APACHE_HTTPD:-/usr/sbin/apache2$SUFFIX}
> 5: systemctl enable apache2@instancename && systemctl start
> apache2@instancename
> 
> Important notices:
> 0: that your envvars in the apache config should change the suffix from
> @instancename to -instancename as is debians default (if not simply do
> the ln -s with @ instead of -)!
> 1: After every apache upgrade the /usr/sbin/apache2ctl mod needs to be
> performed again!
> 
> On Tue, 6 Jul 2021 09:47:09 +0200 Michiel Hazelhof 
> wrote:
> 
>> Made two small tweaks to hopefully mitigate this behaviour:
> ... Do not follow this post anymore!

Hi,

could you push a merge request ?

Cheers,
Yadd

Bug#967010: apache2: last debian 10.4 , last apache avail from repo hangs on install (and start phase)

[Yadd]

Control: tags -1 + moreinfo

Hi,

I'm unable to reproduce this issue, package apache 2 contains
default-ssl.conf and autopkgtest succeeded to start apache2.

Bug#990853: Problem with Directory directive

[Yadd]

Le 09/07/2021 à 13:12, Stadtsholte, Ingo a écrit :
> Package: apache2
> 
> Version: 2.4.38-3+deb10u4
> 
>  
> 
> After minor updating my Apache Installation to the above Version,
> AuthType in Directory directive only affects to DirectoryIndex, not to
> all other files/subdirectories
> 
>  
> 
> 
> 
>   AuthType GSSAPI
> 
>   require valid-user
> 
>   DirectoryIndex index.php
> 
> 
> 
>  
> 
> Authentication works when I call https://myserver/ 
> but do not work anymore when I call https://myserver/index.php
> 

Hi,

it's not a bug, use  when using an external file handler
(like php-fpm)

> Other problems I had after that update: I had to enable some modules via
> a2enmod. 3 weeks earlier the modules were automatically enabled and the
> AuthType works for the whole directory

Could you give more details ?

Bug#990580: apache2: [regression] daily cron mails from logrotate: Reloading Apache httpd web server: apache2., caused by #979813

[Yadd]

Le 09/07/2021 à 05:04, Thorsten Glaser a écrit :
> Thanks Adam for the analysis!
> 
>> To stop the mails from logrotate, could you please change back:
>> -   invoke-rc.d apache2 reload
>> +   invoke-rc.d apache2 reload > /dev/null 2>&1
>>
>> otherwise, people running Bullseye will be mightily unhappy.
>>
>> I also wonder why such a cleanup was done late during hard freeze.
> 
> Indeed. ping‽ (I intend to NMU if no activity happens.)
> 
> bye,
> //mirabilos

Hi,

Apache2 is RFH for years, feel free to contribute

Bug#989562: apache2: CVE-2021-31618: NULL pointer dereference on specially crafted HTTP/2 request

[Yadd]

Le 08/06/2021 à 10:51, Yadd a écrit :
> Le 08/06/2021 à 08:25, Yadd a écrit :
>> Le 08/06/2021 à 07:58, Yadd a écrit :
>>> Le 07/06/2021 à 17:34, Salvatore Bonaccorso a écrit :
>>>> Source: apache2
>>>> Version: 2.4.47-1
>>>> Severity: grave
>>>> Tags: security upstream
>>>> Justification: user security hole
>>>> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
>>>> 
>>>>
>>>> Hi,
>>>>
>>>> The following vulnerability was published for apache2.
>>>>
>>>> CVE-2021-31618[0]:
>>>> | httpd: NULL pointer dereference on specially crafted HTTP/2 request
>>>>
>>>> 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-2021-31618
>>>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31618
>>>> [1] 
>>>> https://github.com/apache/httpd/commit/a4fba223668c554e06bc78d6e3a88f33d4238ae4
>>>> [2] 
>>>> https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2021-31618
>>>>
>>>> Please adjust the affected versions in the BTS as needed.
>>>>
>>>> Regards,
>>>> Salvatore
>>>
>>> Hi all,
>>>
>>> I can't import the whole patch for Bullseye since it is written for
>>> 2.4.47. I think the best solution is to import the whole http2 module in
>>> Bullseye. This gives the attached patch
>>>
>>> Cheers,
>>> Yadd
>>
>> We can also fix this for Buster using the same way (we did it previously
>> for 2.4.46). Here is the debdiff
> 
> Update for Buster

I as wrong for both Bullseye and Buster: we can't import HTTP2 from
2.4.28 (too intrusive: SSL stack changed)

So I'll try to patch Apache but it seems not easy to do...

Cheers (and sorry),
Yadd

Bug#989562: apache2: CVE-2021-31618: NULL pointer dereference on specially crafted HTTP/2 request

[Yadd]

Le 07/06/2021 à 17:34, Salvatore Bonaccorso a écrit :
> Source: apache2
> Version: 2.4.47-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for apache2.
> 
> CVE-2021-31618[0]:
> | httpd: NULL pointer dereference on specially crafted HTTP/2 request
> 
> 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-2021-31618
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31618
> [1] 
> https://github.com/apache/httpd/commit/a4fba223668c554e06bc78d6e3a88f33d4238ae4
> [2] https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2021-31618
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore

Hi all,

I can't import the whole patch for Bullseye since it is written for
2.4.47. I think the best solution is to import the whole http2 module in
Bullseye. This gives the attached patch

Cheers,
Yadd
Description: import the whole HTTP/2 module from 2.4.47 to fix CVE-2021-31618
Author: Xavier Guimard 
Origin: upstream
Bug: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31618
Bug-Debian: https://bugs.debian.org/989562
Forwarded: not-needed
Reviewed-By: Yadd 
Last-Update: 2021-06-08

--- a/modules/http2/h2.h
+++ b/modules/http2/h2.h
@@ -141,8 +141,19 @@
 unsigned int chunked : 1;   /* iff request body needs to be forwarded as chunked */
 unsigned int serialize : 1; /* iff this request is written in HTTP/1.1 serialization */
 apr_off_t raw_bytes;/* RAW network bytes that generated this 
request - if known. */
+int http_status;/* Store a possible HTTP status code that gets
+ * defined before creating the dummy HTTP/1.1
+ * request e.g. due to an error already
+ * detected.
+ */
 };
 
+/*
+ * A possible HTTP status code is not defined yet. See the http_status field
+ * in struct h2_request above for further explanation.
+ */
+#define H2_HTTP_STATUS_UNSET (0)
+
 typedef struct h2_headers h2_headers;
 
 struct h2_headers {
--- a/modules/http2/h2_bucket_beam.c
+++ b/modules/http2/h2_bucket_beam.c
@@ -945,7 +945,8 @@
 apr_status_t h2_beam_receive(h2_bucket_beam *beam, 
  apr_bucket_brigade *bb, 
  apr_read_type_e block,
- apr_off_t readbytes)
+ apr_off_t readbytes,
+ int *pclosed)
 {
 h2_beam_lock bl;
 apr_bucket *bsender, *brecv, *ng;
@@ -953,7 +954,7 @@
 apr_status_t status = APR_SUCCESS;
 apr_off_t remain;
 int transferred_buckets = 0;
-
+
 /* Called from the receiver thread to take buckets from the beam */
 if (enter_yellow(beam, ) == APR_SUCCESS) {
 if (readbytes <= 0) {
@@ -1039,6 +1040,7 @@
 H2_BLIST_INSERT_TAIL(>hold_list, bsender);
 
 remain -= bsender->length;
+beam->received_bytes += bsender->length;
 ++transferred;
 ++transferred_buckets;
 continue;
@@ -1126,7 +1128,8 @@
 }
 goto transfer;
 }
-leave:
+leave:
+if (pclosed) *pclosed = beam->closed? 1 : 0;
 leave_yellow(beam, );
 }
 return status;
--- a/modules/http2/h2_bucket_beam.h
+++ b/modules/http2/h2_bucket_beam.h
@@ -258,11 +258,15 @@
  * if no data is available.
  *
  * Call from the receiver side only.
+ * @param pclosed  on return != 0 iff the beam has been closed by the sender. It
+ * may still hold untransfered data. Maybe NULL if the caller is
+ * not interested in this.
  */
 apr_status_t h2_beam_receive(h2_bucket_beam *beam, 
  apr_bucket_brigade *green_buckets, 
  apr_read_type_e block,
- apr_off_t readbytes);
+ apr_off_t readbytes,
+ int *pclosed);
 
 /**
  * Determine if beam is empty. 
--- a/modules/http2/h2_config.c
+++ b/modules/http2/h2_config.c
@@ -78,6 +78,7 @@
 int early_hints;  /* support status code 103 */
 int padding_bits;
 int padding_always;
+int output_buffered;
 } h2_config;
 
 typedef struct h2_dir_config {
@@ -115,6 +116,7 @@
 0,  /* early hints, http status 103 */
 0,  /* padding bits */
 1,  /* padding always */
+1,  /* strean output buffered */
 };
 
 static h

Re: CVE-2010-1452: apache2 fix version issue

[Yadd]

Le 14/05/2021 à 07:49, Andrei Nikonov a écrit :
> Good afternoon,
> 
> I am writing to you as you are mentioned as a maintainers of /*apache2*
> /package.
> 
> I did some research about Debian vulnerability data and found an issue.
> 
> If I check CVE-2010-1452
> <https://security-tracker.debian.org/tracker/CVE-2010-1452> with Debian
> Security Tracker page, I will see that fixed version for apache2 is
> *2.2.16-1* (the same version is on page of JSON-formatted security data
> <https://security-tracker.debian.org/tracker/data/json>)
> 
> But information of this CVE in the file of OVAL data for Buster
> <https://www.debian.org/security/oval/oval-definitions-buster.xml> is
> different. Definition of that CVE starts from line 109250 in that file
> (I attached a screenshot for convenience). Criterion below tells that
> /*apache2 DPKG is earlier than 2.2.19-3*.
> /
> /
> /
> My questions are:
> 1. Should I consider fixed version 2.2.19-3 for apache2?
> 2. Should I rely on OVAL files? Is it just a typo in this case?
> 
> Hoping for an answer.

Hi,

security-tracker.debian.org is the reference (updated in real time), it
uses information from cve.mitre.org:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1452

This issue is fixed in 2.2.16-1. 2.2.* versions are so old that some
information are missing, but 2.2.19-3 wasn't a Debian version (see
http://snapshot.debian.org/package/apache2/). So there is probably a
typo in criterion.

Cheers,
Yadd

Bug#988029: apache2: Non-unique IDs being generated by mod_unique_id - Fix available

[Yadd]

Le 03/05/2021 à 23:29, Atle Solbakken a écrit :
> Package: apache2
> Version: 2.4.38-3+deb10u4
> Severity: normal
> Tags: patch
> 
> Hi
> 
> The current version has a race condition in mod_unique_id causing non-unique 
> IDs to be
> generated (multiple threads are using a counter without any mutex).
> 
> I've encountered the issue in a production situation myself.
> 
> There issue has been fixed upstream.
> 
> https://svn.apache.org/viewvc?view=revision=1887244
> https://svn.apache.org/viewvc?view=revision=1887245
> 
> I've tried to compile the patch on top of the current stable version 2.0.38 
> which seems
> to work. Upstream, the patch is only available from 2.0.47 and it's currently 
> in experimental.
> 
> Maybe it can be applied to 2.0.38 aswell.
> 
> Best regards
> Atle Solbakken

Hi,

Debian Buster is "stable", it means that to avoid regression, only
critical patches are applies (security or grave bug).
So this patch won't probably be accepted by Debian release team.

This bug will be fixed in Debian unstable with Apache 2.0.48 and be part of:
 * next Debian 12 (~2023)
 * Debian backports for Bullseye
 * maybe Debian backports for Buster (buster-backports-sloppy)

Cheers,
Yadd

Bug#980137: apache2: multi-instance support, APACHE_CONFDIR and ServerRoot

[Yadd]

Le 12/04/2021 à 21:43, Christoph Anton Mitterer a écrit :
> Guess the better place to set it would be:
> /lib/systemd/system/apache2.service
> 
> (just like it's already done in /lib/systemd/system/apache2@.service
> for the instance versions)
> 
> 
> 
> This would also have the benefit that people could use APACHE_CONFDIR
> in their configs if they want to make paths relative to it, where the
> directive doens't use non-absolute paths per default relative to
> ServerRoot.

Hi,

could you propose a patch?

Cheers,
Yadd