Information disclosure from share

Description

By design, share serves up resources to unauthenticated from any META-INF directory on the classpath. For example:

curl https://your-alfresco-site/share/res/maven/org.alfresco/alfresco-core/pom.properties

  1. gives you back the pom properties

It is an open source project so all of the out of the box information is available to any member of the public anyway, however it's possible that a jar might include files in META-INF that are sensitive and these would be served up. For example, I might have a jar in my tomcat/common classpath that, unintentionally or otherwise, contains credentials of some kind. All an attacker needs to do is try some standard names for config files and they have it, e.g.:

curl https://your-alfresco-site/share/res/db.properties

The servlet 3.0 does something like this as well, but it at least restricts it to a subpath under META-INF.

I've also seen that there seems to be a bunch of patterns you can configure to deny access, but the OOTB is quite permissive.

Environment

None

Testcase ID

None

Activity

Show:
All Replies
October 31, 2020, 12:48 AM

[This issue has been reassigned to allreplies@alfresco.com as part of the Alfresco cloud migration project. The reporter of this issue was nickg.catalyst]

All Replies
September 22, 2016, 5:49 PM

[This comment has been reassigned to allreplies@alfresco.com as part of the Alfresco cloud migration project. The author of this comment was resplin] Maybe this is a configuration that should be addressed in a reference architecture? Should there be a DOCS issue for this configuration?

All Replies
July 11, 2016, 9:50 PM

[This comment has been reassigned to allreplies@alfresco.com as part of the Alfresco cloud migration project. The author of this comment was nickg.catalyst] Also, I think you're haproxy config won't fix it - the WEB-INF part is safe, it's any resource in any jar under META-INF. so blocking WEB-INF paths (or META-INF for that matter) at the web proxy won't do anything. Have another look at the URL in my description if you're unsure what I mean.

The share deny-access-resource-paths would need to change, too. IIRC, that could works on a url-path basis, not a file-system one, so it sees it just like. You would need to explicitly white-list of black-list particular patterns, so ...

Given that share relies on being able to access files with a .properties extension, I don't see how you could control access to those effectively with a blacklist.

All Replies
July 11, 2016, 9:27 PM

[This comment has been reassigned to allreplies@alfresco.com as part of the Alfresco cloud migration project. The author of this comment was nickg.catalyst] I'm aware that there are workarounds, but I thought the default was surprising and insecure.

All Replies
July 11, 2016, 12:18 PM

[This comment has been reassigned to allreplies@alfresco.com as part of the Alfresco cloud migration project. The author of this comment was kroast] A simple proxy config can be used to mitigate the issue immediately:
For example in haproxy:

and similar for Apache would be simple.

Configuration is also already available in Share to hide specific folders from the resource locator as needed:

We do not see a need to change the default at this time. Thanks for your report!

Fixed
Your pinned fields
Click on the next to a field label to start pinning.

Assignee

All Replies

Reporter

All Replies

Security Severity

Low