Important security alert

[jpotts]

Included in Alfresco 4.0.1 Enterprise is a fix for two critical security issues. The two issues are:

• SOLR REST API allows unauthenticated access to repository contents (ALF-13721) (Affects 4.0)


• Remote code execution possible via Web Script XSLT Processor (ALF-13726) (Affects all versions)

If you are an Enterprise Edition user, you have already been notified of these issues and what to do to address them. Both issues are fixed in 4.0.1. There is a hotfix available for 4.0.

If you are an Enterprise Edition user on 3.4, the XSLT fix will be in 3.4.9. A hotfix is available for 3.4.8.

For Community Edition users, you'll see the fix in the next Community drop. Until then, here is some additional information in case you need to address the issues.

SOLR REST API allows unauthenticated access to repository contents

An omission has been discovered that meant that HTTP access to repository APIs under the paths /alfresco/s/api/solr, /alfresco/wcservice/api/solr and /alfresco/wcs/api/solr were not protected by SOLR’s SSL certificate and could potentially be used by an unauthenticated user to retrieve information from the repository. This issue affects you whether or not you have configured and installed SOLR for search.

The issue is easily addressed by adding some XML to your web.xml. If you take a look at the web.xml file, you'll see a security-constraint element that matches on the "/service/api/solr" pattern. The issue is that the web script is accessible via several other patterns not covered by existing security constraints.

<security-constraint>
      <web-resource-collection>
         <web-resource-name>SOLR</web-resource-name>
         <url-pattern>/service/api/solr/*</url-pattern>
      </web-resource-collection>

      <auth-constraint>
         <role-name>repoclient</role-name>
      </auth-constraint>

      <user-data-constraint>
         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
   </security-constraint>‍‍‍‍‍‍‍‍‍‍‍‍‍‍

You can plug the hole yourself by adding the following additional security constraints:

<security-constraint>
      <web-resource-collection>
         <web-resource-name>SOLR</web-resource-name>
         <url-pattern>/s/api/solr/*</url-pattern>
      </web-resource-collection>

      <auth-constraint>
         <role-name>repoclient</role-name>
      </auth-constraint>

      <user-data-constraint>
         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
   </security-constraint>

   <security-constraint>
      <web-resource-collection>
         <web-resource-name>SOLR</web-resource-name>
         <url-pattern>/wcservice/api/solr/*</url-pattern>
      </web-resource-collection>

      <auth-constraint>
         <role-name>repoclient</role-name>
      </auth-constraint>

      <user-data-constraint>
         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
   </security-constraint>

   <security-constraint>
      <web-resource-collection>
         <web-resource-name>SOLR</web-resource-name>
         <url-pattern>/wcs/api/solr/*</url-pattern>
      </web-resource-collection>

      <auth-constraint>
         <role-name>repoclient</role-name>
      </auth-constraint>

      <user-data-constraint>
         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
   </security-constraint>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Remote code execution possible via Web Script XSLT Processor

Alfresco’s XSLT processor previously allowed XSLT templates used by web scripts and Web Forms to make use of the Apache Xalan extensions feature to call arbitrary Java methods. This could be exploited as a security hole by anyone with permissions to upload a webscript or XSLT template. We now prevent the use of any extension namespaces besides the preconfigured Alfresco 'alf' namespace.

With the fix in place, the Xalan extensions cannot call arbitrary methods because the only extensions allowed are Alfresco's. If you need to call your own Java code through a Xalan extension, you can still configure the XSLT processor to do that.

The code that implements this fix is in the Jira. This should allow you to patch the JAR if you cannot wait for the next Community Edition drop.

Jeff

[lotharmärkle]

Thank you to direct attention to this issue and for providing an instant fix!

For the XSLT issue, it is maybe possible to disable XSLT if this functionality is not required or while the patch is being prepared:

For 4.0d Community Edition place a file security-fixes-context.xml into /shared/classes/alfresco/extension containing:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'>
<beans>
  <!– override xslt beans to disable xslt processing –>
  <!– https://forums.alfresco.com/en/viewtopic.php?f=2&t=44384 –>
  <!– https://issues.alfresco.com/jira/browse/ALF-13726 –>
  <bean id="xsltRenderingEngine" class="java.lang.String"/>
  <bean id="xsltFunctions" class="java.lang.String"/>
  <bean id="xsltProcessor" class="java.lang.String"/>
</beans>

Regards,
  lothar