Hi there,
I was wondering is there a way to init log4j2 in smartfox instead of v1? Are you considering changing log4j to log4j2 in the near feature?
The reason that why i am asking this is we want to use sentry appender: https://docs.sentry.io/platforms/java/guides/log4j2/
They have another appender that supports log4j but not recommended by them. https://docs.sentry.io/platforms/java/g ... acy/log4j/
Best regards
Using Log4j2
-
- Posts: 1
- Joined: 26 Nov 2021, 12:38
Re: Using Log4j2
Hi,
if Log4j 2.x package names don't collide with those of Log4J 1.x it should work, at least as an alternative for logging from your Extension code. I don't think think it would work as a drop-in replacement. Correct me if I am wrong.
As regards adopting Log4J 2.x in SFS2X we haven't looked into it. We may eventually transition to it but at the moment there's no plan. Sorry.
Cheers
if Log4j 2.x package names don't collide with those of Log4J 1.x it should work, at least as an alternative for logging from your Extension code. I don't think think it would work as a drop-in replacement. Correct me if I am wrong.
As regards adopting Log4J 2.x in SFS2X we haven't looked into it. We may eventually transition to it but at the moment there's no plan. Sorry.
Cheers
Re: Using Log4j2
Haha, I was just looking for anything Log4j related because of yesterday's zero-day and it was a good choice to stay with 1.x
Re: Using Log4j2
Yes, lots of people got scared by the recent Log4J 2 vulnerability, but it doesn't seem to affect 1.x, which is what we're using.
Cheers
Cheers
Re: Using Log4j2
Lapo wrote:Yes, lots of people got scared by the recente Log4J 2 vulnerability, but it doesn't seem to affect 1.x, which is what we're using.
Cheers
You mean this line in /config/log4j.properties about JNDI in a production server is no reason to panic, right?
log4j.category.jndi=INFO
Re: Using Log4j2
The vulnerability that is in the news these days affects Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
SmartFoxServer 2X does not use any of the vulnerable versions. It uses Log4J 1.2.x
So please no panic
Cheers
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
SmartFoxServer 2X does not use any of the vulnerable versions. It uses Log4J 1.2.x
So please no panic
Cheers
-
- Posts: 19
- Joined: 01 Feb 2018, 04:33
Re: Using Log4j2
Hi Lapo,
They just found out a new vulnerability of Log4j. I think you may have a look on it:
Ref link: https://nvd.nist.gov/vuln/detail/CVE-2021-4104
They just found out a new vulnerability of Log4j. I think you may have a look on it:
JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
Ref link: https://nvd.nist.gov/vuln/detail/CVE-2021-4104
Sean Su
Mecury Studio
Mecury Studio
Re: Using Log4j2
Thanks Sean,
We do not use JMSAppender in the SFS2X default configuration, nor we recommend it or provide instructions to do so in our documentation.
It's good to know that this issue exists, but given its specificity (i.e. you need to manually setup the appender and the attacker must have write access to the logs), it looks like it has a very miniscule (if any) impact.
We recommend to read the detailed analysis provided by RedHat at this address:
https://access.redhat.com/security/cve/CVE-2021-4104
If there's anything else let us know.
Cheers
JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration.
We do not use JMSAppender in the SFS2X default configuration, nor we recommend it or provide instructions to do so in our documentation.
It's good to know that this issue exists, but given its specificity (i.e. you need to manually setup the appender and the attacker must have write access to the logs), it looks like it has a very miniscule (if any) impact.
We recommend to read the detailed analysis provided by RedHat at this address:
https://access.redhat.com/security/cve/CVE-2021-4104
If there's anything else let us know.
Cheers
Who is online
Users browsing this forum: No registered users and 80 guests