WSO2IS 5.8 include Log4j 1.2.17
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.
Someone knows if this vulnerability can be exploited in the context of WSO2IS 5.8?
Thanks in advance!
WSO2 is very frequently issuing security patches as and when the issues are discovered. Can you please write to security#wso2.com and check.
Also - as a security best practice we recommend to use security#wso2.com all the time to report security issues - this is a common practice followed by all open source projects.
UPDATE: Even though the WSO2 Identity Server 5.8.0 has this dependency, it does not use any of the functionalities provided by SocketServer. So, anyone using 5.8.0 version is NOT affected. Also, since IS 5.9.0 this dependency is upgraded to Log4j 2.
More details here: https://wso2.com/security
Related
We observed vulnerability CVE-2022-29464 being exploited in the wild since April, allowing unrestricted file uploads resulting to arbitrary remote code execution (RCE) found from here
This affects WSO2 API Manager 2.2.0 and above, Identity Server 5.2.0 and above, Identity Server Analytics 5.4.0 to 5.6.0, Identity Server as Key Manager 5.3.0 and above, Open Banking AM 1.4.0 and above, and Enterprise Integrator 6.2.0 and above.
We're using WSO2 EI Product V6.4.0/6.5.0.
I have seen Security Advisory WSO2-2021-1738 guideline too.
We don't have Support Subscription, So I'm planning to remove <FileUploadConfig>mappings in the <product_home>/conf/carbon.xml as suggested in same WSO2 Security Advisory page.
Is this mitigations step enough or do we need to concentrate further more on this?
As per the advisory, it seems disabling the file upload services is not a complete fix. If you look at the fix that has been implemented it has code-level changes as well.[1]
[1] - https://github.com/wso2/carbon-kernel/pull/3152/files
Maybe a naive question. but many projects still use Log4j 1.x
Is there no possibility to fix at least the CVE's in Log4j 1.x? It is clear that every project should switch to log4j2. But that doesn't change the fact that the smaller security leaks in Log4j 1.x are there, even if less critical.
It it possible that the community of Log4j maybe describes how to use Log4j 1.x to be more secure. e.g. not to use some of the appenders?
The development of log4j is volunteer based. There simply aren't enough volunteers to keep maintaining all legacy applications.
And even if there is some volunteer that patches log4j 1.2 (=latest), it is still a deprecated version that is not up-to-date in many other ways (has not been updated for 6 years). Everybody should really migrate to log4j2.
Read this blog post from Apache
We are using TestNG framework with Log4j for preparing end to end tests. Should we take some action?
Just because the vulnerability is only in your test dependencies, does not mean you could ignore it.
However you should be under full control of your input and this should cover all possible log messages as well. So you could assume that nobody from outside can easily exploit this vulnerability. So if are not planning to add injection Strings to your test data, you should be OK.
I recommend to update anyway, as you never know if it could be used in some way of exploit chain (another exploit in the future might rewrite your input, and that ends up in the logging). But it has a lower priority than fixing any public available server.
Version 2.15.0 of log2j contains the fix.
In one of my servers i am getting the above exception. can anyone suggest how to resolve this.
in the WLS9-async component due to unsafe deserialization of XML
encoded Java objects. An unauthenticated, remote attacker can exploit
this, via a crafted Java object, to execute arbitrary Java code in
the contex
How to apply the patch on this
Thanks in advance.
It is a known security issue relative to java deserialization mecanism.
You can read details about in this article from Oracle. The best thing to do is to apply the latest PSU and CPU published by Oracle.
You can also rename the bea_wls9_async_response.war application from your WebLogic Server installation to prevent the issue.
A security flaw in Groovy was detected in versions 1.7 to 2.4.3:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3253
The MethodClosure class in runtime/MethodClosure.java in Apache Groovy 1.7.0 through 2.4.3 allows remote attackers to execute arbitrary code or cause a denial of service via a crafted serialized object.
Does this affect "typical" Grails projects that retrieve data from user input (web forms), the DB, web services, etc. and assume this is all text, not serialized objects? In other words, is there any of this happening implicitly that we should be aware of?
Otherwise, what should we look for to ensure this bug isn't affecting us?
Grame has an issue for exactly this, but noone has been able to show any way to exploit it in a Grails app yet: https://github.com/grails/grails-core/issues/9113
In short: "the plan is 2.5.1 and 3.0.4 will have Groovy 2.4.4"