I don't have time to try it myself at the moment, but had a short look at the code.

Are you able to download all attachments of all users or just attachments that are attached by the currently logged in user?

No, I can download a file even if the user who uploaded the file is not logged on. As soon as the attacker has access to the issue he may download the attachment, if he guesses the correct file id.

I was not able to reprocue the issue.
What I tried:

• Add to config_inc.php
  $g_download_attachments_threshold = DEVELOPER;
  $g_view_attachments_threshold = DEVELOPER;
• Log in as administrator
• Create private project P1
• Create user U1 and assign him as REPORTER to project P1
• Create issue I1, attach a file
• Log in as user U1 (REPORTER)
• View issue I1 --> I don't see any attachments
• Use URL to download the attachment --> I get access denied

I did not add this to the config_inc.php but added it using Manage->Manage Configuration->Configuration Report. There I inserted two entries:

All Users ProjectXX download_attachments_threshold integer 55
All Users ProjectXX view_attachments_threshold integer 55

Tried now with configuration in database instead of config_inc.php.
Still the same: I am not able to reproduce the issue.

I was wrong when writing:

• Create private project P1

My project was set to "public".

After changing to "private" I get some strange behavior.

I am also not able to reproduce the described behavior. I'm just consistently getting the expected 'Access Denied' page.

@atrol, not sure what you mean by "strange behavior"

@ffuchs, just a thought... was your test conducted on the same PC/browser where you a privileged user previously logged in ? If so it could possibly be a caching issue.

@atrol, not sure what you mean by "strange behavior"

I got the attachment displayed in view.php when beeing logged in as the administrator but got "access denied" when clicking on the download link.

And yes, this was on the same PC/browser

sigh I hate our api

Whilst this might not be the case here:

I'd stab a guess that this could be happening if you have multiple projects, and is why I started on the MantisContext and Bug Objects approach before.

If a user has "Project A" selected (which they have manager access to), and tries to access the file download link for a bug in project B (which they don't have download access to).

This will call file_can_download_bug_attachments:

This then calls:
$t_can_download = access_has_bug_level( config_get( 'download_attachments_threshold' ), $p_bug_id );
$t_can_download = $t_can_download || ( $t_uploaded_by_me && config_get( 'allow_download_own_attachments' ) );

In this case, the config_get command is going to run in the context of "Project A" - it's then going to check access_has_bug_level against the bug id and the context of "Project B"

This is really due to having no "project override set" in file_download.php

However, as the file api's might be called by plugins / other code, the correct fix would be to either:

a) change the parameter type from integer to MantisBug, and then call config_get with MantisBug->project_id

Or

b) leave the parameter type as it is now, and call bug_get(), then pass the project id to the config_Get call

This should be done across the codebase where appropriate.

In file_api.php, it needs to be done in 3 functions:

file_can_delete_bug_attachments
file_can_download_bug_attachments
file_can_view_bug_attachments

Previously, I started going with the approach of passing the object out of bug_get() around to avoid multiple calls to bug_get(), and therefore slowly removing use of 'id', so we always get an accessible bug object.

I can provide you a few additional hints that might help solve the problem. It does not seem to be a caching problem. I used Firefox in privacy mode, closed it and additionally removed all the cookies to be sure. Still the attacker could access the attached file.

All our projects are marked as "private". The attacker has access to more than one project including the one he is able to open the attachments in. He does not see the attachments listed in ProjectXX I mentioned earlier though due to our configuration.

However, we granted the attacker permission so he sees the "issue history". The filename appears in the issue history although he does not see the attachments unless he executes the attack described above. This might be an additional security problem or related to this one.

I tried several private projects based scenarios, as well as the case described by @grangeway, but still I can't reproduce this.

@ffuchs, instead of "hints", it would be much more helpful if you could provide us clear, step-by-step instructions to reproduce this issue, preferably from a fresh install.

The filename appears in the issue history although he does not see the attachments

I agree this is a minor disclosure issue, it can be addressed separately (I opened 0017744 to track this).

I can reproduce the problem at anytime on our system. However, I cannot do a fresh install because we already have more than 10.000 entries in our system because we are using it for six years now. If it is of any help to you I can demonstrate the problem on our system next week via a TeamViewer session.

The following steps should be enough to reproduce it

• Create two private projects P1 and P2
• Set download_attachments_threshold and view_attachments_threshold to 55 for project P2
• Create a user U1 with access level DEVELOPER in project P1 and REPORTER in P2
• Create issue with attachment in project P2
• Login as U1
• Choose P1 in project selection list (where you are DEVELOPER)
• Open URL for file in project P2

Removed some (maybe confusing) information.
User U1 must not be DEVELOPER in project P1.

Steps to reproduce the issue:

• Create two private projects P1 and P2
• Set download_attachments_threshold and view_attachments_threshold to 55 for project P2
• Create user U1 with access level REPORTER in projectd P1 and P2
• Create issue with attachment in project P2
• Login as U1
• Choose P1 in project selection list
• Open URL for file in project P2

As mentioned by grangeway, the problem is that we look at the selected (current) project instead of looking at the project where the issue belongs to.

CVE request http://thread.gmane.org/gmane.comp.security.oss.general/14712