Status: Closed (View Workflow)
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
Environment:Any XMLUI site
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.
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.
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:
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).
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:
Then nginx configtest followed by reload
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:
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.
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-2445patch 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.
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.
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.