Log4j Vulnerability impact on Cloud SDK project - sap-cloud-sdk

We have some use cases which leverage Cloud SDK project template for Java. Now they are already running on SAP BTP, Cloud Foundry environment. By default, it uses logback and we did not change it.
When getting dependencies with maven command mvn dependency:tree in cloud sdk project, I can see log4j-to-slf4j:jar:2.14.1 and log4j-api:jar:2.14.1 is used by SAP Spring xsuaa library and spring-boot-starter-logging.
[INFO] | | +- org.springframework.boot:spring-boot-starter-logging:jar:2.5.6:compile
[INFO] | | | +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.14.1:compile
[INFO] | | | | \- org.apache.logging.log4j:log4j-api:jar:2.14.1:compile
[INFO] +- com.sap.cloud.security.xsuaa:xsuaa-spring-boot-starter:jar:2.11.0:compile
[INFO] | +- com.sap.cloud.security.xsuaa:spring-xsuaa:jar:2.11.0:compile
[INFO] | | +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.14.1:compile
[INFO] | | | \- org.apache.logging.log4j:log4j-api:jar:2.14.1:compile
According the [Spring official documentation][1]. Only log4j-core is affected. The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own. From my perspective, there should be no impact on Cloud SDK project with libraries originally included.
Could you give some comments?

This writeup of the SLF4J developers describes their situation quite well: http://slf4j.org/log4shell.html
The SLF4J API is just an API which lets message data go through.
This means it all depends on the actual logging implementation that you use.
The SDK modules do not provide or expect any logging implementation.
In our CF Archetypes we use slf4j-simple for test cases and logback for productive logging, however this can be changed by the consumer of the archetype.
On Neo the runtime provides an implementation, so that the archetype does not provide any implementation.

Related

Spring 5.X web Kafka Integeration using xml configuration (Not Spring boot)

I am trying to setup a kafka consumer on legacy web application using xml configuration that is running Spring 5.2 release project (It is not a spring boot project).
After looking up I found a project that sets up the kafka consumer using xml configuration like in here
https://docs.spring.io/spring-kafka/docs/1.3.11.RELEASE/reference/html/_spring_integration.html
However this does not give details on how to connect this with java in a spring web application . All examples are for spring-boot project. I did find out what configuring I need to add to xml
https://github.com/spring-projects/spring-integration-kafka
I also did find an example of Spring web application and kafka but it is for 4.X release and is from 2015.
https://techannotation.wordpress.com/2015/10/26/introduction-to-apache-kafka-using-spring/
Any help on any newer documentation or on how to setup a consumer in java spring web project with xml configuration in 2020 would be appreciated
It is not clear why you mention Spring Integration framework all the time, but you don't accent on it.
Let's see if this doc helps you though: https://docs.spring.io/spring-integration/docs/current/reference/html/kafka.html#kafka !
Pay attention the Spring Integration is 5.4 already.
This sample is Spring Boot based, but still should give you a general idea how to configure Kafka channel adapter with Java: https://github.com/spring-projects/spring-integration-samples/tree/master/basic/kafka
With Help from Gary Russel and Artem Bilan I was able to figure this out. Since I am using legacy spring application I needed this project and not spring integration project
https://spring.io/projects/spring-kafka
I also followed documentation here to setup java config for kafka listener
https://docs.spring.io/spring-kafka/docs/2.3.12.RELEASE/reference/html/#with-java-configuration
I used this to figure out how to have both java config and xml config work together
https://memorynotfound.com/mixing-xml-java-config-spring/
Here is gist of my implementation that worked
https://gist.github.com/praveen2710/7dcf1671379ee6db4581436e1225c673

JNA library for z/OS (USS)

I am trying to run cassandra on z/OS USS (Mainframe) which loads JNA jar. CASSANDRA fails to start with an error -
ERROR [main] 2020-04-01 01:07:44,272 NativeLibraryLinux.java:64 - Failed to link the C library against JNA. Native methods will be unavailable.
java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/z/os-s390x/libjnidispatch.so) not found.
I could not find com/sun/jna/z/os-s390x/libjnidispatch.so inside the jar. libjnidispatch.so uses libffi C library. There is a port available https://github.com/eclipse/openj9/tree/master/runtime/libffi/z. I am not sure how to compile libffi and libjnidispatch.so on USS (Mainframe).
Is there any JNA library/libjnidispatch.so port available on z/OS USS (Mainframe)?
There is an open source project that is implementing Devops on Z called Polycephaly. Here is a link to their comments on this error.
They do not specifically refer to Cassandra but this is an error related to Jenkins as one of several distributed tools to improve DevOps on z/OS.
The error does not seem to impact what they are doing as there are alternative classes available to manage this function.
Note: the error 'com/sun/jna/z/os-s390x/libjnidispatch.so' not found is normal. The z/OS Java doesn't contain the Oracle JNI classes. This will not cause any issues.

