Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Log4j security concerns
December 13, 2021
14:03, EET
Avatar
christopher_schmidt
Member
Members
Forum Posts: 5
Member Since:
May 19, 2020
sp_UserOfflineSmall Offline

Hi everyone,

it seems like there are critical vulnerabilities regarding Apaches log4j library (see Link below). I would like to know if this could be an issue regarding Java-SDK even tho we use 1.2.x currently.

https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/

Kind regards
Christopher

December 13, 2021
14:45, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 801
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

We are aware of this.

SDK 1.x (and Stack that it used) uses Log4j version 1; so it is not affected by this, as log4j1 is not (per http://slf4j.org/log4shell.html, that being said log4j1 is at end of life) basically the log4shell is Log4j2 problem as far was we are aware. However, while investigating … at https://www.lunasec.io/docs/blog/log4j-zero-day/ it does also say:

log4j v1​

Version 1 of log4j is vulnerable to other RCE attacks, and if you’re using it you need to migrate to 2.15.0.

(we are not aware what these other RCE attacks would be however as of writing this)
So you might be affected by something else, but not this particular issue.

SDK 2.x-4.x by itself “cannot be affected”, as it uses slf4j. However, if you have used log4j2 as the slf4j implementation in your apps that use the SDK you would be (i.e. it is outside of the SDK so to say). SDK still uses log4j1 in the SDK samples, as that was the only Java 6 slf4j implementation (and the SDK even in 4.x is still 6+). But in the light of (https://www.lunasec.io/docs/blog/log4j-zero-day/ log4j1 mention) we probably have to start to use something else (slf4j-simple maybe, or finally move to Java 8+) in the future, but regardless the selection of logging library is on the SDK user in SDK 2+ world.

Meanwhile also writing this here (we will make a blog once we have time…). Our apps are affected (servers more, clients maybe if connected to a attacker’s UA Server) and the server side apps have just been released (though news about might take a bit of time to write, simulationserver can be updated via the auto-update or via Help->Check for Updates..). Client side apps will be updated as well once server apps release pipeline is fully done.

So in practice I would recommend you to update first to SDK 3.x (as the stack part is merged in 4.x and in different packages this is probably easier) and then to 4.x to be 100% safe.

December 13, 2021
14:53, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 801
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

…aand sorry! I interpreted that as using SDK 1.2.x, but obiviously you mean the log4j1 version 1.2.x … but anyway, I sort of covered everything in the post, but to reiterate: Per the http://slf4j.org/log4shell.html log4j1 is NOT affected by this issue.

Per https://www.lunasec.io/docs/blog/log4j-zero-day/ there might be something ELSE (of what it would be, we are not aware, could also be an error; but currently no idea). Log4j1 is at end of life and at least per that page it is recommended to update to log4j2 2.15.0.

December 14, 2021
16:46, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 801
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

OK, also updating this to here: blog is at https://www.prosysopc.com/blog/log4shell-attack/ and also updated as of today.

All our apps are patched (by updating the log4j2 version) in their latest versions. Everyone should update to those versions (or to any later versions, if reading this later).

We noticed a different CVE has been made vs. log4j1: https://access.redhat.com/security/cve/CVE-2021-4104. Quote from the page:


Note this flaw ONLY affects applications which are specifically configured to use JMSAppender, which is not the default, or when the attacker has write access to the Log4j configuration for adding JMSAppender to the attacker’s JMS Broker.

If the Log4j configuration is set TopicBindingName or TopicConnectionFactoryBindingName configurations allowing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228 Log4j 2.x, Log4j 1.x is vulnerable. However, the attack vector is reduced as it depends on having write access, which is not a standard configuration rather than untrusted user input. These are sufficient factors beyond the attacker’s control.

Applications using Log4j 1.x may be impacted if their configuration uses JNDI as described above.

Thus unless that specific condition hold (which should not be a default, at least SDK samples do not use it as they just use org.apache.log4j.ConsoleAppender and org.apache.log4j.RollingFileAppender + org.apache.log4j.RollingFileAppender in some older releases), log4j1 is not affected by CVE-2021-44228. I assume this is the https://www.lunasec.io/docs/blog/log4j-zero-day/ reference to log4j1. Also as noting here that this is still “SDK samples” not the SDK itself (though, version 1.x of the SDK used log4j1 directly, as mentioned in the above post)

In addition at https://logging.apache.org/log4j/1.2/ there is a link to: https://www.cvedetails.com/cve/CVE-2019-17571/ with the note “A security vulnerability, CVE-2019-17571 has been identified against Log4j 1. Log4j includes a SocketServer that accepts serialized log events and deserializes them without verifying whether the objects are allowed or not. This can provide an attack vector that can be expoited. Since Log4j 1 is no longer maintained this issue will not be fixed. Users are urged to upgrade to Log4j 2.”

However, for this one I do not know when the vulnerability would be in play i.e. when this ‘ServerSocket’ would be in use. https://nvd.nist.gov/vuln/detail/CVE-2019-17571 mentions “Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data.”

If “deserialization gadget” means e.g. java serialization, it is not a problem for the SDK itself, as we do not use java serialization (the OPC UA serialization process is custom logic). Of course some other parts (outside of our control, outside SDK) in apps SDK users have done might use java serialization (or whatever “deserialization gadget” means), but that is outside of the “SDK scope” anyway.

So, my personal take on this exactly right now as of writing this would be that it might be that log4j1 is not directly unsafe depending on the conditions, but regradless it probably should not be used anymore. Thus, we’ll work towards remove it from the SDK samples somehow in the next release (unless we get some new info).

December 16, 2021
17:42, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 801
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

And continuing… blog post (https://www.prosysopc.com/blog/log4shell-attack/) is updated once again.

Per my current understanding another CVE-2021-45046 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 would not affect us, since our SDK for Java nor our applications use ‘MDC’ in code, but it is hard to say for certain (due to libs). Thus, we have released a second version of our apps just in case (note that Browser was already updated to log4j2 2.16.0 as it happened a bit later than the rest).

Anyway, apps use PatternLayout pattern=”%d{MM/dd/yyyy HH:mm:ss.SSS} %-5p [%t] %47c %3x – %m%n” i.e. does not include `Context Lookup` nor `Thread Context Map (MDC)` flags mentioned in the CVE text. Note that there is a difference in small x vs. large X in the layout. The small x is NDC (https://stackoverflow.com/questions/14134734/what-is-the-difference-between-log4js-ndc-and-mdc-facilities) is not mentioned in the CVE. Also, our SDK and applications also do not use `NDC` context either. However, as of writing we cannot say with 100% certainty a library used by our SDK or application would not use internally MDC/NDC. Also the CVE link does state “Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to localhost by default. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. “

Thus, I would recommend to update to the newer versions. Also updating to log4j2 2.16.0 if you are using it in your own apps (this is outside of the SDK etc. but just to note) is recommended.

Also … we basically just noted now: https://arstechnica.com/information-technology/2021/12/patch-fixing-critical-log4j-0-day-has-its-own-vulnerability-thats-under-exploit/. The first part of the article is about CVE-2021-45046. The second however is something else that links to https://www.praetorian.com/blog/log4j-2-15-0-stills-allows-for-exfiltration-of-sensitive-data/. So there could be a second problem with 2.15.0, but my understanding (per the link) would be that that too would be fixed by 2.16.0. Thus basically without knowing any better at this point I would recommend everyone to update to log4j2 2.16.0 as soon as possible.

December 20, 2021
16:36, EET
Avatar
rocket science
Member
Members
Forum Posts: 65
Member Since:
March 16, 2017
sp_UserOfflineSmall Offline

As the journey continues there is now the recommendation to update to log4j 2.17.0.

Do you plan to provide updates version of Browser, Simulation Server, etc the next days?

December 20, 2021
17:29, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 801
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

Per our understanding we are NOT affected by the thing 2.17.0 fixes. We do NOT use Context Lookup in the PatternLayout the applications create on first startup. And that is the only attack vector mentioned in https://logging.apache.org/log4j/2.x/security.html + https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105.

The blog post at https://www.prosysopc.com/blog/log4shell-attack/ now has updated info.

Thus (while not exactly up to me to decide this) we are not making new releases per current info. I managed to do beta versions before the analysis of the situation was done, so ask sales@prosysopc.com if needed, but per my understanding they are not needed. We’ll notify if the situation changes.

July 28, 2022
18:57, EEST
Avatar
in-fke
Member
Members
Forum Posts: 26
Member Since:
June 8, 2016
sp_UserOfflineSmall Offline

It would be helpful to remove Log4J1 completely in order to avoid any discussion (especially customers who emply scanning tools).
I find it way easier to remove the dependency then to argue that it’s “safe” (we may even have to legally declare that it’s “safe”, not an easy task).

As for now, this scanner https://github.com/hillu/local-log4j-vuln-scanner/releases reports a CVE.
Seems like prosys-opc-ua-java-sdk-codegen-standalone-4.4.2-326.jar has “unpack-dependencies” to Log4J1 in it and a sample references Log4J1.

C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk>c:\temp\local-log4j-vuln-scanner.exe C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary
local-log4j-vuln-scanner.exe – a simple local log4j vulnerability scanner

Checking for vulnerabilities: CVE-2019-17571, CVE-2021-44228, CVE-2021-45105
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\jaxb-api-2.2.11.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\org.eclipse.persistence.asm-2.7.4.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\org.eclipse.persistence.core-2.7.4.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\org.eclipse.persistence.moxy-2.7.4.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\prosys-opc-ua-java-sdk-codegen-standalone-4.4.2-326.jar
indicator for vulnerable component found in C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\commandline\lib\prosys-opc-ua-java-sdk-codegen-standalone-4.4.2-326.jar (org/apache/log4j/net/SocketNode.class): SocketNode.class SocketNode class missing FilteredObjectInputStream patch CVE-2019-17571
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\maven-integration
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\maven-integration\maven-install-helper
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\maven-integration\maven-install-helper\data
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\codegen\maven-integration\maven-install-helper\data\prosys-opc-ua-java-sdk-codegen-maven-plugin-4.4.2-326.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-mandatory
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-mandatory\bcpkix-jdk15to18-1.64.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-mandatory\bcprov-jdk15to18-1.64.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-mandatory\slf4j-api-1.7.28.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https\commons-codec-1.11.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https\commons-logging-1.2.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https\httpclient-4.5.10.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https\httpcore-4.4.12.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-opc-https\httpcore-nio-4.4.12.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-samples
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-samples\commons-cli-1.4.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-samples\log4j-1.2.17.jar
indicator for vulnerable component found in C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-samples\log4j-1.2.17.jar (org/apache/log4j/net/SocketNode.class): SocketNode.class log4j 1.2.17 CVE-2019-17571
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\lib-samples\slf4j-log4j12-1.7.28.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib\prosys-opc-ua-sdk-client-4.4.2-1266.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib-android
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib-android\bcpkix-jdk15on-1.58.0.0.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib-android\core-1.58.0.0.jar
examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary\lib-android\prov-1.58.0.0.jar

Scan finished

Samples referencing Log4J1

$ grep log4j $(find . -name pom.xml)
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/sampleconsoleclient/pom.xml: slf4j-log4j12
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/sampleconsoleclient/pom.xml: log4j
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/sampleconsoleclient/pom.xml: log4j
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/sampleconsoleclient/pom.xml:
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/simpleclient/pom.xml: slf4j-log4j12
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/simpleclient/pom.xml: log4j
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/simpleclient/pom.xml: log4j
./prosys-opc-ua-sdk-for-java-4.4.2-1266-client-binary/samples/simpleclient/pom.xml:

July 29, 2022
10:35, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 801
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Please note that you are replying to old things that have changed compared to the current release.

That above post is from December 20, 2021. The linked blog was updated multiple times: https://www.prosysopc.com/blog/log4shell-attack/, though it for the most parts was about 2.x.

The SDK version 4.4.2 is old. The current release version is 4.8.0. The samples were moved to use logback in https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-7-0, that also has more text on the matter. Codegen internals were moved also to use reload4j (I do not remember exactly when, but at least in 4.8.0).

August 1, 2022
11:07, EEST
Avatar
in-fke
Member
Members
Forum Posts: 26
Member Since:
June 8, 2016
sp_UserOfflineSmall Offline

I always prefer to follow up on a thread rather than polluting with new threads.
Sorry that I did not catch the newest binaries. Samples from 4.8 look OK now.
But 4.8.0 the code generator still contains log4j1 classes though, the scanner tells us:

C:\Users\fnke>c:\temp\local-log4j-vuln-scanner.exe C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.8.0-25-client-server-binary
local-log4j-vuln-scanner.exe – a simple local log4j vulnerability scanner

Checking for vulnerabilities: CVE-2019-17571, CVE-2021-44228, CVE-2021-45105

indicator for vulnerable component found in C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.8.0-25-client-server-binary\codegen\commandline\lib\prosys-opc-ua-java-sdk-codegen-standalone-4.8.0-16.jar (org/apache/log4j/net/SocketNode.class): SocketNode.class SocketNode class missing FilteredObjectInputStream patch CVE-2019-17571

August 1, 2022
14:00, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 801
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

I guess I should have explained a bit more, reload4j is basically log4j1 with fixes, https://reload4j.qos.ch/:
“… the reload4j project is a fork of Apache log4j version 1.2.17 with the goal of fixing pressing security issues. It is intended as a drop-in replacement for log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with reload4j.jar in your build with no source code changes in .java files being necessary. “

In Codegen 4.8.0 we used reload4j 1.2.18.1. That page listed above says that “CVE-2019-17571 (SocketServer) – fixed in 1.2.18.0 by hardening”, thus it is a bit odd it would show up with 1.2.18.1. Anyway, we are making an SDK 4.8.2 release during the next 2 weeks with the current plan. The included Codegen will have the latest reload4j.

P.S.
Basically in this tool we just use a ConsoleAppender programmatically (i.e. logging is not intended to be configured otherwise) as that allows equal output to our maven plugin.

August 3, 2022
15:33, EEST
Avatar
in-fke
Member
Members
Forum Posts: 26
Member Since:
June 8, 2016
sp_UserOfflineSmall Offline

Just to follow up on this, first of all THANKS for the fast update!
https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-8-2 states
“No functional changes, but internals use now slf4j-simple when logging in the commandline mode.”
And I can confirm that the Scanner no longer has any findings!
c:\temp\local-log4j-vuln-scanner.exe C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.8.2-35-client-server-binary

examining C:\dev\git\in-mvn-build-3rdparty\prosys-opc-ua-sdk\prosys-opc-ua-sdk-for-java-4.8.2-35-client-server-binary\codegen\commandline\lib\prosys-opc-ua-java-sdk-codegen-standalone-4.8.2-20.jar

Scan finished

Great! Cool

August 3, 2022
18:12, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 801
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Glad you like it. You were faster than me in making the reply here 🙂

That was the easiest way to solve it ‘now’ i.e. avoids the need to prove things.

So basically the “problem” is now outside of the SDK. We like might still need to comment on that, since we have suggested reload4j as log4j1 replacement.

We actually tried the scanner with latest reload4j (even the jar alone), but it did give the same output. Now then, since https://reload4j.qos.ch/ does say “CVE-2019-17571 (SocketServer) – fixed in 1.2.18.0 by hardening” either reload4j or the tool has a problem (or it is possible that I have misunderstood something or that we ran the scanner incorrectly). I could see a possiblity that the tool checks something like a sequence of bytecode, which might not exist 1:1 as reload4j is basically the log4j1 with fixes, thus like e.g. java compiler differences etc. could potentially produce a jar that still has the fix, but would not be detected by the scanner. Just a theory though, proving that might be something to be asked from reload4j or the scanner developers.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online: cigerxwinchaker@hotmail.com
14 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 120

pramanj: 86

ibrahim: 74

rocket science: 65

kapsl: 57

gjevremovic: 49

Sabari: 44

Xavier: 42

fred: 41

TimK: 41

Member Stats:

Guest Posters: 0

Members: 3124

Moderators: 17

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1277

Posts: 5457

Newest Members:

valentinanoblet, XNXXguini, RobertTop, baileyuup3516, Richardlacle, inezwb11, clarissabeasley, raulakhtar528, claritanisbett4, isiahhughey

Moderators: Jouni Aro: 942, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 801, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 25, Teppo Uimonen: 21, Markus Johansson: 41, Niklas Nurminen: 0, Matti Siponen: 209, Lusetti: 0

Administrators: admin: 1