Hi Tony, Glad you want to help. The original Log4J community left, so to get anything done we need some new contributors!
On Thu, Dec 16, 2021 at 9:19 PM Homer, Tony <tony.ho...@intel.com> wrote: > There has been some discussion about releasing a security update for log4j > 1.x (1.2.18, perhaps), both here and on > https://github.com/apache/logging-log4j2/pull/608. > Is there a JIRA open for this work? > I don't think we really need an issue tracker, we can discuss the work here on the mailing list and iterate on pull requests. If we do need an issue tracker I would suggest enabling the github one after making that a writable repo. People have been making pull requests there for years...I guess since the current github mirror repo doesn't clearly say log4j 1.x is end-of-life...might as well go where the users are. (I have no enthusiasm for using venerable bugzilla, I think it's even older than log4j 1.2 ;-) ) > I'd like to provide some input, specifically that any security update > should consider all of the following CVES: > > https://nvd.nist.gov/vuln/detail/CVE-2019-17571 > consider starting with the Debian patch > discussion: > https://lists.debian.org/debian-lts-announce/2020/01/msg00008.html > download: https://packages.debian.org/stretch/liblog4j1.2-java > changelog: > https://metadata.ftp-master.debian.org/changelogs//main/a/apache-log4j1.2/apache-log4j1.2_1.2.17-7+deb9u1_changelog > < > https://metadata.ftp-master.debian.org/changelogs/main/a/apache-log4j1.2/apache-log4j1.2_1.2.17-7+deb9u1_changelog > > > Hmm, that Debian patch is very minimal/conservative. On the branch I'm working on I disabled many socket things much more thoroughly: https://github.com/apache/log4j/pull/16 Also reviewed the other patches they have in debian on liblog4j1.2, I think none are worth upstreaming. > https://nvd.nist.gov/vuln/detail/CVE-2020-9488 > consider removing SMTPAppender (brute force mitigation) > I've been thinking about this one today. The vulnerability description here is kind of limited: "Improper validation of certificate with host mismatch". Put another way: very little attempt is made when using SMTPS to do a good job at SSL. On the other hand there is also no assertion anywhere the approach used is particularly secure. At a guess, when the code was written, it was a reasonable assumption the JDK should do secure-by-default certificate verification/pinning/etc. Actually, you could still argue that :) The CVE has a base score of 3.7 (LOW), unlike other appenders at least it has some support for encryption...through what the JDK builds in for SMTPS. By the way, that's only one of the issues with this SMTPAppender, apparently another one is that it can generate huge amounts of email: https://github.com/apache/log4j/pull/6 but such a PR also shows that the appender has at least some users. There's probably also users who configure it with insecure SMTP, who you could say have reasonable expectations that it's an insecure connection. (Maybe they talk SMTP to localhost?) So I don't know about disabling it completely. I'm more inclined to log a stern warning, like I'm doing for syslog: https://github.com/lsimons/log4j/blob/2021-security-fixes/src/main/java/org/apache/log4j/helpers/SyslogWriter.java#L95 What do you think? Of course the right fix if you want to log to SMTP is to upgrade to 2.x, which has a nice new builder API that allows passing SSL configuration. Backporting that seems like way too much work. > https://nvd.nist.gov/vuln/detail/CVE-2021-4104 > consider removing JMSAppender (brute force mitigation) > Note removing the classes would break API compatibility. Instead I'm opting to remove the functionality while keeping the API signature: https://github.com/lsimons/log4j/blob/2021-security-fixes/src/main/java/org/apache/log4j/net/JMSAppender.java Fixes the security issue while allowing for a drop-in replacement jar. Cheers, Leo
