#21657 closed defect (fixed)
[PATCH] Update log4j to 2.15.0 (CVE-2021-44228)
| Reported by: | taylor.smock | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Plugin | Version: | |
| Keywords: | log4j cve | Cc: |
Description (last modified by )
This fixes CVE-2021-44228 by default.
In addition there are some other enhancements, but it does claim to be binary compatible with previous releases.
log4j is used directly or indirectly by the following plugins:
- areaselector
- routing
- ImportImagePlugin
- kendzi3d
AFAIK, none of those have remote control capabilities, so the CVE shouldn't affect JOSM.
Attachments (3)
Change History (39)
by , 3 years ago
| Attachment: | 21657.patch added |
|---|
comment:1 by , 3 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 3 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
comment:3 by , 3 years ago
| Resolution: | duplicate |
|---|---|
| Status: | closed → reopened |
follow-up: 11 comment:5 by , 3 years ago
IMHO the pointer to "remote control capabilities, so the CVE shouldn't affect JOSM." is misleading as the the "feature" could just as easily be used via a logged OSM tag or similar input.
comment:6 by , 3 years ago
On Linux, I have the system libraries liblog4j1.2-java and liblog4j2-java installed. Do I still need the plugin?
comment:7 by , 3 years ago
The plugin doesn't try to use native libraries, it uses only the shipped version.
comment:9 by , 3 years ago
| Milestone: | 21.11 |
|---|
comment:11 by , 3 years ago
Replying to SimonPoole:
IMHO the pointer to "remote control capabilities, so the CVE shouldn't affect JOSM." is misleading as the the "feature" could just as easily be used via a logged OSM tag or similar input.
Most of the affected plugins don't do anything with tags, or are broken for most users. routing is _probably_ the only one that (a) isn't broken and (b) does stuff with tags. It does actually log tags (weight/speed). TBH, we probably ought to replace the logging code in it with calls to the JOSM Logging class (source:/trunk/src/org/openstreetmap/josm/tools/Logging.java ) anyway. The plugin probably used log4j since JOSM didn't have the Logging class at the time the plugin was originally written.
Replying to skyper:
On Linux, I have the system libraries liblog4j1.2-java and liblog4j2-java installed. Do I still need the plugin?
Probably. TBH, we should probably check our dependencies for log4j. I'll update #21596 (update dependencies in ivy.xml and tools/ivy.xml) so we do get any fixes our dependencies needed to do. I'll also take a look at apache-commons/apache-http.
follow-up: 15 comment:14 by , 3 years ago
comment:15 by , 3 years ago
follow-ups: 17 19 20 comment:16 by , 3 years ago
If someone can find out why JOSM-Plugins Jenkins tasks still fetches log4j 2.14.1 for areaselector I'd appreciate it.
comment:17 by , 3 years ago
Replying to stoecker:
If someone can find out why JOSM-Plugins Jenkins tasks still fetches log4j 2.14.1 for areaselector I'd appreciate it.
I'll take a look at it. Hopefully areaselector just has a hidden dependency on log4j somewhere. If that is the case, then it should be as easy as excluding it in ivy.
comment:19 by , 3 years ago
Replying to stoecker:
If someone can find out why JOSM-Plugins Jenkins tasks still fetches log4j 2.14.1 for areaselector I'd appreciate it.
I'm not seeing log4j in the project dependencies. It is, however, part of the tool dependencies (resolve-tools), and I'm seeing it there.
<target name="resolve-tools" depends="init-ivy" description="Resolves tools using Apache Ivy"> <ivy:resolve file="${core.tools.ivy}"/> <ivy:cachepath file="${core.tools.ivy}" pathid="errorprone.classpath" conf="errorprone"/> <ivy:cachepath file="${core.tools.ivy}" pathid="errorprone_javac.classpath" conf="errorprone_javac"/> <ivy:cachepath file="${core.tools.ivy}" pathid="checkstyle.classpath" conf="checkstyle"/> <ivy:cachepath file="${core.tools.ivy}" pathid="spotbugs.classpath" conf="spotbugs"/> </target>
I'll update #21596 again.
comment:20 by , 3 years ago
Replying to stoecker:
If someone can find out why JOSM-Plugins Jenkins tasks still fetches log4j 2.14.1 for areaselector I'd appreciate it.
It looks like it is due to spotbugs in source:trunk/tools/ivy.xml. Version 4.5.2 updates log4j.
follow-up: 23 comment:21 by , 3 years ago
Replying to taylor.smock:
In 35879/osm:
Something went wrong with this dist, the MANIFEST says
Plugin-Version: UNKNOWN
comment:22 by , 3 years ago
Also there is still someone pulling 2.14.1:
Seems dist-optimized: jenkins/job/JOSM/jdk=JDK11/7647/consoleFull
I hate this remote dependency stuff. That's awful.
follow-up: 27 comment:23 by , 3 years ago
Replying to GerdP:
Something went wrong with this dist, the MANIFEST says
Plugin-Version: UNKNOWN
I know what happened -- my dev environment is a Frankenstein of docker containers + localhost. I've got to use docker for subversion (if you've got homebrew set to a different home than the default, then subversion refuses to build/install), so getting the svn revision didn't work.
Replying to stoecker:
Also there is still someone pulling 2.14.1:
Seems dist-optimized: jenkins/job/JOSM/jdk=JDK11/7647/consoleFull
I hate this remote dependency stuff. That's awful.
There are pros/cons to everything. The one thing I like is that I know what the dependency actually is (as in, which org/module it is). And the ability to do a generic check for dependency updates (ant ivy-checkdepsupdate) -- #21596 made some modifications so that tools/ivy.xml was included in the update check. But you do have to do a scrollback.
We could set ivy up to exclude log4j, and provide our own. I've done exclusions in ivy with a few patches I've been working on.
Anyway, it looks like the problematic dependency is proguard-ant in tools/ivy.xml. We just have to update it to 7.2.0-beta4.
comment:27 by , 3 years ago
I hate this remote dependency stuff. That's awful.
There are pros/cons to everything.
Yes, I know these. I'm doing software development for more that 30 years now, more than 20 years as professional. I'm intimate with all the pros and cons available. :-)
The one thing I like is that I know what the dependency actually is (as in, which org/module it is). And the ability to do a generic check for dependency updates (
ant ivy-checkdepsupdate) -- #21596 made some modifications so thattools/ivy.xmlwas included in the update check. But you do have to do a scrollback.
The problem with these ivy, maven,... tools is, that you totally lose the control over the source and contrary to the belief it does not increase security compared to simply copying the code into your project. Rather the opposite as the last years have shown.
We could set ivy up to exclude log4j, and provide our own. I've done exclusions in ivy with a few patches I've been working on.
No. That makes no sense. I allowed the way to go with dynamic dependencies and now we have to live with this decision. A mix of dynamic and local static or specific exceptions is even worse.
Anyway, it looks like the problematic dependency is
proguard-antintools/ivy.xml. We just have to update it to 7.2.0-beta4.
Hope that's the last place. Will see if the ant/ivy/nexus caches keep clean.
P.S. As openSUSE package manager you learn to hate these projects which don't even have a way to build offline, but rather expect that a network connection is always available, which for package build servers it is not - a package must always be build with only the supplied files.
follow-up: 29 comment:28 by , 3 years ago
Well, there will remain one old log4j in Plugins build 2033, as this is kept until the Mapillary tests are fixed...
follow-up: 30 comment:29 by , 3 years ago
Replying to stoecker:
Well, there will remain one old log4j in Plugins build 2033, as this is kept until the Mapillary tests are fixed...
Sorry about the Mapillary tests -- I have yet to figure out why they pass in some environments, and fail in others. I thought I had something reproducible at one point, but I haven't been able to repro recently.
I've got a docker container that should be fairly similar to the Jenkins environment, but the tests were passing. I just added svn/git to the image, and maybe I'll be able to repro with that.
comment:30 by , 3 years ago
Replying to taylor.smock:
Replying to stoecker:
Well, there will remain one old log4j in Plugins build 2033, as this is kept until the Mapillary tests are fixed...
Sorry about the Mapillary tests -- I have yet to figure out why they pass in some environments, and fail in others. I thought I had something reproducible at one point, but I haven't been able to repro recently.
I've got a docker container that should be fairly similar to the Jenkins environment, but the tests were passing. I just added
svn/gitto the image, and maybe I'll be able to repro with that.
Is there anything that could help you?
comment:31 by , 3 years ago
About the only thing I can think of would be a list of software that was installed. (apt list --installed should do it).
Hopefully I don't need the exact same configuration settings. If I do need the same configuration settings, I'll just have to add extra print statements to see what happens, and debug day-by-day.
comment:32 by , 3 years ago
Would it help when we setup a JOB which only builds and checks mapillary? That way you could use our instance for testing (and fast feedback). Probably much easier than trying to recreate our setup (which I'm not entirely sure I could do myself without the backups).
by , 3 years ago
| Attachment: | 21657.2.17.1.patch added |
|---|
Update Log4J to 2.17.1. This fixes CVE-2021-44832.
Bump log4j version