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: 726
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: 726
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: 726
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: 726
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: 52
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: 726
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.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
16 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 113

pramanj: 86

ibrahim: 74

kapsl: 57

rocket science: 52

gjevremovic: 49

Xavier: 42

fred: 41

TimK: 41

Fransua33: 39

Member Stats:

Guest Posters: 0

Members: 1743

Moderators: 17

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1206

Posts: 5137

Newest Members:

LimaomoT, eulaallcot, brain7955241817, barbaravillalobo, widallet, erminovski, etsuko73u61420, donnyblaxland, DonaldHAp, kelvin6887

Moderators: Jouni Aro: 918, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 726, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 24, Teppo Uimonen: 21, Markus Johansson: 36, Niklas Nurminen: 0, Matti Siponen: 163, Lusetti: 0

Administrators: admin: 1