CVE-2010-1807 vulnerablity (from android-json) in Spring Boot 1.5.3

When running OWASP dependency check I am getting following issue reported (vulnerable dependency)
CWE: CVE-2010-1807
CWE-20 Improper Input Validation
Severity (CVSS): High (9.3)
Dependency: android-json-0.0.20131108.vaadin1.jar
I am using Spring Boot 1.5.3.
Doing gradlew dependencies I see that android-json is indeed dependency of Spring Boot
+--- org.springframework.boot:spring-boot-configuration-processor: -> 1.5.3.RELEASE
| \--- com.vaadin.external.google:android-json:0.0.20131108.vaadin1
How to check if this is false-positive or valid issue?
edit: this dependency is not used in runtime. it is used only in tests.
If the dependency is only used in tests, then it should be fine. Tests, almost by definition, don't use user input, and are not typically available to be run in a production environment. Therefore, a vulnerability in a test, or in a dependency of a test, isn't really a concern. I would reach out to the Spring Boot developers to ask why they have a potentially vulnerable library as a dependency, or look on their GitHub issues.
The issue is a false positive.
As described in the CVE, the vulnerability is in Apple's WebKit that was used in Android before 2.2:
WebKit in Apple Safari 4.x before 4.1.2 and 5.x before 5.0.2; Android before 2.2; and webkitgtk before 1.2.6; does not properly validate floating-point data, which allows remote attackers to execute arbitrary code or cause a denial of service (application crash) via a crafted HTML document, related to non-standard NaN representation.
It would appear that the OWASP dependency check as incorrectly identified android-json-0.0.20131108.vaadin1.jar as being part of Android. In reality the jar is a clean room implementation of org.json:json that has nothing to do with Android other than originally being developed by the Android team. It certainly doesn't contain WebKit.

External Authentication for Cassandra in DSE 4.7

We are trying to implement external authentication to Cassandra on DSE 4.7. Followed few of the guides where we have to extend IAuthenticator class but after doing that there is less documentation on how to integrate.
Is it more of plug and play where we extend IAuthenticator class build a jar and place it in lib(/usr/share/dse/resources/cassandra/lib) and change the yaml file accordingly or is it take a source code from Github build entire tree and then use?
If so is Datastax's Cassandra available on Github?
What do we need to do to build external authentication other that LDAP and Kerberos in DSE 4.7?
extend IAuthenticator class build a jar and place it in
lib(/usr/share/dse/resources/cassandra/lib) and change the yaml file
accordingly
^^ yes, this is the right approach.
Datastax's Cassandra available on Github?
Not exactly. You'll see the version of c* that ships with DSE in the release notes, you can check the source in the apache/cassandra github and it will match (up to and excluding the build number). The exact c* build under DSE will have some critical patches from future versions and that exact source code is not avaliable. However, the dot release in apache/cassandra is good enough for all intents and purposes.
I.E. look at https://github.com/apache/cassandra/tree/cassandra-2.1.8 for 4.7.1
As mentioned by #Mikea we need to override ISaslAwareAuthenticator and while using Cassandra in DSE need to be very sure of Cassandra version and then dig into appropriator Github repo.

Groovy project - Sonar - Publish project and Unit + Integration Test code coverage data

