About logging vulnerabilities

[onair1127]

trafficstars

Hello? And thank you so much for developing and deploying this great API.

Even now, I'm using AWS Lambda to make good use of it.

First of all, I would like to apologize for my poor English skills.

It's been a while since I posted this, but I discovered it too late and I'm posting this issue.

When I recently checked the FFmpeg related log, I saw the following warning log.

WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Transforming org/apache/logging/log4j/core/lookup/JndiLookup (lambdainternal.CustomerClassLoader@433c675d)

This warning is a statement that AWS Lambda itself has been replaced with JndiLookup if the problematic version of Log4j is being used even after the Log4j-related vulnerability issue occurred in December 2021.

Before the vulnerability issue, I didn't care because each application did not use Log4j, but I found that this warning was continuously displayed for every request only in the application using FFmpeg.

As a result of the check, the part that outputs the final FFmpeg command to the log before execution (net.bramp.ffmpeg.RunProcessFunction) is no longer logged, and I ask you a question by finally confirming that there is a problem in this part.

Actually, before asking this question, it is right to ask a more specific question after replacing and testing the logging framework of the application with Logback and finally getting the results, but I am unable to use logback in Lambda, so I am asking this question.

Is the logging framework used by this API free of issues with current issues?

And the AWS Lambda documentation tells me to use the log4j dependency as required after the vulnerability. Could you please update the version to match the dependency below?

implementation 'org.apache.logging.log4j:log4j-api:2.17.1'
implementation 'org.apache.logging.log4j:log4j-core:2.17.1'
runtimeOnly 'org.apache.logging.log4j:log4j-slf4j18-impl:2.17.1'
runtimeOnly 'com.amazonaws:aws-lambda-java-log4j2:1.5.1'

Thanks for reading this long and sloppy post.

[bramp]

yes I think we are free of issues.

This is the latest dependency tree, and we do not use log4j:

$ mvn dependency:tree

[INFO] net.bramp.ffmpeg:ffmpeg:jar:0.6.3-SNAPSHOT
[INFO] +- org.slf4j:slf4j-api:jar:1.7.36:compile
[INFO] +- com.github.spotbugs:spotbugs-annotations:jar:4.6.0:provided
[INFO] |  \- com.google.code.findbugs:jsr305:jar:3.0.2:compile
[INFO] +- com.google.errorprone:error_prone_annotations:jar:2.12.1:provided
[INFO] +- com.google.guava:guava:jar:31.1-jre:compile
[INFO] |  +- com.google.guava:failureaccess:jar:1.0.1:compile
[INFO] |  +- com.google.guava:listenablefuture:jar:9999.0-empty-to-avoid-conflict-with-guava:compile
[INFO] |  +- org.checkerframework:checker-qual:jar:3.12.0:compile
[INFO] |  \- com.google.j2objc:j2objc-annotations:jar:1.3:compile
[INFO] +- commons-io:commons-io:jar:2.11.0:compile
[INFO] +- org.apache.commons:commons-lang3:jar:3.12.0:compile
[INFO] +- com.google.code.gson:gson:jar:2.9.0:compile
[INFO] +- org.modelmapper:modelmapper:jar:3.1.0:compile
[INFO] +- ch.qos.logback:logback-classic:jar:1.2.11:test
[INFO] |  \- ch.qos.logback:logback-core:jar:1.2.11:test
[INFO] +- junit:junit:jar:4.13.2:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- org.mockito:mockito-core:jar:4.4.0:test
[INFO] |  +- net.bytebuddy:byte-buddy:jar:1.12.8:test
[INFO] |  +- net.bytebuddy:byte-buddy-agent:jar:1.12.8:test
[INFO] |  \- org.objenesis:objenesis:jar:3.2:test
[INFO] +- org.hamcrest:hamcrest:jar:2.2:test
[INFO] +- org.hamcrest:hamcrest-integration:jar:1.3:test
[INFO] |  \- org.hamcrest:hamcrest-library:jar:1.3:test
[INFO] +- com.nitorcreations:matchers:jar:1.3:test
[INFO] |  \- org.hamcrest:hamcrest-generator:jar:1.3:test
[INFO] \- org.glassfish.grizzly:grizzly-http-server:jar:3.0.1:test
[INFO]    \- org.glassfish.grizzly:grizzly-http:jar:3.0.1:test
[INFO]       \- org.glassfish.grizzly:grizzly-framework:jar:3.0.1:test

We do use org.slf4j, which is a simple interface ontop of log4j and other logging libraries. I don't know if the warning is a false positive because org.slf4j is probing for log4j, or log4j is actually being included by another dependency of yours.