Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302
Hey. I've just installed this again on some node, and for some reason apt- listbugs still shows it as open: # aptitude Performing actions... Retrieving bug reports... Done Parsing Found/Fixed information... Done grave bugs of liblog4j1.2-java (→ 1.2.17-10+deb11u1) b1 - #1004482 - liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302 (Fixed: apache-log4j1.2/1.2.17-11) Summary: liblog4j1.2-java(1 bug) Are you sure you want to install/upgrade the above packages? [Y/n/?/...] But that's the one now installed: liblog4j1.2-java 1.2.17-10+deb11u1 which, AFAIU should contain the fixes, right? Does it need a: Control: fixed -1 1.2.17-10+deb11u1 ? Cheers, Chris.
Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302
Hi, Am Donnerstag, dem 10.02.2022 um 17:22 +0100 schrieb Christoph Anton Mitterer: > Hey. > > Is that going to be fixed in stable, too? > > Cheers, > Chris. Yes, these issues will be fixed with a stable point update. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302
Hey. Is that going to be fixed in stable, too? Cheers, Chris.
Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302
Am Sonntag, dem 30.01.2022 um 16:49 -0800 schrieb tony mancill: > On Mon, Jan 31, 2022 at 01:18:49AM +0100, Emmanuel Bourg wrote: > > Le 31/01/2022 à 00:47, Markus Koschany a écrit : > > > > > Thanks tony! I'm currently rebuilding all reverse-dependencies of > > > log4j1.2. So > > > far it looks like I was right and there is no package that actually > > > requires > > > one of the affected classes to build. None of the affected features are > > > enabled > > > by default hence why I would rather prefer the sledgehammer approach and > > > just > > > remove them. What doesn't exist can't be exploited. At least this makes > > > sense > > > for stable and oldstable distributions right now. > > > > +1 > > Yes, I didn't mean to imply anything otherwise for stable and oldstable. Ok, I will remove the affected classes in Stretch and prepare a point update for Buster and Bullseye which will achieve the same. > > > > I suggest to file bugs against all those packages with severity normal > > > and ask > > > to migrate to log4j2. If we don't make a lot of progress within the next > > > six > > > months then we could consider packaging reload4j, although I would rather > > > avoid > > > to package (and maintain) a fork of an obsolete project. > > > > We may also pick the reload4j changes and apply them on top of log4j1.2, > > that should induce less work (no extra package, no dependency change, no > > migration to a new API). > > Right. My point in writing was to point out that reload4j is a direct > fork of log4j1.2. Porting to log4j2 could be quite a bit of > (unnecessary) work. For unstable and testing I have applied the changes from the reload4j project on top of our sources now. I agree that porting every dependency to log4j2 on our own is too much work but I presume there are some projects that already did the switch a while ago and their package was simply not updated in Debian. In any case as long as reload4j continues to provide security fixes log4j1.2 should be maintainable. signature.asc Description: This is a digitally signed message part
Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302
On Mon, Jan 31, 2022 at 01:18:49AM +0100, Emmanuel Bourg wrote: > Le 31/01/2022 à 00:47, Markus Koschany a écrit : > > > Thanks tony! I'm currently rebuilding all reverse-dependencies of log4j1.2. > > So > > far it looks like I was right and there is no package that actually requires > > one of the affected classes to build. None of the affected features are > > enabled > > by default hence why I would rather prefer the sledgehammer approach and > > just > > remove them. What doesn't exist can't be exploited. At least this makes > > sense > > for stable and oldstable distributions right now. > > +1 Yes, I didn't mean to imply anything otherwise for stable and oldstable. > > I suggest to file bugs against all those packages with severity normal and > > ask > > to migrate to log4j2. If we don't make a lot of progress within the next six > > months then we could consider packaging reload4j, although I would rather > > avoid > > to package (and maintain) a fork of an obsolete project. > > We may also pick the reload4j changes and apply them on top of log4j1.2, > that should induce less work (no extra package, no dependency change, no > migration to a new API). Right. My point in writing was to point out that reload4j is a direct fork of log4j1.2. Porting to log4j2 could be quite a bit of (unnecessary) work. signature.asc Description: PGP signature
Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302
Le 31/01/2022 à 00:47, Markus Koschany a écrit : Thanks tony! I'm currently rebuilding all reverse-dependencies of log4j1.2. So far it looks like I was right and there is no package that actually requires one of the affected classes to build. None of the affected features are enabled by default hence why I would rather prefer the sledgehammer approach and just remove them. What doesn't exist can't be exploited. At least this makes sense for stable and oldstable distributions right now. +1 I suggest to file bugs against all those packages with severity normal and ask to migrate to log4j2. If we don't make a lot of progress within the next six months then we could consider packaging reload4j, although I would rather avoid to package (and maintain) a fork of an obsolete project. We may also pick the reload4j changes and apply them on top of log4j1.2, that should induce less work (no extra package, no dependency change, no migration to a new API). Emmanuel Bourg
Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302
Am Sonntag, dem 30.01.2022 um 15:20 -0800 schrieb tony mancill:
>
> Hi Markus,
>
> You might take some inspiration and/or patches from the reload4j
> project.
>
> https://reload4j.qos.ch/
>
> I have been using it as drop-in replacement for the log4j 1.2.x jar for
> applications at ${dayjob} without any problem. Once you decide how you
> would like to address the CVE, we can discuss the possibility of
> packaging reload4j for bookworm as a replacement for apache-log4j1.2.
Thanks tony! I'm currently rebuilding all reverse-dependencies of log4j1.2. So
far it looks like I was right and there is no package that actually requires
one of the affected classes to build. None of the affected features are enabled
by default hence why I would rather prefer the sledgehammer approach and just
remove them. What doesn't exist can't be exploited. At least this makes sense
for stable and oldstable distributions right now.
I don't know much about the reload4j fork at the moment. From an application
manager perspective it could make sense to replace log4j1.2 with reload4j but
Debian should better move forward to log4j2 in my opinion. Ideally we could
just replace log4j1.2 with log4j2 in all reverse dependencies. Some upstream
projects should be really shaken up by now because of log4shell and eventually
move away from log4j1.2. We still have a lot of Debian packages which depend on
it though.
I suggest to file bugs against all those packages with severity normal and ask
to migrate to log4j2. If we don't make a lot of progress within the next six
months then we could consider packaging reload4j, although I would rather avoid
to package (and maintain) a fork of an obsolete project.
Cheers,
Markus
signature.asc
Description: This is a digitally signed message part
Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302
On Sun, Jan 30, 2022 at 10:12:53PM +0100, Markus Koschany wrote:
> On Fri, 28 Jan 2022 17:04:08 +0100 Christoph Anton Mitterer
> wrote:
> > Package: liblog4j1.2-java
> > Version: 1.2.17-10
> >
> > A number of holes was found in the 1.2 branch of log4j.
> >
> > The following is apparently critical (code injection):
> > https://www.cvedetails.com/cve/CVE-2022-23307/
> >
> > https://www.cvedetails.com/cve/CVE-2022-23305/
> > https://www.cvedetails.com/cve/CVE-2022-23302/
>
>
> I intend to address these issues shortly. I believe we can just remove the
> affected classes because they are not used by our dependencies but I need to
> double-check that.
Hi Markus,
You might take some inspiration and/or patches from the reload4j
project.
https://reload4j.qos.ch/
I have been using it as drop-in replacement for the log4j 1.2.x jar for
applications at ${dayjob} without any problem. Once you decide how you
would like to address the CVE, we can discuss the possibility of
packaging reload4j for bookworm as a replacement for apache-log4j1.2.
Cheers,
tony
signature.asc
Description: PGP signature
Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302
Control: owner -1 ! On Fri, 28 Jan 2022 17:04:08 +0100 Christoph Anton Mitterer wrote: > Package: liblog4j1.2-java > Version: 1.2.17-10 > Severity: grave > Tags: security upstream > Justification: user security hole > X-Debbugs-Cc: Debian Security Team > > Hey. > > A number of holes was found in the 1.2 branch of log4j. > > The following is apparently critical (code injection): > https://www.cvedetails.com/cve/CVE-2022-23307/ > > https://www.cvedetails.com/cve/CVE-2022-23305/ > https://www.cvedetails.com/cve/CVE-2022-23302/ I intend to address these issues shortly. I believe we can just remove the affected classes because they are not used by our dependencies but I need to double-check that. Markus signature.asc Description: This is a digitally signed message part
Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302
Package: liblog4j1.2-java Version: 1.2.17-10 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: Debian Security Team Hey. A number of holes was found in the 1.2 branch of log4j. The following is apparently critical (code injection): https://www.cvedetails.com/cve/CVE-2022-23307/ https://www.cvedetails.com/cve/CVE-2022-23305/ https://www.cvedetails.com/cve/CVE-2022-23302/ AFAIU there is no support anymore form these from upstream, and seems: https://lists.apache.org/thread/rg4yyc89vs3dw6kpy3r92xop9loywyhh there are no plans to fix it. EGI recommends: "For services where chainsaw is installed but not used apply the mitigation zip -q -d /usr/share/cassandra/lib/log4j*.jar org/apache/log4j/chainsaw/*" Not sure if that could be done for the Debian package in a new version? Is Debian going to do anything about these? Thanks, Chris. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
