AFAIK, this has been fixed in later versions of Undertow and WildFly. Have you tried this against the latest versions?

Either way, mentioning swd847 just in case this still is an issue.

Hi Jaikiran,

Thanks a lot for your answer.

I'm going to perform the test on a more recent version.

Hi Jaikiran and swd847,

I have done some tests with Wildfly 11 and I get the same issue. I can get files of my VM that are outside of my web application in the http response.

The code related to the two "strange" behaviors I found is still present in Wildfly 11.

Best regards,

Laurent

The first issue is resolved, see UNDERTOW-666 servlet forward can access filesystem outside base path · undertow-io/undertow@432f062 · GitHub  .

Looking at the code it seems like ALLOW_ENCODED_SLASH might still be an issue for the AJP parser, can you file an Undertow JIRA?

lroussel35  wrote:

 

 

 

I have done some tests with Wildfly 11 and I get the same issue. I can get files of my VM that are outside of my web application in the http response.

 

The code related to the two "strange" behaviors I found is still present in Wildfly 11.

 

Is this reproducible only when AJP is involved? How do you fire off those requests, using curl? Finally, you are sure this is WildFly 11? I tried reproducing this and haven't been able to so far.

Hi jaikiran and swd847

And thank you for your answers.

Ok I'm going to create a dedicated Jira for the AJP Parser.

Concerning the first issue I mentionned, I think it's a different problem than the one described in UNDERTOW-666. The classes involved to get the resource requested seems to be different. I confirmed that the tests have well been done on Wildfly 11.

When I debug the source code, it's the following stack that provides the resource:

    ServletResourceManager.getResource(String) line: 80 

    CachingResourceManager.getResource(String) line: 114 

    CachingResourceManager.getResource(String) line: 32 

    ServletContextImpl.getResourceAsStream(String) line: 307 

    ServletContextResource.getInputStream() line: 139   

    ResourceHttpRequestHandler.writeContent(HttpServletResponse, Resource) line: 384 

    ResourceHttpRequestHandler.handleRequest(HttpServletRequest, HttpServletResponse) line: 160 

    HttpRequestHandlerAdapter.handle(HttpServletRequest, HttpServletResponse, Object) line: 51

    DispatcherServlet.doDispatch(HttpServletRequest, HttpServletResponse) line: 938 

    DispatcherServlet.doService(HttpServletRequest, HttpServletResponse) line: 870

    DispatcherServlet(FrameworkServlet).processRequest(HttpServletRequest, HttpServletResponse) line: 961

    DispatcherServlet(FrameworkServlet).doGet(HttpServletRequest, HttpServletResponse) line: 852 

And the problem seems to be  localised in the method org.wildfly.extension.undertow.deployment.ServletResourceManager.getResource.

    @Override

    public Resource getResource(final String path) throws IOException {

        Resource res = deploymentResourceManager.getResource(path);

        if (res != null) {

            return new ServletResource(this, res);

        }

        String p = path;

        if (p.startsWith("/")) {

            p = p.substring(1);

        }

        if (overlays != null) {

            for (VirtualFile overlay : overlays) {

                VirtualFile child = overlay.getChild(p);

                if (child.exists()) {

                    return new ServletResource(this, new VirtualFileResource(overlay.getPhysicalFile(), child, path));

                }

            }

        }

        for (int i = 0; i < externalOverlays.length; ++i) {

            ResourceManager manager = externalOverlays[i];

            res = manager.getResource(path);

            if(res != null) {

                return res;

            }

        }

        return null;

    }

In my case, there is an overlay (/content/secu-1.0.0-SNAPSHOT.war/WEB-INF/lib/springfox-swagger-ui-2.2.2.jar/META-INF/)   and  it's the virtual file corresponding to the overlay that provides the file of the resource specified in the url.

I send you the code source to reproduce the issue.

To facilitate the reproduction, I have activated the option ALLOW_ENCODED_SLASH on the http connector.

In my environment, with the request  http://<hostname>:8080/secu-1.0.0-SNAPSHOT/..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/etc/passwd, I get the /etc/passwd file of the VM.

Best regards,

Laurent

Hello,

I am a security manager and our team has focused on this item/subject.

We lead a study based on the "Proof Of Concept" sent in last exchange (secu.zip from Laurent Roussel) and it seems to be averate. I push you our summary about this weakness.

How is it possible to push this subject quickly ? (jaikiran, swd847, redhat assistance ?)

VULNERABILITY MANAGEMENT :

RISK :

Breach of data confidentiality

AFFECTED SYSTEM :

Wildfly  : all versions (undertow) ?

SUMMARY :

A team has discovered a "Path traversal" security weakness on Wildfly application servers. This vulnerability is related to an application server vulnerability that allows access to static files stored outside the application context of the web application.

By manipulating URLs that reference files with “dot-dot-slash (../)” sequences and its variations, it may be possible to access arbitrary files stored on file system including application source code or configuration and critical system files. This vulnerability of the component "ServletResourceManager" is exploitable thanks to a too permissive implementation of AJP connector (component AjpRequestParser) which interprets the characters slash / anti-slash encoded in the url.

SOLUTION :

It seems that no security patch is released to date. Could you confirm or make recommandations ?

TEMPORARY BYPASS :

The team advocates:

• Problem remediation :
  • use the http connector of the wildfly application server instead of the AJP connector. The http connector is implemented with protection for this type of request.
  • without correcting the vulnerability, using spring MVC (version 4.3 or 5.x) to access the resources prevents exploiting the vulnerability.
• Mitigation :
  • check the presence of an application firewall as well as the configuration of the path traversal rules
  • limit the application server launch rights as much as possible and verify the rights applied to the files on the application server. An OS hardening operation of this type will limit impacts in case of exploitation.

lapsang, thank you for the detailed explanation. Can you please follow the steps noted here Security Contacts and Procedures - Red Hat Customer Portal  to take this further?

Fix was already committed to undertow as well as included in WildFly.