Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Utilities: Replace log4j-1.2.17 by logback-classic-1.2.9 #1050

Closed
richterjens opened this issue Oct 16, 2021 · 14 comments
Closed

Utilities: Replace log4j-1.2.17 by logback-classic-1.2.9 #1050

richterjens opened this issue Oct 16, 2021 · 14 comments
Assignees
Milestone

Comments

@richterjens
Copy link

The version of log4j that is used is labeled as end of life.
It is also flagged during our vulnerability scans.

Suggest to update to the latest release of log4j v2.14.1

@muralibarla
Copy link

log4j:log4j:1.2.17 flagged during our vulnerability scan and this version is labeled as end of life.

Please update to org.apache.logging.log4j:log4j:2.14.1

@denicaM
Copy link

denicaM commented Dec 8, 2021

Same problem, It would be great if log4j is updated.

@chming1016
Copy link

As CVE-2021-44228 has Critical security issue and affects log4j >= 2.0.0, < 2.15.0, it is better to use 2.15.0 instead of 2.14.1.

@zooozoo
Copy link

zooozoo commented Dec 13, 2021

Any plan for this update...?

@chming1016
Copy link

Hi

It seems like log4j 1.x is vulnerable to CVE-2021-44228.

Update (2021-12-12 10:09 JST): according to this analysis by @TopStreamsNet, strictly speaking, applications using Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower.

For detailed context, see apache/logging-log4j2#608 (comment)

Is dcm4che exploitable? or just vulnerable only? Thanks.

@jssuttles
Copy link

Sorry about this @gunterze, I know you're probably very busy, but will this be addressed soon?

@nroduit
Copy link
Member

nroduit commented Dec 20, 2021

The dcm4che toolkit uses the sl4j facade and log4j 1.2.17 by default.

log4j 1.x is not affected by CVE-2021-44228, see the analysis of the designer of log4j and sl4j. Note that the default logger configuration in dcm4che does not contain JMSAppender, so is not affected by the vulnerability CVE-2021-4104.

If you integrate dcm4che in third-party software then you have to check what is the logger (as it can be modified) and its configuration.

@gunterze
Copy link
Member

gunterze commented Dec 20, 2021

Particularly, the library does not use any default, only the launcher scripts for the utilities currently includes log4j-1.2.17.jar with slf4j-log4j12-1.7.30.jar into the CLASSPATH. I will take a look to switch using logback-classic by provided launchers.

@nroduit
Copy link
Member

nroduit commented Dec 20, 2021

Yes it seems the best option to move to logback 1.2.9

@gunterze gunterze self-assigned this Dec 20, 2021
@gunterze gunterze added this to the 5.26.0 milestone Dec 20, 2021
@gunterze gunterze changed the title log4j update Utilities: Replace log4j-1.2.17 by logback-classic-1.2.9 Dec 20, 2021
@sblour
Copy link

sblour commented Jan 3, 2022

I am using dcm4che-net-2.0.29.jar that uses log4j. What is the replacement? I tried the newer versions of dcm4che-net, but it seems still uses log4j.
How to do this?

@gunterze
Copy link
Member

gunterze commented Jan 5, 2022

I do not longer maintain dcm4che-2.x.
dcm4che-2.x - as dcm4che-3/5.x - depends on SLF4J, and not on log4j. So you may switch to using logback-classic without changing any source code as done here for dcm4che-3/5.x.

@sblour
Copy link

sblour commented Jan 6, 2022

We have switched to logback-classic, but in runtime the application fails on dcm4che.data that requires log4j.
Where I can retrieve jar files for dcm4che utility?

@sblour
Copy link

sblour commented Jan 24, 2022

Can someone tells me the pom or maven link to download dcm4che 5 and dependency libraries? I am using gradle, it doesn't find the place to download

@sblour
Copy link

sblour commented Feb 4, 2022

I am stuck here, does anyone have a solution?
Using dropwizard 2.0.28
Exception in thread "main" java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgument(ZLjava/lang/String;Ljava/lang/Object;)V

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants