I use spring-boot-starter-activemq with the lastest version of springboot (2.7.1). Our company's dependency tracker marks activemq-broker which is part of the starter as vulnerable because of CVE-2015-3208 (XML external entity - XXE). We use ActiveMQ instead of Artemis for integration with some legacy system. Is there a way to fix it or is this just a false positive ? I see that that there are updates in maven repository quite frequently (link) hence I can't believe that the vulnerability published in 2017 is not solved yet.
Thank you for your thoughts !
Related
For our spring boot project , We are using customized spring boot library and it has been upgraded now.
But during upgrade we have kept older version of hibernate core 5.3.7.Final to support namedNativeQuery functionality.
And this version internally using older vulnerable version of log4j.
However as part of security , the overall log4j version is upgraded to latest and we can see only log4j-2.17.1 when we run the mvn dendency:list.
Is this sufficient to handle the log4j vulnarability ?
Thanks in advance.
Hibernate is not affected:
Hibernate projects are not affected by the vulnerabilities behind
CVE-2021-45046 and CVE-2021-44228: none of the Hibernate projects has
a runtime dependency on Log4j core.
Source: https://in.relation.to/2021/12/16/log4j-cve/
After Anyalysis and stack overflow help come to know that Hibernate core 5.3.7.Final is not vulnerable in spring boot project for log4j vulnerability
Our system is a microservices-based system. It has more than 120 services. We were advised to upgrade the log4j version in our microservices to 2.16.0 to mitigate the recent log4j vulnerability. Currently, our services use the 2.11.2 version. Can't we just use -Dlog4j2.formatMsgNoLookups=true to mitigate these vulnerabilities.
Look at the Apache Log4j Security Vulnerabilities page, especially the explanation under the heading "Fixed in Log4j 2.12.2 and Log4j 2.16.0".
It explains that even in 2.15.0, which had the initial fix for CVE-2021-44228, there was a situation possible in which you still had a problem, which has a new ID: CVE-2021-45046
Note that previous mitigations involving configuration such as to set the system property log4j2.formatMsgNoLookups to true do NOT mitigate this specific vulnerability.
To protect yourself against the new CVE, update to 2.16.0.
I am using Microservices for a single release. Normally, I have a Version.json file which Jenkins gets the versions of microservices of each release and publish these multiple services.
Is there any other way to do it except using Version.json file ?
Thanks
Doing single release with microservices is an anti-pattern. Therefore there is no ideal answer to your question.
If you want to get rid of one centralized Version.json file, I would suggest, keeping microservice version separate in each microservice project/repository. Qhen doing release Jenkins would just look into each released microservice repository and extract version from there. :)
Instead of Version.json in Jenkins:
{
"microservice_a": "1.2.3",
"microservice_b": "2.3.4"
}
You would have:
Version.json in microservice_a repo:
"1.2.3"
Version.json in microservice_b repo:
"2.3.4"
We use fabric8-maven-plugin to manage the full lifecycle of all of our kubernetes services. We are having a problem upgrading statefulsets (similar to this post but we dont use the kubernetes-client). The version of the maven plugin is 4.3.1. We have no issues with daemonsets but I just cant find a way to update statefulsets. We get the same error as the afore mentioned post.
Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden..
I have tried to set the updateStrategy to rolling but that doesn't seem to do anything.
Thanks Paul
The application is developed on Spring Boot 2.0.1.
I include the next dependency to be able to use JavaMelody -
dependency("net.bull.javamelody:javamelody-spring-boot-starter:1.72.0")
JavaMelody configuration:
javamelody:
advisor-auto-proxy-creator-enabled: false
init-parameters:
url-exclude-pattern: (/webjars/.*|/css/.*|/images/.*|/fonts/.*|/js/.*)
As a result I have a performance monitoring system and completely broken integration tests (JUnit version is 5).
The exception message is
the configured DataSource [com.sun.proxy.$Proxy128] (named '') is not the one associated with transaction manager [org.springframework.orm.jpa.JpaTransactionManager] (named '').
It can be fixed by removing javamelody dependency or by disabling javamelody in config file of the application.
Does somebody know the cause of the issue? Doesn't it create some unobvious bugs out of tests' scope?
I faced the same issue. I found a solution. I checked the Java melody jar file and they have a spring.factories in there. I think this might be messing around with the configurations.
In the application-test.properties I added this:
spring.autoconfigure.exclude=net.bull.javamelody.JavaMelodyAutoConfiguration
and it seems to work.
add
spring.autoconfigure.exclude=net.bull.javamelody.JavaMelodyAutoConfiguration
in application.properties can help.