View Issue Details

IDProjectCategoryView StatusLast Update
0026631mantisbtsecuritypublic2020-09-19 10:59
Reporterpolzin Assigned Tovboctor  
Status closedResolutionfixed 
Product Version2.23.0 
Target Version2.24.1Fixed in Version2.24.1 
Summary0026631: file_get_visible_attachments shows private files that should be invisible to the user

2.23.0 allows to upload private and public files, the visibility is stored at the attached bugnote. This is not taken into account in some core functions like file_get_visible_attachment. It is possibly not critical, because I don't know if a user can see the return values somewhere. print_bug_attachment_list uses this function, but the print function seems not to be called directly.

TagsNo tags attached.


related to 0009802 closedvboctor Support attachments associated with private notes 
related to 0027039 closeddregad CVE-2020-25781: Access to private bug note attachments 
has duplicate 0026728 closeddregad file_get_visible_attachments shows private attachments (uploaded with a private bugnote) 
related to 0022323 new Missing whole "Attached Files" section 
related to 0026893 closedvboctor APIs expose private attachments to users who has access to issue but not private notes 




2020-02-04 12:12

reporter   ~0063576

As response to 0022323:0063574 - fits here better:

Don't know what's the intention of the developers.

As reported in 0026627 it seems attachments are always treat public, so they prevent uploading if default note state is private.

If upgrading from an older version attachments don't pinned to a note, also always public visible.



2020-02-04 12:31

reporter   ~0063578

I think, the situation is different:

  1. Starting 2.23 it is possible to add private/public attachments
  2. The function file_get_visible_attachments does not care about that, a security issue. But not critical, as I don't see that the results are printed somewhere (except for patch in 0022323)
  3. Changing the "default_bugnote_view_state" is something that was probably not tested when introducing 1., this lead to a minor bug in 0026627. I don't think that there is special intention behind this.


2020-05-04 15:45

developer   ~0063955

@vboctor no time to check, but isn't this fixed in 2.24.1 by the changes to fix 0026893 ?
If not, target version should be set to 2.25.0.



2020-05-05 00:11

manager   ~0063956

Yes, it is fixed in 2.24.1. @polzin can you please confirm?



2020-05-05 11:33

reporter   ~0063958

I have currently no 2.24.1 installed. I will need some time to check it out, sorry.



2020-05-05 13:40

manager   ~0063959

Closing for now. @polzin please re-open or open a new issue if you had issues with this. I tested this as part of the fix in 2.24.1.