Hello

Many thanks for the detailed bug report. I will look into it and let you know when a fix is available for testing.

Have you reserved a CVE for this, or should I do it ?

Hi,

No, I didn't reserve a CVE, you can do it. Let me know if you have any questions.

Pier-Luc

I just had a quick look at the code, and I reckon this vulnerability would only affect MantisBT instances relying on the default mechanism to determine the server path [1].

I'm not so keen on using SERVER_NAME only as that may not work in all situations since it is dependent on the web server's setup.

Maybe a better approach would be to get rid of the unsafe use of HTTP_HOST in the detection mechanism or trigger a warning if it's being used, and let the admin set the (canonical) path in config_inc.php. Another option would be to introduce a new setting to validate the path (similar to what Drupal did), but maybe that's overkill.

I need to think some more about this.

[1] https://github.com/mantisbt/mantisbt/blob/master/config_defaults_inc.php#L176

No time for tests, thus just some thoughts.

We could completely remove access of $_SERVER['HTTP_HOST'] in master 1.3.x, and wait for
feedback of users.
Another option for 1.3.x is to change order of the $t_host assignment, set a global
variable if $_SERVER['HTTP_HOST'] is used, check for the variable in admin/check and
login_page.php (if $g_admin_checks is set) and provide a warning if the variable is set.

$g_http_host_used = false;

if( isset( $_SERVER['HTTP_X_FORWARDED_HOST'] ) ) { # Support ProxyPass

$t_hosts = explode( ',', $_SERVER['HTTP_X_FORWARDED_HOST'] );

$t_host = $t_hosts[0];

} else if( isset( $_SERVER['SERVER_NAME'] ) ) {

$t_host = $_SERVER['SERVER_NAME'] . $t_port;

} else if( isset( $_SERVER['SERVER_ADDR'] ) ) {

$t_host = $_SERVER['SERVER_ADDR'] . $t_port;

} else if( isset( $_SERVER['HTTP_HOST'] ) ) {

$t_host = $_SERVER['HTTP_HOST'];

$g_http_host_used = true;

}

Furthermore we would have to describe the configuration of the web server in this case and
describe also the right setting for $g_path in config_inc.php if configuration of the web
server is not possible or does not work.

Not sure if we could do the same for 1.2.x and risk breaking existing installations.
Especially because we are hardly able to test all possible combinations of supported
PHP versions and different web servers and versions.

Every kind of potentially breaking change would have to be described in installation/upgrade
guide and would have to be part of the release announcement of 1.2.20.

BTW, I found that the code block in master starting with
if( !isset( $_SERVER['SCRIPT_NAME'] )) {
https://github.com/mantisbt/mantisbt/blame/master/config_defaults_inc.php#L187
is dead code.
It's in a block that starts with
if( isset ( $_SERVER['SCRIPT_NAME'] ) ) {

If the MantisBT host is compromised, why would the evil code just go change the database rather than this round about way? Am I missing something?

@vboctor

The MantisBT host is not compromised.

The issue is that we rely on the client-provided HTTP_HOST to build $g_path, allowing an attacker to initiate a password reset process for any user for which they know the id and password, and by inserting "evil.com" instead of "mantisbt.org", the e-mail we send to the user will point them back to "evil.com" thus letting the attacker retrieve the verification key and using it to hijack the user's account.

Obviously this requires the user to actually click the link without verifying it.

@atrol

Thanks for your feedback. Your suggestion goes along the lines of what I was thinking.

Good catch also with the dead code block.

@Pier-Luc

You mentioned a blog in your forum post [1], does that need to be referenced in the CVE ? If so please provide the URL.

One more question, about the use of HTTP_X_FORWARDED_HOST - I have not actually tested this, but would assume that this can be spoofed in the same way you described above, right ?

[1] https://www.mantisbt.org/forums/viewtopic.php?f=2&t=22938

I did a quick test on my installation, without actually using a proxy. I added the X-Forwarded-Host header line in the request :

POST /mantisbt/lost_pwd.php HTTP/1.1
Host: 192.168.101.90
X-Forwarded-Host: evil.com
[...]

and the link was poisonned with evil.com.

For the blog, you can provide this URL: plmsecurity.net (there is nothing on there yet).

Hi, I just want to remind you that we are two weeks from my 3 months deadline. Did you guys have planned a patch for this issue?

Thanks for the reminder, this kind of fell off the radar...

We reach the deadline. Please tell me if you have something planned.

Well I have a potential patch but did not fully test it yet (sorry, I do this in my spare time, and I unfortunately don't have much of that nowadays). We need to consider backwards compatibility before releasing anything, which makes fixing this not so trivial.

If I may make a comment, it would have been nice(r) to announce this deadline of yours up front. That being said, what are your plans moving forward - assuming we're not able to release a fix shortly ?

I was clear with the 90 days deadline on my original post on the forum (https://www.mantisbt.org/forums/viewtopic.php?f=2&t=22938), but maybe I should have stated it here too.

I really don't want to go full disclosure. If I give you two more weeks, will you be able to release a patch? If not, I will relase the advisory on my blog, post it on exploit-db, share it on twitter, etc.

This vulnerability put your users informations at risk and it is your responsability to mitigate that risk, even if it's done in your spare time.

maybe I should have stated it here too

Indeed.

it is your responsability to mitigate that risk

I know damn well what my responsibilities are. For the record, it is also my responsibility to take care of my family, and do the job my employer pays me for. It's all a question of priorities...

Using open-source software implies accepting some risks, and an unpatched vulnerability is one of them.

That being said and despite appearances, I do take security issues very seriously, and will do my best to get this patch out within 2 weeks. Will let you know when the patch is ready so you can confirm whether it actually fixes the issue or not before I release it to the general public.

GitHub security advisory: https://github.com/mantisbt/mantisbt/security/advisories/GHSA-mcqj-7p29-9528

CVE-2024-23830 assigned on 29-Jan-2024.

Patch is available for review at https://github.com/mantisbt/mantisbt-ghsa-mcqj-7p29-9528/pull/1

Feedback welcome. Please get in touch with me if you have problems accessing.

@dregad as an additional enhancement (must not be part of this fix), should we write $g_path and $g_short_path to config_inc.php when running a new installation?

That's an idea.

I suppose you mean to achieve that by requesting the path to use at install time, with a proposed default value based on the logic I moved from config_defaults_inc.php to set_default_path() function in core.php ?

Exactly like that.

@atrol please review https://github.com/mantisbt/mantisbt-ghsa-mcqj-7p29-9528/pull/2 which implements your suggestion 0019381:0068521

Pull requests from temporary fork have been merged, and the advisory published
https://github.com/mantisbt/mantisbt/security/advisories/GHSA-mcqj-7p29-9528.