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
July 11, 2016, 10: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!

All Replies
July 12, 2016, 7:27 AM

[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 12, 2016, 7:50 AM

[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
September 23, 2016, 3:49 AM

[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
October 31, 2020, 11: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]

Fixed

Assignee

All Replies

Reporter

All Replies

Labels

None

Security Severity

Low

Patch Attached

None

Sprint Number

None

Documentation required

None

Documentation Impact

None

Resource

None

Regression

None

Escalation level

None

Triage

None

Release Train

None

Delivery Team

None

Time remaining

0m

Components

Fix versions

Affects versions

Priority

Unprioritized