Uploaded image for project: 'DSpace (LEGACY)'
  1. DSpace (LEGACY)
  2. DS-3094

XMLUI Directory Traversal Vulnerability in Themes



    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1, 1.7.2, 1.7.3, 1.8.0, 1.8.1, 1.8.2, 1.8.3, 3.0, 3.1, 3.2, 3.3, 3.4 , 3.5, 4.0, 4.1, 4.2, 4.3, 4.4, 5.0, 5.1, 5.2, 5.3, 5.4
    • Fix Version/s: 3.6, 4.5, 5.5, 6.0
    • Component/s: XMLUI
    • Labels:
    • Environment:
      Any XMLUI site
    • Attachments:
    • Comments:
    • Documentation Status:


      What is the problem? Who is affected?

      This XMLUI directory traversal bug is a variation on DS-2445. It was discovered by Virginia Tech (Keith Gilbertson and others).

      Vulnerability - Severity: HIGH The XMLUI "themes/" path is vulnerable to a full directory traversal using [any-two-or-more-chars]:[any-full-file-path]. This means that ANY files on your system which are readable to the Tomcat user account may be publicly accessed via your DSpace website. This vulnerability has existed since 1.5.x (when XMLUI was introduced). All DSpace XMLUI sites are affected, unless you've previously blocked such URL hacks.

      To see if you are affected, paste the following on the end of your DSpace URL (if vulnerable, you will see your filesystem's "/etc/passwd" file). If affected, similar URL pattern(s) would allow for access to any other file accessible to the Tomcat user account on your filesystem.

      The URL pattern that displays this vulnerability is:

      Some examples (for Linux / Mac OSX backends) include:
      [dspace.url]/themes/Reference/ac%3Aetc/passwd (Note %3A is an encoded colon)

      • NOTE #1: The name of the XMLUI theme doesn't matter, it could be Mirage2, Mirage, Reference, Kubrick, Classic, or a custom theme name.
      • NOTE #2: If you are hosting your DSpace on Windows, the /etc/passwd file won't exist. So you may wish to try a different, known path like C:/Windows/System32/CRYPT32.DLL or any other file that is readable by the user that Tomcat runs as.

      What is the fix?

      Temporary / Quick Fix (can be applied without rebuild or restart of DSpace)

      We have a variety of quick fixes available below, based on whether you are using Apache (in front of Tomcat), NGINX (again in front of Tomcat), or just Tomcat. All Quick fixes can be applied immediately to your site (without restarting it), and will block this vulnerability from occurring until you can upgrade or patch your site (see "Permanent Fix" details below). You only need to choose ONE quick fix.

      Apache Web Server Quick Fix

      For any sites that use Apache in front of Tomcat, you can block all affected URLs at the Apache level using "mod_rewrite". This does not actually fix the problem in DSpace, but it does block access to the vulnerable URLs (until you are able to upgrade). For example:

      # Temporary block for DS-3094 (for sites using Apache + mod_rewrite)
      # This redirects all vulnerable URLs to /error (which doesn't exist and throws a 404 response)
      RewriteEngine On
      RewriteRule ^/+themes/.*:.*$ /error [R=permanent,L]
      # If your DSpace XMLUI URL starts with "/xmlui", you should use this instead:
      # RewriteRule ^/+xmlui/+themes/.*:.*$ /xmlui/error [R=permanent,L]

      After putting these rules in place, you should be able to simply reload Apache to apply these changes to your site (e.g. sudo service apache2 reload).

      NGINX Web Server Quick Fix

      For any sites that use NGINX in front of Tomcat, you can block all affected URLs from NGINX. This does not actually fix the problem in DSpace, but it does block access to the vulnerable URLs (until you are able to upgrade). Add this to your server or location directive:

      rewrite ^/+themes/.*:.*$ /error permanent;
      # If your DSpace XMLUI URL starts with "/xmlui", you should use this instead:
      # rewrite ^/+xmlui/+themes/.*:.*$ /xmlui/error permanent;

      Then nginx configtest followed by reload

      XMLUI Root Sitemap Quick Fix

      If you are NOT using Apache or NGINX, it is also possible to block all affected URLs within the DSpace XMLUI root sitemap itself. Similar to the above fixes, this can be done while the DSpace site is up-and-running.

      Simply find the root sitemap (usually at [dspace.url]/webapps/xmlui/sitemap.xmap) and add the following:

      <!-- Temporary block for DS-3094. -->
      <!-- Internally redirect all vulnerable URLs to /error (which doesn't exist and throws a 404) -->
      <map:match pattern="themes/**:**">
           <map:redirect-to uri="{request:contextPath}/error" permanent="yes"/>
      <!-- NOTE: the above section should be added just BEFORE the following section (which exists already around line #623-625) -->
      <!-- handle common theme resources, such as dri2xhtml -->
      <map:match pattern="themes/*">
          <map:read src="themes/{1}"/>

      The redirect will take effect immediately. Any of the vulnerable URLs will be redirected to "/error" (which doesn't exist in DSpace, and will cause DSpace to simply return a 404 Page Not Found error). If you plan to rebuild/redeploy your DSpace in the near future (prior to your next upgrade), you also should ensure this redirect is copied into your source code at [dspace-src]/dspace-xmlui/src/main/webapp/sitemap.xmap (or [dspace-src]/dspace/modules/xmlui/src/main/webapp/sitemap.xmap if you are using overlays). . That way any future rebuilds and redeploys do not accidentally overwrite these changes.

      Permanent Fix (requires patching code & rebuilding / restarting DSpace)

      Based on the version of DSpace you are running (3.x, 4.x or 5.x), apply the appropriate patch file to your DSpace source code (dspace-src), rebuild and redeploy DSpace. If you do not wish to apply the patches manually, you may instead chose to apply one of the above "Temporary / Quick fixes" and wait to upgrade to DSpace versions 3.6, 4.5 or 5.5.

      • DSpace 5.x users should apply the attached "DS-3094-5x.patch" OR upgrade to DSpace 5.5.
      • DSpace 4.x users should apply the attached "DS-3094-3x-or-4x.patch" OR upgrade to DSpace 4.5
      • DSpace 3.x users should apply the attached "DS-3094-3x-or-4x.patch" OR upgrade to DSpace 3.6
      • DSpace 1.x.x users are highly encouraged to upgrade to the latest version of 3.x, 4.x or 5.x. The "DS-3094-3x-or-4x.patch" should also work for 1.x.x sites (untested), as long as you've also previously applied the patch for DS-2445. You may also consider simply applying one of the "quick fixes" above until you are able to upgrade.

      Hints on applying the patches:

      • Applying the patch on Linux is usually just: cd [dspace-src]; patch -p1 < [path-of-patchfile]
      • If you are using Git, you can also simply run: cd [dspace-src]; git apply [path-of-patchfile]
      • NOTE: If the SafeResourceReader does not exist in your source code, then make sure to FIRST apply the patch for DS-2445 (which resolves other XMLUI security issues by creating the SafeResourceReader). The SafeResourceReader MUST exist before you can apply any of the above patches. This means you need to either be running v3.4 - 3.5, v4.3 - 4.4, or v5.1 - 5.4 OR you must manually apply the DS-2445 patch first.

      This patch resolves the vulnerability in our custom Cocoon SafeResourceReader by ensuring it doesn't accept URLs that include a colon (:) or an escaped colon (%3a). It also creates a new default "whitelist" of valid file extensions for all XMLUI themes. By default this whitelist includes common web formats, but it can be customized via a new, optional xmlui.theme.whitelist setting in your dspace.cfg.

      Once you've applied the permanent fix, you can remove any of the "Quick Fix" changes (listed above) as they will no longer be necessary.

      How can I tell if I've been exploited? What other steps should I take?

      If you are using Apache in front of Tomcat, you should be able to query your Apache logs to look for exploits that match the vulnerable pattern. Here's some sample greps of Apache logs (often in /var/log/apache2 on Linux machines). You may need to tweak these grep statements based on the format or name of your Apache logs.

      # First search recent Apache access logs
      # Grep the logs for the query “GET .*/themes/[^/]\+/[[:alpha:]]*:”. On a linux based system this can be done through:
      # This assumes your Apaceh access logs are either under /var/log/apache/ or /var/log/httpd/
      grep "GET .*/themes/[^/]\+/[[:alpha:]]*:" /var/log/apache*/*access*log* /var/log/httpd/*access*log*
      # Then, check any gzipped Apache access logs (assuming you gzip old logs to save space)
      zgrep "GET .*/themes/[^/]\+/[[:alpha:]]*:" /var/log/apache*/*access*log*.gz /var/log/httpd/*access*log*.gz

      NOTE: Unfortunately, there is no way to check for these exploits in the default Tomcat logs. Thus far, we have no confirmed instances of this vulnerability being exploited in any DSpace sites. However, because of the difficulty in tracking this at the Tomcat level and the number of versions this affects, it is possible this vulnerability could have been exploited in some sites.

      Whether or not you've been exploited, you may wish to change your underlying database password (or any other passwords or secure information stored in your dspace.cfg file). It is possible that someone could read your dspace.cfg if they were able to figure out or guess the full path of that configuration file. The same is true for any other configuration file that is readable by the Tomcat user on your system.


        1. DS-3094-3x-or-4x.patch
          9 kB
        2. DS-3094-5x.patch
          11 kB
        3. DS-3094-master.patch
          11 kB

          Issue Links



              tdonohue Tim Donohue
              tdonohue Tim Donohue
              0 Vote for this issue
              12 Start watching this issue