The Synopsys Software Integrity Group is now Black Duck®. Learn More

close search bar

Sorry, not available in this language yet

close language selection

2 path traversal defects in Oracle's JSF2 implementation

Black Duck Editorial Staff

Oct 15, 2013 / 3 min read

Table of Contents

Advisory

From Oracle’s site:

“Developed through the Java Community Process under JSR – 314, JavaServer Faces technology establishes the standard for building server-side user interfaces. With the contributions of the expert group, the JavaServer Faces APIs are being designed so that they can be leveraged by tools that will make web application development even easier.”

Oracle has a reference implementation of JavaServer Faces 2 (JSF2) called Mojarra based upon the JSR 314 specification. JSF2 is a Java web Model-View-Controller (MVC) framework, similar to Spring Web MVC or Struts. Its model is represented by Managed Beans, which is pretty much like JavaBeans. Views generally are written in an XHTML format called a Facelet. However, unlike other web MVCs that use a typical stand-alone controller a la Spring or Struts, JSF2 controllers are actually defined within the view itself.

Newer versions of JSF2 exist:

  • JSF 2.1 is also defined via JSR 314
  • JSR 344 defines JSF 2.2

Coverity SRL discovered two path traversal defects in the Oracle Mojarra 2.0 and 2.1 reference implementations. (The 2.2 implementation was not at a final release at the time of the discovery.) Oracle has released their October 2013 CPU, which they state fixes these two path traversal defects. Oracle has assigned CVE-2013-3827 to these defects. CERT/CC has assigned #VU526012 to the defects described in this advisory and additional defects reported to Oracle.

Background

JSF2 Servlet and Resource Handlers

The JSF2 servlet is javax.faces.webapp.FacesServlet. The servlet is either explicitly defined in web.xml or implicitly injected if certain conditions are met. Refer to the JavaDoc for more information.

The JSF2 Specification, Section 2.6 defines “Resource Handling”. A conformant JSF implementation needs to allow an application developer to access resources defined in the directories listed below, relative to the application root directory.

  • resources/
  • META-INF/resources/

Some resource examples are CSS and JS static files. These could be packaged in the above resource directories as appropriate. A resource is accessible by a resourceIdentifier. The resourceIdentifier is defined in the specification as so:

  • [localePrefix/][libraryName/][libraryVersion/]resourceName[/resourceVersion]

As seen above, resources can specify an option libraryName value, which is prefixed to the resource path.

The javax.faces.application.ResourceHandler class and its helper methods determine if the request is for a resource, and if so, attempt to create and return the resource. It is the responsibility of the JSF2 implementation to perform these calls. ResourceHandler.handleResourceRequest() is the API method that starts the process of responding with a requested resource.

Resource Handler Controls

Since some resources contain potentially sensitive information, certain extensions are excluded by default. An application developer can override these extensions via a context parameter called javax.faces.RESOURCE_EXCLUDES for the JSF2 servlet.

An example entry in web.xml:

<context-param>
<param-name>javax.faces.RESOURCE_EXCLUDES</param-name>
<param-value>.xhtml .class .jsp .jspx .properties</param-value>
</context-param>

Mojarra

Mojarra, Oracle’s reference implementation of JSF2, is freely available and utilized by the following Java web application containers:

  • Glassfish
  • JBoss
  • WebLogic

The com.sun.faces.application.resource.ResourceHandlerImpl class extends the JSF2 ResourceHandler class with methods overriding / implementing the specification. Assuming a JSF application is deployed to the URL http://www.example.com/someApp, the following request will be seen as a resource request:

http://www.example.com/someApp/RESOURCE_ID.JSF_EXTENSION?ln=LIBRARY_NAME

RESOURCE_ID is the requested resourceIdentifier:

  • Needs to start with “javax.faces.resource.”
  • If it looks like a file name, the suffix is used to determine MIME-type mappings.

JSF_EXTENSION is either:

  • Defined via the javax.faces.FACELETS_VIEW_MAPPINGS in web.xml
  • Any url-pattern suffix matches associated to the FacesServlet servlet
  • Or ending in either *.jsf or *.faces if no FacesServlet is defined

LIBRARY_NAME is a directory name used when composing the resourceIdentifier.

The following extensions are excluded by default:

  • .class
  • .jsp
  • .jspx
  • .properties
  • .xhtml
  • .groovy

Defect 1: Partial Path Traversal Via Resource Identifier

A partial path traversal defect exists with the handling of a resource identifier. Mojarra does not check the resource name starting with ../sequence. The defect is somewhat limited in that it cannot be used to escape from the application root and access arbitrary files on the application server.

The following URL can access the WEB-INF/web.xml file assuming the JSF suffix of .jsf is used and .xml is not excluded:

http://www.example.com/someApp/javax.faces.resource.../WEB-INF/web.xml.jsf

A method call is eventually made to com.sun.faces.application.resource.WebappResourceHelper.findResource(LibraryInfo, String, String, boolean, FacesContext)that attempts to load the resource relative to the /resource directory. The resource name of ../WEB-INF/web.xml is then appended to the directory, resulting in a request to /resource/../WEB-INF/web.xml.

Defect 2: Partial Path Traversal Via Library Name

A partial path traversal defect exists with the handling of a library name. Mojarra does not check the library name for the sequence ... The defect is somewhat limited in that it cannot be used to escape from the application root and access arbitrary files on the application server.

The following URL can access the WEB-INF/web.xml file assuming the JSF suffix of .jsf is used and .xml is not excluded:

http://www.example.com/someApp/javax.faces.resource./WEB-INF/web.xml.jsf?ln=..

Mojarra does attempt to filter out malicious path traversal characters via a method check atcom.sun.faces.application.resource.ResourceManager.libraryNameContainsForbiddenSequence(String). However, the sequence .. is not checked and also returns a directory, which is required in the application. A method call is made to com.sun.faces.application.resource.WebappResourceHelper.findResource(LibraryInfo, String, String, boolean, FacesContext)that attempts to load the resource using the path of /resource/.., concatenated with /, concatenated with the trimmed resource name of WEB-INF/web.xml, resulting in a request to /resource/../WEB-INF/web.xml.

Thanks

Coverity SRL used CERT/CC for this disclosure. Coverity SRL thanks CERT/CC for shepherding this disclosure with Oracle.

Updates

  • Oct 17 2013: Updated CVE to correct version and removed miscredited section
  • Oct 18 2013: Added CERT/CC link.

Continue Reading

Explore Topics