Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption
Hi,
On Fri, Dec 30, 2022 at 05:25:41PM +0100, Tobias Frost wrote:
> On Fri, Dec 30, 2022 at 04:14:25PM +0100, Salvatore Bonaccorso wrote:
> > Hi Steinar, hi Tobias,
> >
> > On Fri, Dec 30, 2022 at 12:04:29PM +0100, Tobias Frost wrote:
> > > On Fri, Dec 30, 2022 at 11:18:14AM +0100, Steinar H. Gunderson wrote:
> > > > On Fri, Dec 30, 2022 at 11:04:46AM +0100, Tobias Frost wrote:
> > > > > I was trying to triage this CVE and *maybe* those revisions are
> > > > > related:
> > > > >
> > > > > r1894937 ("apreq_parse_headers: Discard CRLF of folded values.")
> > > > > r1894940 ("reindent (no functional change).")
> > > > > r1894977 ("Follow up to r1894937: Fix setting of empty value.")
> > > > > r1895054 ("Follow up to r1894937: Always eat CRLF at the end of
> > > > > header value.")
> > > >
> > > > Perhaps it's best to remove libapreq2 entirely? I don't use nor
> > > > maintain it
> > > > anymore, it's been out of testing for a while, and there's this CVE.
> > >
> > > #ssh mirror.ftp-master.debian.org "dak rm -Rn libapreq2"
> > >
> > > Will remove the following packages from unstable:
> > >
> > > libapache2-mod-apreq2 | 2.13-7+b4 | amd64, arm64, armel, armhf, i386,
> > > mips64el, mipsel, ppc64el, s390x
> > > libapache2-request-perl | 2.13-7+b4 | amd64, arm64, armel, armhf,
> > > i386, mips64el, mipsel, ppc64el, s390x
> > >libapreq2 | 2.13-7 | source
> > > libapreq2-3 | 2.13-7+b4 | amd64, arm64, armel, armhf, i386, mips64el,
> > > mipsel, ppc64el, s390x
> > > libapreq2-dev | 2.13-7+b4 | amd64, arm64, armel, armhf, i386,
> > > mips64el, mipsel, ppc64el, s390x
> > > libapreq2-doc | 2.13-7 | all
> > >
> > > Maintainer: Steinar H. Gunderson
> > >
> > > --- Reason ---
> > >
> > > --
> > >
> > > Checking reverse dependencies...
> > > # Broken Depends:
> > > libapache2-authcassimple-perl: libapache2-authcassimple-perl
> > > libapache2-sitecontrol-perl: libapache2-sitecontrol-perl
> > > lua-apr: lua-apr
> > > rapache: libapache2-mod-r-base
> > >
> > > # Broken Build-Depends:
> > > libapache2-sitecontrol-perl: libapache2-request-perl
> > > lua-apr: libapreq2-dev
> > > rapache: libapreq2-dev
> > >
> > > Dependency problem found.
> > >
> > > ... and still theres a need to fix the CVE for stable (and also for
> > > (E)LTS)
> > >
> > > (I'm currently take a look at 2.17, to see if I can get it packages, if
> > > I'm succeeding,
> > > there will be an NMU announcement :))
> >
> > Upstream has still not clarified on
> > https://www.openwall.com/lists/oss-security/2022/08/26/4 and given it
> > was now out of bookworm, it might be wise that we actually sunset it
> > for bookworm (including having the above reverse dependencies out of
> > bookworm).
> >
> > Fixing stable and oldstable is then another story, and I still hope we
> > get feedback from upstream on pinpointing the fixes.
>
> ACK, I will file a "not suitable for bookworm" bug, so that the new package
> and r-depends won't migrate.
Thank you Tobi!
> Lets hope that upstream answers…
Regards,
Salvatore
Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption
On Fri, Dec 30, 2022 at 04:14:25PM +0100, Salvatore Bonaccorso wrote:
> Hi Steinar, hi Tobias,
>
> On Fri, Dec 30, 2022 at 12:04:29PM +0100, Tobias Frost wrote:
> > On Fri, Dec 30, 2022 at 11:18:14AM +0100, Steinar H. Gunderson wrote:
> > > On Fri, Dec 30, 2022 at 11:04:46AM +0100, Tobias Frost wrote:
> > > > I was trying to triage this CVE and *maybe* those revisions are related:
> > > >
> > > > r1894937 ("apreq_parse_headers: Discard CRLF of folded values.")
> > > > r1894940 ("reindent (no functional change).")
> > > > r1894977 ("Follow up to r1894937: Fix setting of empty value.")
> > > > r1895054 ("Follow up to r1894937: Always eat CRLF at the end of header
> > > > value.")
> > >
> > > Perhaps it's best to remove libapreq2 entirely? I don't use nor maintain
> > > it
> > > anymore, it's been out of testing for a while, and there's this CVE.
> >
> > #ssh mirror.ftp-master.debian.org "dak rm -Rn libapreq2"
> >
> > Will remove the following packages from unstable:
> >
> > libapache2-mod-apreq2 | 2.13-7+b4 | amd64, arm64, armel, armhf, i386,
> > mips64el, mipsel, ppc64el, s390x
> > libapache2-request-perl | 2.13-7+b4 | amd64, arm64, armel, armhf,
> > i386, mips64el, mipsel, ppc64el, s390x
> > libapreq2 | 2.13-7 | source
> > libapreq2-3 | 2.13-7+b4 | amd64, arm64, armel, armhf, i386, mips64el,
> > mipsel, ppc64el, s390x
> > libapreq2-dev | 2.13-7+b4 | amd64, arm64, armel, armhf, i386,
> > mips64el, mipsel, ppc64el, s390x
> > libapreq2-doc | 2.13-7 | all
> >
> > Maintainer: Steinar H. Gunderson
> >
> > --- Reason ---
> >
> > --
> >
> > Checking reverse dependencies...
> > # Broken Depends:
> > libapache2-authcassimple-perl: libapache2-authcassimple-perl
> > libapache2-sitecontrol-perl: libapache2-sitecontrol-perl
> > lua-apr: lua-apr
> > rapache: libapache2-mod-r-base
> >
> > # Broken Build-Depends:
> > libapache2-sitecontrol-perl: libapache2-request-perl
> > lua-apr: libapreq2-dev
> > rapache: libapreq2-dev
> >
> > Dependency problem found.
> >
> > ... and still theres a need to fix the CVE for stable (and also for (E)LTS)
> >
> > (I'm currently take a look at 2.17, to see if I can get it packages, if I'm
> > succeeding,
> > there will be an NMU announcement :))
>
> Upstream has still not clarified on
> https://www.openwall.com/lists/oss-security/2022/08/26/4 and given it
> was now out of bookworm, it might be wise that we actually sunset it
> for bookworm (including having the above reverse dependencies out of
> bookworm).
>
> Fixing stable and oldstable is then another story, and I still hope we
> get feedback from upstream on pinpointing the fixes.
ACK, I will file a "not suitable for bookworm" bug, so that the new package and
r-depends won't migrate.
Lets hope that upstream answers…
--
tobi
> Regards,
> Salvatore
Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption
Hi Steinar, hi Tobias,
On Fri, Dec 30, 2022 at 12:04:29PM +0100, Tobias Frost wrote:
> On Fri, Dec 30, 2022 at 11:18:14AM +0100, Steinar H. Gunderson wrote:
> > On Fri, Dec 30, 2022 at 11:04:46AM +0100, Tobias Frost wrote:
> > > I was trying to triage this CVE and *maybe* those revisions are related:
> > >
> > > r1894937 ("apreq_parse_headers: Discard CRLF of folded values.")
> > > r1894940 ("reindent (no functional change).")
> > > r1894977 ("Follow up to r1894937: Fix setting of empty value.")
> > > r1895054 ("Follow up to r1894937: Always eat CRLF at the end of header
> > > value.")
> >
> > Perhaps it's best to remove libapreq2 entirely? I don't use nor maintain it
> > anymore, it's been out of testing for a while, and there's this CVE.
>
> #ssh mirror.ftp-master.debian.org "dak rm -Rn libapreq2"
>
> Will remove the following packages from unstable:
>
> libapache2-mod-apreq2 | 2.13-7+b4 | amd64, arm64, armel, armhf, i386,
> mips64el, mipsel, ppc64el, s390x
> libapache2-request-perl | 2.13-7+b4 | amd64, arm64, armel, armhf,
> i386, mips64el, mipsel, ppc64el, s390x
>libapreq2 | 2.13-7 | source
> libapreq2-3 | 2.13-7+b4 | amd64, arm64, armel, armhf, i386, mips64el,
> mipsel, ppc64el, s390x
> libapreq2-dev | 2.13-7+b4 | amd64, arm64, armel, armhf, i386,
> mips64el, mipsel, ppc64el, s390x
> libapreq2-doc | 2.13-7 | all
>
> Maintainer: Steinar H. Gunderson
>
> --- Reason ---
>
> --
>
> Checking reverse dependencies...
> # Broken Depends:
> libapache2-authcassimple-perl: libapache2-authcassimple-perl
> libapache2-sitecontrol-perl: libapache2-sitecontrol-perl
> lua-apr: lua-apr
> rapache: libapache2-mod-r-base
>
> # Broken Build-Depends:
> libapache2-sitecontrol-perl: libapache2-request-perl
> lua-apr: libapreq2-dev
> rapache: libapreq2-dev
>
> Dependency problem found.
>
> ... and still theres a need to fix the CVE for stable (and also for (E)LTS)
>
> (I'm currently take a look at 2.17, to see if I can get it packages, if I'm
> succeeding,
> there will be an NMU announcement :))
Upstream has still not clarified on
https://www.openwall.com/lists/oss-security/2022/08/26/4 and given it
was now out of bookworm, it might be wise that we actually sunset it
for bookworm (including having the above reverse dependencies out of
bookworm).
Fixing stable and oldstable is then another story, and I still hope we
get feedback from upstream on pinpointing the fixes.
Regards,
Salvatore
Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption
On Fri, Dec 30, 2022 at 12:28:49PM +0100, Steinar H. Gunderson wrote: > On Fri, Dec 30, 2022 at 12:04:29PM +0100, Tobias Frost wrote: > > (I'm currently take a look at 2.17, to see if I can get it packages, if I'm > > succeeding, > > there will be an NMU announcement :)) > > If you are NMUing, could you orphan the package in the upload? Yes, will do that. > /* Steinar */ > -- > Homepage: https://www.sesse.net/
Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption
On Fri, Dec 30, 2022 at 12:04:29PM +0100, Tobias Frost wrote: > (I'm currently take a look at 2.17, to see if I can get it packages, if I'm > succeeding, > there will be an NMU announcement :)) If you are NMUing, could you orphan the package in the upload? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption
On Fri, Dec 30, 2022 at 11:18:14AM +0100, Steinar H. Gunderson wrote:
> On Fri, Dec 30, 2022 at 11:04:46AM +0100, Tobias Frost wrote:
> > I was trying to triage this CVE and *maybe* those revisions are related:
> >
> > r1894937 ("apreq_parse_headers: Discard CRLF of folded values.")
> > r1894940 ("reindent (no functional change).")
> > r1894977 ("Follow up to r1894937: Fix setting of empty value.")
> > r1895054 ("Follow up to r1894937: Always eat CRLF at the end of header
> > value.")
>
> Perhaps it's best to remove libapreq2 entirely? I don't use nor maintain it
> anymore, it's been out of testing for a while, and there's this CVE.
#ssh mirror.ftp-master.debian.org "dak rm -Rn libapreq2"
Will remove the following packages from unstable:
libapache2-mod-apreq2 | 2.13-7+b4 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
libapache2-request-perl | 2.13-7+b4 | amd64, arm64, armel, armhf,
i386, mips64el, mipsel, ppc64el, s390x
libapreq2 | 2.13-7 | source
libapreq2-3 | 2.13-7+b4 | amd64, arm64, armel, armhf, i386, mips64el,
mipsel, ppc64el, s390x
libapreq2-dev | 2.13-7+b4 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
libapreq2-doc | 2.13-7 | all
Maintainer: Steinar H. Gunderson
--- Reason ---
--
Checking reverse dependencies...
# Broken Depends:
libapache2-authcassimple-perl: libapache2-authcassimple-perl
libapache2-sitecontrol-perl: libapache2-sitecontrol-perl
lua-apr: lua-apr
rapache: libapache2-mod-r-base
# Broken Build-Depends:
libapache2-sitecontrol-perl: libapache2-request-perl
lua-apr: libapreq2-dev
rapache: libapreq2-dev
Dependency problem found.
... and still theres a need to fix the CVE for stable (and also for (E)LTS)
(I'm currently take a look at 2.17, to see if I can get it packages, if I'm
succeeding,
there will be an NMU announcement :))
> /* Steinar */
> --
> Homepage: https://www.sesse.net/
signature.asc
Description: PGP signature
Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption
On Fri, Dec 30, 2022 at 11:04:46AM +0100, Tobias Frost wrote:
> I was trying to triage this CVE and *maybe* those revisions are related:
>
> r1894937 ("apreq_parse_headers: Discard CRLF of folded values.")
> r1894940 ("reindent (no functional change).")
> r1894977 ("Follow up to r1894937: Fix setting of empty value.")
> r1895054 ("Follow up to r1894937: Always eat CRLF at the end of header
> value.")
Perhaps it's best to remove libapreq2 entirely? I don't use nor maintain it
anymore, it's been out of testing for a while, and there's this CVE.
/* Steinar */
--
Homepage: https://www.sesse.net/
Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption
I was trying to triage this CVE and *maybe* those revisions are related:
r1894937 ("apreq_parse_headers: Discard CRLF of folded values.")
r1894940 ("reindent (no functional change).")
r1894977 ("Follow up to r1894937: Fix setting of empty value.")
r1895054 ("Follow up to r1894937: Always eat CRLF at the end of header value.")
diff:
http://svn.apache.org/viewvc/httpd/apreq/trunk/library/parser_header.c?r1=1894937=1895054=1895054_format=h
Those SVN commits have been introduced at the beginning of the 2.17 release
cycle, so
would match the description "up to 2.16"…
Said that, there are not many changes between 2.13 and 2.17…
IMHHO using 2.17 might be an option to evaluate. However, someone with more
perland apache2 modules knowledge should
double check:
- Apache2 Module Magic Number for the apache2 module has been bumped, which
according to the comment:
> The Apache2 Module Magic Number for use in the Apache 2.x module structures
> This gets bumped if changes in th4e API will break third party applications
> using this apache2 module
Looking at the changes for the module, with 2.13 released on r1041502,
the changes up to the MMM update are only those as in attached
r1041792-1042894.diff
(between r1041502 and r1041792 there are only changes in regards to the new dev
cycle, i.e s/2.13/2.14)
Not sure how that would break API… I do not see any other changes to the
apache2 until recently, which is still unreleased, past 2.17)
- ./glue/perl/xsbuilder/tables/APR/Request/CallbackTable.pm is almost empty
>>2.13 … No idea what that means…
(attached the diff between 2.13 and 2.15. It's the same, except date, for 2.17)
--
tobi (in the hope the analysis helps…)
Index: module/apache2/apreq_module_apache2.h
===
--- module/apache2/apreq_module_apache2.h (revision 1041792)
+++ module/apache2/apreq_module_apache2.h (revision 1042894)
@@ -171,7 +171,7 @@
* using this apache2 module
* @see APREQ_MODULE
*/
-#define APREQ_APACHE2_MMN 20090110
+#define APREQ_APACHE2_MMN 20101207
/** @} */
Index: module/apache2/handle.c
===
--- module/apache2/handle.c (revision 1041792)
+++ module/apache2/handle.c (revision 1042894)
@@ -15,8 +15,6 @@
** limitations under the License.
*/
-#include "assert.h"
-
#include "httpd.h"
#include "http_config.h"
#include "http_log.h"
Index: module/apache2/filter.c
===
--- module/apache2/filter.c (revision 1041792)
+++ module/apache2/filter.c (revision 1042894)
@@ -15,8 +15,6 @@
** limitations under the License.
*/
-#include "assert.h"
-
#include "httpd.h"
#include "http_config.h"
#include "http_log.h"
@@ -37,8 +35,8 @@
/* d == OR_ALL */
struct dir_config *dc = apr_palloc(p, sizeof *dc);
dc->temp_dir = NULL;
-dc->read_limit= APREQ_DEFAULT_READ_LIMIT;
-dc->brigade_limit = APREQ_DEFAULT_BRIGADE_LIMIT;
+dc->read_limit= -1;
+dc->brigade_limit = -1;
return dc;
}
@@ -52,7 +50,7 @@
c->brigade_limit = (b->brigade_limit == (apr_size_t)-1) /* overrides ok */
? a->brigade_limit : b->brigade_limit;
-c->read_limit= (b->read_limit < a->read_limit) /* why min? */
+c->read_limit= (b->read_limit < a->read_limit) /* yes, min */
? b->read_limit : a->read_limit;
return c;
@@ -532,10 +530,11 @@
ctx->brigade_limit = APREQ_DEFAULT_BRIGADE_LIMIT;
} else {
ctx->temp_dir = d->temp_dir;
-ctx->read_limit= d->read_limit;
-ctx->brigade_limit = d->brigade_limit;
+ctx->read_limit= (d->read_limit == (apr_uint64_t)-1)
+? APREQ_DEFAULT_READ_LIMIT : d->read_limit;
+ctx->brigade_limit = (d->brigade_limit == (apr_size_t)-1)
+? APREQ_DEFAULT_BRIGADE_LIMIT : d->brigade_limit;
}
f->ctx = ctx;
}
-
Index: CHANGES
===
--- CHANGES (revision 1041792)
+++ CHANGES (revision 1042894)
@@ -3,6 +3,9 @@
@section v2_14 Changes with libapreq2-2.14 (in development)
+- C API [joes]
+ Fix mod_apreq2's config merging.
+
@section v2_13 Changes with libapreq2-2.13 (released December 3, 2010)
- HTTP Only Cookie [Robert Stone & Adam Prime]
--- libapreq2-2.13/glue/perl/xsbuilder/tables/APR/Request/CallbackTable.pm 2010-11-25 20:19:33.0 +0100
+++ libapreq2-2.15/glue/perl/xsbuilder/tables/APR/Request/CallbackTable.pm 2020-11-05 17:21:01.0 +0100
@@ -2,222 +2,11 @@
# !!
# ! WARNING: generated by My::ParseSource/
-# ! Thu Nov 25 21:19:33 2010
+# ! Thu Nov 5 16:21:01 2020
# ! do NOT edit, any changes will be lost !
# !!
-$APR::Request::CallbackTable = [
- {
-'return_type' => 'apr_status_t',
Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption
Hi, On Sat, Sep 03, 2022 at 03:31:15PM +0200, Steinar H. Gunderson wrote: > On Fri, Aug 26, 2022 at 09:07:06PM +0200, Salvatore Bonaccorso wrote: > > The following vulnerability was published for libapreq2. > > > > CVE-2022-22728[0]: > > | A flaw in Apache libapreq2 versions 2.16 and earlier could cause a > > | buffer overflow while processing multipart form uploads. A remote > > | attacker could send a request causing a process crash which could lead > > | to a denial of service attack. > > Based on the description, I assume it is this one: > > http://svn.apache.org/viewvc?view=revision=1866760 > > I'm not sure if it counts as “buffer overflow”, but given that it only > mentions DoS and not arbitrary code execution, NULL pointer dereference > looks a lot like it. 2.13 appears vulnerable to me, given the description. > > I don't use libapreq2 anymore, so anyone wanting to pick up the package > would be more than welcome. Upstream homepage is now seemingly at: > > https://httpd.apache.org/apreq/ Thanks for having investigated this further. This is puzzling and upstream has not yet answered on queries about isolating the fix. The above would be already a couple of years old. And https://bugs.gentoo.org/show_bug.cgi?id=CVE-2022-22728#c1 seems to indicate there must be something in recent days about it. A diff between libapreq2-2.16 and libapreq2-2.17 has in fact: diff -urN libapreq2-2.16/CHANGES libapreq2-2.17/CHANGES --- libapreq2-2.16/CHANGES 2021-03-10 14:46:30.0 +0100 +++ libapreq2-2.17/CHANGES 2022-08-18 11:19:04.0 +0200 @@ -1,6 +1,11 @@ /** @page apreq_changes CHANGES //! brief List of major changes. +@section v2_17 Changes with libapreq2-2.17 (released 25 August, 2022) + +- Multipart header parser [Yann Ylavic] + Rework apreq_parse_headers() to discard CRLF of folded values. + @section v2_16 Changes with libapreq2-2.16 (released 17 March, 2021) But maybe as you suggest we have to go back . Though it should be something which still affects 2.16 upstream. and likely so not the newley released 2.17. Regards, Salvatore
Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption
On Fri, Aug 26, 2022 at 09:07:06PM +0200, Salvatore Bonaccorso wrote: > The following vulnerability was published for libapreq2. > > CVE-2022-22728[0]: > | A flaw in Apache libapreq2 versions 2.16 and earlier could cause a > | buffer overflow while processing multipart form uploads. A remote > | attacker could send a request causing a process crash which could lead > | to a denial of service attack. Based on the description, I assume it is this one: http://svn.apache.org/viewvc?view=revision=1866760 I'm not sure if it counts as “buffer overflow”, but given that it only mentions DoS and not arbitrary code execution, NULL pointer dereference looks a lot like it. 2.13 appears vulnerable to me, given the description. I don't use libapreq2 anymore, so anyone wanting to pick up the package would be more than welcome. Upstream homepage is now seemingly at: https://httpd.apache.org/apreq/ /* Steinar */ -- Homepage: https://www.sesse.net/