I have:
1. Gradle 1.6
2. SonarQube instance 5.0 (also have 4.1+ instances)
3. sonar-runner (aka SonarQube runner) version: 2.4
4. Groovy Version: 2.3.3 JVM: 1.7.0_40 Vendor: Oracle Corporation OS: Linux
I have project's with Java, Java + Groovy or totally Groovy based project.
All of these projects have valid Unit and non-Unit tests (Integration, Selenium etc). I'm also running various static analysic tools for both Java/Groovy (pmd, findbugs, checkstyle, codenarc etc).
For a Java based project, when I run sonarRunner (Gradle task) OR sonar-runner, I see valid data in project's Sonar dashboard for everything (including combined code coverage and other project health info). So, everything works for a JAVA based project.
The same though, is not working for a Groovy based project. i.e. when I pass "sonar.language=grvy" for a Groovy based project and run Sonar analysis, I do NOT get Unit and IT test coverage as it says 0% coverage OR it doesn't even LIST those in Sonar project's dashboard but I successfully get project health info (issues, lines of code, etc etc).
When I pass the above sonar language variable as "sonar.language=java" for this Groovy project, I do NOT see Groovy project's data info (issues, lines of code etc etc) and any code coverage info for Unit / Integration tests and their combined tests. I have valid jacoco exec files for both Unit tests and Integration tests (jacocoIT.exec is created after jacocoagent is attached to the target Tomcat JVM and after Tomcat instance is stopped).
Any ideas! why sonar is not working for a Groovy based project OR for a project which has both Java+Groovy (source Java, tests in Groovy or vice versa or mixed).
PS: I tried sonar.language=grvy,java OR sonar.language=java,grvy BUT, it didn't make any improvement on the project's sonar dashboard.
The latest SonarQube version that I have (5.0) does support multiple language support.
Sonar's Project Motion Chart plugin also doesn't show any info as well even though Lines of Code is showing up at the right side (when sonar.languages is passed as grvy).
When I pass sonar.language=java I get, here Project Motion Chart is showing nothing (not even a blank graph) says "No Data". All other project health related info is gone too (Technical debt etc fields says 0):
With the latest SonarQube version, I see there are new sonar.*.* fields and I'm trying to find if I'm missing to provide a field or it's correct value.
OK.. what happens??? when I use SonarQube instance version 4.1.2 (instead of 5.0)
When I use sonar.language=java
I see some info and Unit test coverage says 0% but Unit test success says 100% successful. Even though I have valid jacoco IT exec file for Integratiojn tests, it still not showing that widget info.
When SonarQube instance is 4.1.2 and if I set sonar.language=grvy, I do NOT see any Unit tests coverage or IT coverage of state of tests being successful % at all:
This is what I have in my project's sonar-project.properties file (when I use sonar-runner utility).
sonar.projectName=GradlePlugin
sonar.projectKey=com:company:projectABC:GradlePlugin
sonar.projectVersion=1.0
# optional description
sonar.projectDescription=ContainerSvc Business Service
#sonar.language=grvy,java
sonar.language=java
#Tells SonarQube that the code coverage tool by unit tests is JaCoCo
sonar.java.coveragePlugin=jacoco
#Tells SonarQube to reuse existing reports for unit tests execution and coverage reports
sonar.dynamicAnalysis=reuseReports
#Tells SonarQube where the unit tests execution reports are
sonar.surefire.reportsPath=build/test-results/UT
# Some properties that will be inherited by the modules
#sonar.sources=src/main/groovy,src/main/java,src/test/java,src/test/groovy,src/java-test,src/groovy-test
# Sonar Unit Test Report path
sonar.jacoco.reportPath=build/jacoco/UT/jacocoUT.exec
# Sonar Integration Test Report Path
#sonar.jacoco.itReportPath=build/jacoco/IT/jacocoIT.exec
sonar.jacoco.itReportPath=build/jacoco/UT/jacocoUT.exec
# Sonar Binaries
sonar.binaries=build/classes/main
sonar.java.binaries=build/classes/main
sonar.groovy.binaries=build/classes/main
sonar.sources=src/main/groovy
sonar.tests=src/test/groovy
# Encoding of the source code
sonar.sourceEncoding=UTF-8
sonar.scm.url=scm:svn:http://kobaloki/Core/GradlePlugin/trunk
sonar.junit.reportsPath=build/test-results/UT
sonar.java.coveragePlugin=jacoco
sonar.groovy.coveragePlugin=jacoco
sonar.grvy.coveragePlugin=jacoco
I used/tweaked the above values many time with different values while running sonar-runner.
I used the same values with -D / -P parameters when I run sonarRunner task in Gradle.
Note: SonarQube 5.0 won't work with Gradle (1.6) version (that I'm using) as I get an error about "Failed to download Libraries" etc. (this error won't come if I use Gradle > 2.2 version).
One other point I noticed is that, even though I'm using Groovy compile option debug=true for compiling both Groovy project's source and tests code, while doing sonar-runner (with both SonarQube instance 4.1.2 or 5.0 isntances) --or running sonarRunner Gradle task (with 4.1.2), I see the following lines in the analysis output.
15:32:20.647 INFO - Analysing /production/jenkins/AKS/ma/GradlePlugin/build/jacoco/IT/jacocoIT.exec
15:32:21.025 WARN - Coverage information was not collected. Perhaps you forget to include debug information into compiled classes?
and
15:32:24.681 INFO - Analysing /production/jenkins/AKS/ma/GradlePlugin/build/jacoco/UT/jacocoUT.exec
15:32:24.791 WARN - Coverage information was not collected. Perhaps you forget to include debug information into compiled classes?
15:32:24.792 INFO - Sensor JaCoCoSensor done: 112 ms

Resources