View Issue Details

IDProjectCategoryView StatusLast Update
0026631mantisbtsecuritypublic2020-05-05 13:40
Reporterpolzin Assigned Tovboctor  
PrioritynormalSeverityminorReproducibilitysometimes
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
Description

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.

Relationships

related to 0009802 closedvboctor Support attachments associated with private notes 
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 

Activities

ciwu

ciwu

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.

polzin

polzin

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.
atrol

atrol

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.

vboctor

vboctor

2020-05-05 00:11

manager   ~0063956

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

polzin

polzin

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.

vboctor

vboctor

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.

Issue History

Date Modified Username Field Change
2020-01-27 14:17 polzin New Issue
2020-02-04 12:12 ciwu Note Added: 0063576
2020-02-04 12:31 polzin Note Added: 0063578
2020-02-21 06:40 dregad Relationship added has duplicate 0026728
2020-02-21 06:40 dregad Relationship added related to 0022323
2020-02-21 06:41 dregad Relationship added related to 0009802
2020-04-20 01:46 atrol Relationship added related to 0026893
2020-04-20 01:54 vboctor Assigned To => vboctor
2020-04-20 01:54 vboctor Status new => assigned
2020-04-20 01:54 vboctor Target Version => 2.24.1
2020-05-04 15:45 atrol Note Added: 0063955
2020-05-05 00:11 vboctor Status assigned => feedback
2020-05-05 00:11 vboctor Note Added: 0063956
2020-05-05 11:33 polzin Note Added: 0063958
2020-05-05 11:33 polzin Status feedback => assigned
2020-05-05 13:40 vboctor Status assigned => closed
2020-05-05 13:40 vboctor Resolution open => fixed
2020-05-05 13:40 vboctor Fixed in Version => 2.24.1
2020-05-05 13:40 vboctor Note Added: 0063959