We just got this emailed directly to us. I've seen no chatter on the DSpace list. Is this real or no?
Paul Go Systems Librarian / Library Technology Manager Paul V. Galvin Library Illinois Institute of Technology 35 West 33rd Street Chicago, IL 60616 312.567.7997 [email protected] *Driving Innovation through Knowledge and Scholarship* ---------- Forwarded message ---------- From: DuraSpace Security <[email protected]> Date: Mon, Mar 14, 2016 at 8:47 AM Subject: [URGENT] Major DSpace security vulnerability affecting all XMLUI sites To: DuraSpace Security <[email protected]> Hello, The DSpace Committers team has been notified of a major security vulnerability affecting all sites that use the XMLUI (DSpace versions 1.5.x, 1.6.x, 1.7.x, 1.8.x, 3.x, 4.x and 5.x). JSPUI sites are unaffected by this vulnerability. If exploited, this vulnerability may allow an anonymous user to view any file on your filesystem that is accessible to the Tomcat user account. By default, this may include your dspace.cfg file (and all related DSpace configurations) as well as any operating system files that are readable by the Apache Tomcat user account. The Committers team is working rapidly to patch this vulnerability in the DSpace XMLUI codebase and release security fixes for 3.x, 4.x and 5.x versions. We expect 3.x, 4.x and 5.x security releases (and patches) to be made publicly available on Monday, March 21st. In the meantime, we have quick fixes available at the bottom of this email which will ensure your site is not vulnerable to these attacks. (Please pass them along to the individual who manages your DSpace.) We ask that you please keep this information confidential and avoid posting questions to our public DSpace mailing lists. In order to protect DSpace sites, we will not be disclosing any further details of the vulnerability until the security releases/patches are available. If you have any questions or concerns, we’ve set up a [email protected] email address which can be used to privately contact the DSpace Committers and DuraSpace staff. The quick fix options can be found below. Please apply one of them to your site immediately. Because of the nature of this vulnerability, we also recommend changing any passwords (or secure information) that appear in your DSpace configuration files (e.g. database connection passwords). Sincerely, Tim Donohue (on behalf of the DSpace Committers) Tech Lead for DSpace Quick Fixes for XMLUI Vulnerability We HIGHLY RECOMMEND applying one of the following “quick fixes” to your production site immediately. These quick fixes are designed to block all known attack paths and may be left in place until you are able to upgrade to one of the forthcoming DSpace security releases. Because of the nature of this vulnerability, we also recommend changing any passwords (or secure information) that appear in your DSpace configuration files (e.g. database connection passwords). We have three quick fixes available, based on your local DSpace setup. You only need to choose ONE. - Apache Web Server Quick Fix (for sites that run an Apache Web Server in front of Tomcat) - NGINX Web Server Quick Fix (for sites that run an NGINX Web Server in front of Tomcat) - DSpace XMLUI Sitemap Quick Fix (for sites that simply run Tomcat or another Java servlet container) If you have any questions or concerns about these quick fixes, please email [email protected]. These quick fixes are all considered production-ready, and have already been applied to DSpace sites managed by various DSpace Committers. Option #1: 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 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). Be sure to apply this fix for both HTTP and HTTPS URLs, if your site responds to both. To verify the quick fix is working, visit a URL like: http://[dspace.url]/themes/Reference/test:url (Be sure to test both HTTP and HTTPS). The URL should be redirected to [dspace.url]/error/ and a Page Cannot be Found response returned. As long as this occurs, the quick fix was successful. Option #2: 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 run nginx configtest followed by reload. To verify the quick fix is working, visit a URL like: http://[dspace.url]/themes/Reference/test:url (Be sure to test both HTTP and HTTPS). The URL should be redirected to [dspace.url]/error/ and a Page Cannot be Found response returned. As long as this occurs, the quick fix was successful. Option #3: 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]/webapps/xmlui/sitemap.xmap) and add the following: <!-- Temporary block --> <!-- 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"/> </map:match> <!-- NOTE: the above section should be added just BEFORE this next following section (which exists around line #623-625) --> <!-- handle common theme resources, such as dri2xhtml --> <map:match pattern="themes/*"> <map:read src="themes/{1}"/> </map:match> The change 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). To verify the quick fix is working, visit a URL like: http://[dspace.url]/themes/Reference/test:url (Be sure to test both HTTP and HTTPS). The URL should be redirected to [dspace.url]/error/ and a Page Cannot be Found response returned. As long as this occurs, the quick fix was successful. If you plan to rebuild/redeploy your DSpace in the near future (prior to your next upgrade), you also should ensure this quick fix 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. -- You received this message because you are subscribed to the Google Groups "DSpace Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-community. For more options, visit https://groups.google.com/d/optout.
