Headline
CVE-2022-24898: XWIKI-18946: Improve the default XML parser · xwiki/xwiki-commons@947e892
org.xwiki.commons:xwiki-commons-xml is a common module used by other XWiki top level projects. Starting in version 2.7 and prior to versions 12.10.10, 13.4.4, and 13.8-rc-1, it is possible for a script to access any file accessing to the user running XWiki application server with XML External Entity Injection through the XML script service. The problem has been patched in versions 12.10.10, 13.4.4, and 13.8-rc-1. There is no easy workaround for fixing this vulnerability other than upgrading and being careful when giving Script rights.
@@ -19,10 +19,19 @@
*/
package org.xwiki.xml;
import java.io.File;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import org.apache.commons.io.FileUtils;
import org.apache.html.dom.HTMLDocumentImpl;
import org.junit.jupiter.api.Test;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.bootstrap.DOMImplementationRegistry;
import org.w3c.dom.html.HTMLElement;
import org.w3c.dom.ls.DOMImplementationLS;
import org.w3c.dom.ls.LSInput;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertFalse;
@@ -279,4 +288,22 @@ void serializeNode()
serialize = XMLUtils.serialize(node, false);
assertEquals("<HTML><HEAD/><BODY class=\"toto\"/></HTML>", serialize);
}
@Test
void disableExternalEntities()
throws ClassNotFoundException, InstantiationException, IllegalAccessException, ClassCastException, IOException
{
File tempFile = File.createTempFile("file", “.txt”);
FileUtils.write(tempFile, "external", StandardCharsets.UTF_8);
DOMImplementationLS ls =
(DOMImplementationLS) DOMImplementationRegistry.newInstance().getDOMImplementation(“LS 3.0”);
LSInput input = ls.createLSInput();
input.setStringData(“<?xml version=’1.0’ encoding=’UTF-8’?>” + “<!DOCTYPE root[<!ENTITY xxe SYSTEM 'file://”
+ tempFile.getAbsolutePath() + “’ >]><root>&xxe;</root>”);
Document result = XMLUtils.parse(input);
assertNotEquals("external", result.getDocumentElement().getTextContent());
}
}
Related news
### Impact The velocity scripts is not properly sandboxed against using the Java File API to perform read or write operations on the filesystem. Now writing an attacking script in velocity requires the Script rights in XWiki so not all users can use it, and it also requires finding an XWiki API which returns a File. ### Patches The problem has been patched on versions 12.6.7, 12.10.3 and 13.0RC1. ### Workarounds There's no easy workaround for fixing this vulnerability other than upgrading and being careful when giving Script rights. ### References https://jira.xwiki.org/browse/XWIKI-5168 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki](https://jira.xwiki.org) * Email us at [XWiki Security mailing-list](mailto:[email protected])
Zoho ManageEngine Access Manager Plus before 4302, Password Manager Pro before 12007, and PAM360 before 5401 are vulnerable to access-control bypass on a few Rest API URLs (for SSOutAction. SSLAction. LicenseMgr. GetProductDetails. GetDashboard. FetchEvents. and Synchronize) via the ../RestAPI substring.
### Impact It's possible in a script to access any file accessing to the user running XWiki application server with XML External Entity Injection through the XML script service. For example: ``` {{velocity}} #set($xml=$services.get('xml')) #set($xxe_payload = "<?xml version='1.0' encoding='UTF-8'?><!DOCTYPE root[<!ENTITY xxe SYSTEM 'file:///etc/passwd' >]><root><foo>&xxe;</foo></root>") #set($doc=$xml.parse($xxe_payload)) $xml.serialize($doc) {{/velocity}} ``` ### Patches The problem has been patched on versions 12.10.10, 13.4.4 and 13.8RC1. ### Workarounds There's no easy workaround for fixing this vulnerability other than upgrading and being careful when giving Script rights. ### References https://jira.xwiki.org/browse/XWIKI-18946 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki](https://jira.xwiki.org) * Email us at [XWiki Security mailing-list](mailto:[email protected])
Shopware is an open source e-commerce software platform. Versions prior to 5.7.9 are vulnerable to malfunction of cross-site request forgery (CSRF) token validation. Under certain circumstances, the CSRF tokens were not generated anew and not validated correctly. This issue is fixed in version 5.7.9. Users of older versions may attempt to mitigate the vulnerability by using the Shopware security plugin.
The Ericom PowerTerm WebConnect 6.0 login portal can unsafely write an XSS payload from the AppPortal cookie into the page.
Missing authentication for critical function in AssetView prior to Ver.13.2.0 allows a remote unauthenticated attacker with some knowledge on the system configuration to upload a crafted configuration file to the managing server, which may result in the managed clients to execute arbitrary code with the administrative privilege.
**According to the CVSS metric, a successful exploitation could lead to a scope change (S:C). What does this mean for this vulnerability?** This vulnerability could lead to a browser sandbox escape.
cifs-utils through 6.14, with verbose logging, can cause an information leak when a file contains = (equal sign) characters but is not a valid credentials file.
Redis is an in-memory database that persists on disk. Prior to versions 6.2.7 and 7.0.0, an attacker attempting to load a specially crafted Lua script can cause NULL pointer dereference which will result with a crash of the redis-server process. The problem is fixed in Redis versions 7.0.0, 6.2.X and 6.0.X. An additional workaround to mitigate this problem without patching the redis-server executable, if Lua scripting is not being used, is to block access to `SCRIPT LOAD` and `EVAL` commands using ACL rules.