We are using below list of Spring Framework jar files in the application and we are not using Spring’s websocket or any other form of websocket dependencies in the application and no code references of enabling STOMP support.
Could someone please confirm if we are still vulnerable to CVE-2018-1270?
spring-security-web-4.2.3.RELEASE.jar
spring-security-core-4.2.3.RELEASE.jar
spring-security-config-4.2.3.RELEASE.jar
spring-aspects-4.3.12.RELEASE.jar
spring-web-4.3.12.RELEASE.jar
spring-tx-4.3.12.RELEASE.jar
spring-orm-4.3.12.RELEASE.jar
spring-jdbc-4.3.12.RELEASE.jar
spring-expression-4.3.12.RELEASE.jar
spring-core-4.3.12.RELEASE.jar
spring-context-support-4.3.12.RELEASE.jar
spring-context-4.3.12.RELEASE.jar
spring-beans-4.3.12.RELEASE.jar
spring-jms-4.3.12.RELEASE.jar
spring-messaging-4.3.12.RELEASE.jar
spring-aop-4.3.12.RELEASE.jar
All versions of the 4.3 branch (up to 4.3.15) are affected, you should upgrade to 4.3.16 as recommended. Further information here: https://pivotal.io/security/cve-2018-1270
This only affects you if you use STOMP over WebSockets, otherwise you are not affected.
Related
Currently there are so many suggested steps that have been posted for excluding log4j-core library from dependency or upgrading to the latest (above version 2.15) version according to Spring Blog . Are there any recommended tools that can be used for protecting spring application deployed in Google App Engine or Pivotal Cloud Foundry(PCF) for protecting instead of patching them for redeployment?
Another necessary question is, does it make my application(microservice spring application) to be vulnerable if it uses another microservice for some of its service if it depends on another microservice and if that microservice already uses vulnerable version of log4j-core?
In regard to your first question, you can set an environment variable in order to disable the replacement lookups in log4j:
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Please note that this only works for log4j >= 2.10.
I believe you can set environment variables in PCF without having to redeploy the service (of course, a restart would be needed), so no new release would be needed. See: https://docs.pivotal.io/pivotalcf/2-3/devguide/deploy-apps/environment-variable.html and https://cli.cloudfoundry.org/en-US/v6/set-env.html
In order to see whether your spring-boot application is vulnerable to the exploit, you could use a spring-boot test I created for that purpose: https://github.com/chilit-nl/log4shell-example - You could test your application with and without the environment variable, to see if it has any effect (assuming that your application currently is vulnerable).
Short answer to your first question is may be. You can protect your application/service by using rules in WAF to discard the ${jndi://ldap pattern. However, there are so many mutations of this (base64 encoding etc.) that it will not be foolproof. If you are worried about dependencies, you should set the JVM Parameter and redeploy your app to prevent the lookup as a workaround.
Regarding your 2nd question - the answer is yes if the the 2nd micro service is being passed the same input and it's logging.
When creating a new Spring Boot project using Spring Initializr and adding Azure Support, it adds a dependency to com.microsoft.azure:azure-spring-boot-starter.
implementation 'com.microsoft.azure:azure-spring-boot-starter'
The spring cloud documentation says:
The Azure Support entry contains auto-configuration support for Azure
managed services [...]
Now I'd like to send and receive messages from Azure Service Bus and the documentation wants me to add a dependency to azure-servicebus.
implementation 'com.microsoft.azure:azure-spring-boot-starter'
implementation 'com.microsoft.azure:azure-servicebus'
Okay fine. When I now switch over to Microsoft and read the documentation about Service Bus there, it mentions two libraries, where Microsoft states the second one is dated and legacy.
azure-messaging-servicebus (latest) implementation 'com.azure:azure-messaging-servicebus:7.0.0'
azure-servicebus (legacy) 'com.microsoft.azure:azure-servicebus'
Question
Is the Spring Boot documentation just outdated?
I have read somewhere that libraries in com.microsoft.com are for managing the resource itself, while libraries in com.azure are for managing the data. Is this true?
What is meant by auto-configuration support?
As you can see I am very confused which dependencies I need to add. Also I don't get the difference between packages from com.azure and com.microsoft.azure.
Can someone please shed some light on this?
My company's Sonatype scan shows Spring-Web is vulnerable even for the latest version (currently 5.2.3.RELEASE).
It reads:
"Found security vulnerability CVE-2016-1000027 with severity 9.8".
I noticed CVE-2016-1000027 is added to the NATIONAL VULNERABILITY DATABASE
on 01/02/2020, and it is in regards to
"Spring Framework 4.1.4 suffers from a potential remote code execution
(RCE) issue if used for Java deserialization of untrusted data".
Is this an obsolete ticket or has it not be resolved after 4 years?
This issue is resolved from a Spring Framework point of view, see my latest comment summarizing the situation on that issue. Your application is only vulnerable if you're using HTTPInvokerServiceExporter or RemoteInvocationSerializingExporter and reading data from untrusted sources.
Deserializing Java code from untrusted sources is a well-known problem in Java (so, all Java applications and Frameworks!), and this feature might be removed in future Java versions.
Given the nature of this security problem (there's no way to "fix it" besides removing the classes, which will be done in the next major version of Spring Framework), contacting your vendor or your security team is the best course of action. The Spring team is happy to help the community with this matter by providing more context on that issue if needed.
In my project I am forced to use these packages:
com.sparkjava:spark-core:2.3, which ends up using jetty-server:9.3.2.v20150730
org.apache.spark:spark-core_2.10:1.2.0, which ends up using jetty-server:8.1.14.v20131031
Note that com.sparkjava and org.apache.spark have nothing to do with each other. They are called both spark funnily.
The issue here is that both jetty versions are incompatible, so if I force jetty 8.X the system crashes, if I force jetty 9.X the system crashes again, I get java.lang.NoClassDefFoundError: org/eclipse/jetty/server/ServerConnector in one case and java.lang.NoClassDefFoundError: org/eclipse/jetty/server/bio/SocketConnector in the other.
What I am expected to do in such a situation ?
Note: I've tried to shadow jetty, but the dependency manager resolves just one (9.X by default, or 8.X if I force it) and then it shadows it, so it's really not helping.
It would be exceedingly difficult to resolve this situation.
Jetty 8.1 is about 4 major version behind Jetty 9.3, which represents many hundreds of releases of difference.
Note: Jetty versioning is [servlet_support].[major_ver].[minor_ver].
Jetty 8.x is Servlet 3.0, while Jetty 9.x is Servlet 3.1
The architecture of the connectors has evolved tremendously in that time frame, from being old school blocking Sockets in Jetty 8 to no blocking connectors at all in Jetty 9, with Jetty 9 needing to evolve the connectors to support features in TLS/1.2, and ALPN in order to properly support HTTP/2, and the internal I/O handling to support the new Servlet 3.1 Async I/O feature set.
Solution #1:
You won't be able to have both versions running in the same VM without some sort of classloader isolation, and careful configuration to ensure they don't claim the same resources (listening ports, temp files, etc)
Solution #2:
Upgrade (or downgrade) one or the other spark dependency till you hit a common jetty version. (Spark_2.11 / 2.0.0 seems to support Jetty 9.2.x)
Solution #3:
Apache Spark is open source, go submit a patch that upgrades its use of Jetty to 9.3 (this might be difficult as Apache Spark isn't ready to use Java 8 yet, which is a requirement for Jetty 9.3)
What is the best choice for an open source Enterprise-level application server when using Java 6 and Spring 3.1? Glassfish or JBOSS? Looking for good support e.g. online documentation, features, ease of use and set up, good performance, security, scalability, high availability features etc. that an enterprise would require. Enterprise being a large commercial or government client.
Are you using EJBs? If not, I would recommend jetty. jetty is a very light-weight container for doing most of the exploration/testing you would want to do in a project. Another plus that jetty delivers is that it is configured with only the most basic features enabled/configured by default.
Are you using Maven? If so, I would also recommend jetty-maven-plugin. In the past, I've had some success with using the jetty-maven-plugin for local testing on a previous project.