Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
Liferay 7.4 GA 9 and GA+ Sonatype Vulnerabilities Issues
Hello, I ran Sonatype Scan against liferay 7.4 GA9 and GA13 and resulted into 1 Critical 9 High and 16 Medium. vulnerabilties. Below is the list of vulnerabilties identified in the Liferay third party jars. Our Cyber security team is asking us to get these vulnerabilites remediated or fixed. Can someone please advise when these vulnerabitlies will be remediated by Liferay? Also, could we update the jars in the share container library folder and update the depency file to remediate the vulenrabiltites?
Critical: org.codehaus.woodstox : wstx-asl : 3.2.8 - The woodstox-core package is vulnerable to Improper Restriction of XML eXternal Entity (XXE) Reference. The setFeature and getFeature methods in WstxSAXParserFactory.class rely on the mSecureProcessing boolean value to be able to securely parse input XML. The boolean value, however, is set to false by default. Additionally, the class lacks support for properties XMLConstants.FEATURE_SECURE_PROCESSING and XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, which can make it possible for an attacker to conduct XXE attacks.
High : org.springframework : spring-web : 5.2.10.RELEASE - In Spring Framework, versions 5.2.x prior to 5.2.15 and versions 5.3.x prior to 5.3.7, a WebFlux application is vulnerable to a privilege escalation: by (re)creating the temporary storage directory, a locally authenticated malicious user can read or modify files that have been uploaded to the WebFlux application, or overwrite arbitrary files with multipart request data.
High: org.glassfish.web : javax.servlet.jsp.jstl : 1.2.3 - https://nvd.nist.gov/vuln/detail/CVE-2015-0254
High: com.liferay : org.apache.axis : 1.4.LIFERAY-PATCHED-6 - https://nvd.nist.gov/vuln/detail/CVE-2019-0227
High: com.fasterxml.jackson.core : jackson-databind : 2.12.4 - https://nvd.nist.gov/vuln/detail/CVE-2020-36518
High: org.apache.santuario : xmlsec : 1.5.8 - https://nvd.nist.gov/vuln/detail/CVE-2021-40690
High: commons-dbcp : commons-dbcp : 1.2.2 - The Apache Commons DBCP packages are vulnerable to Insufficiently Protected Credentials. The toString method in various classes as mentioned below, displays sensitive credentials. An attacker can exploit this as part of a larger attack, using said credentials to gain unauthorized access.
High: com.liferay : org.hibernate.core : 3.6.10.LIFERAY-PATCHED-6 - https://nvd.nist.gov/vuln/detail/CVE-2020-25638
High: com.fasterxml.jackson.core : jackson-databind : 2.12.4
The jackson-databind package is vulnerable to a Denial of Service (DoS) attack. The readExternal() method in the NodeSerialization class fails to restrict allocation when JsonNode objects are serialized/deserialized by the JDK. Consequently, since the first 4 bytes of serialized JsonNode objects indicate the size of the object's contents, certain payloads with an actual byte-length of 4 may cause the application to allocate a byte array of Integer.MAX_VALUE in size (2Gb). A remote attacker can exploit this vulnerability to cause the application to consume large amounts of available heap memory by submitting a payload that exploits this issue.
I think your group is asking the wrong question.
For example, it is not whether Liferay has an older version of commons-dbcp, it's whether the vulnerability it contains is exploitable or not.
In each of the cases here, none of them are exploitable by an external user. They could be exploited by a malicious developer who can deploy onto your platform, but if you have one of those they can already wreak lots of havoc without having to use any of these dependencies to get the job done.
Pick any one that you want and just read the CVE and decide if it is exploitable or not and, in every case, you'll quickly identify that they are all basically false positives.
For WSTX, they'd have to be able to submit a malicious xml file, something regular users cannot do.
For the Spring Web one, Liferay isn't using WebFlux so it is not susceptible to the vulnerabilities around that.
JSTL - Requires being able to submit a JSP page, something users cannot do.
Axis 1 - Liferay is not using or exposing the code w/ the vulnerability.
Etc, etc.
You have to remember that tools like Sonatype are stupid - all they do is identify the existence of a jar w/ a known security vulnerability, but they don't evaluate whether the vulnerability can actually be exploited in the code.
That becomes your job ;-)
Thanks David,
I did check the NVD database and there are some CVE's that are under re-analysis. Yes you are correct sonatype doesnt do a deep dive in the code to check if certain spring packages are being used. For example, the httpinovker under spring package org.springframework.remoting.httpinvoker which liferay doesnt as I looked thought he liferay code as it uses it uses it own http invoker. I am submitting the CVE's below to our cyber secuity team below for false positive and to be supressed
CVE-2016-1000027 CVE-2020-25638 CVE-2021-22118 CVE-2019-0227 CVE-2015-0254
Kevin
Hi David, just a question on the vulenerabilties for WSTX and others , we need consider internal users for exploting the code or sending a malicious file internally, as the cyber security team is also consider that use cases as well. Wouldnt this something to consider as well to remediate these vulenerabilties?
Thanks
Kevin
org.glassfish.web:javax.servlet.jsp.jstl:1.2.3 - Based on the description in CVE-2015-0254, this library isn't vulnerable:
Apache Standard Taglibs before 1.2.3...
yes its vulnerable for lesser version that 1.2.3. But they have this
clause in Root Cause
javax.servlet.jsp.jstl-1.2.3.jarorg/apache/taglibs/standard/tag/common/xml/TransformSupport.class(,
1.2.4). I will submit this as false positive because accoring ot NVD
this CVE is under re-analysys.
Hi David,
For Spring4Shell bug CVE-2022-22965. Is there plans for liferay to upgrade to Spring Framework 5.3.18 and 5.2.20. I know they mention the work around is downgrading to java 8, upgrading tomcat and disallowing fields.
Thanks
Kevin
Powered by Liferay™