PR_CSO,

I was not able to reproduce your problem with a fresh install of 2.25.7. (used two private projects and a new user with reporter access level)
Please provide detailed step-by-step instructions to reproduce the issue.

As a side note, I set the "View Status" of the issue to "private", so there is no need to set your notes to private as long as they do not contain private information.
Please always report security issues as private, following our guidelines https://mantisbt.org/wiki/doku.php/mantisbt:handling_security_problems

Do you have an account with "Administrator" rights?
Do you have access to the file system of the installation?

Project Access Level reporter

So you have access to the project?
Befor that, you wrote in the description

but without permissions on any project

Without having a reproducible workflow that starts from a fresh installation of MantisBT 2.25.7, there is hardly a chance to find out what is going on.

You need administrative access to the affected installation and access to the file system (maybe also to the database) to check all configuration options, project and user settings.
Based on that, you could try to configure the same on a fresh install and to reproduce.

The customer declared that the version is mantisbt-2.25.7 is there any easy way to verify this information? (I can't see any banner)

If the REST API is enabled, you can try to access an endpoint and look for the X-Mantis-Version header.

As a side note (and potential information disclosure issue, to follow-up separately), I don't think this header should be set if $g_show_version is OFF, which I guess is the case in your instance otherwise you would see Powered by MantisBT [version] at the bottom of the page.

Request:
GET /mantisbt/api/rest/ HTTP/1.1

Response:
HTTP/1.1 401 API token required
Date: Mon, 02 Oct 2023 07:24:47 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips PHP/7.2.34
X-Powered-By: PHP/7.2.34
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Last-Modified: Tue, 11 Apr 2023 22:55:08 GMT
X-Mantis-Version: 2.25.7
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8

I already requested to have the "bug_revision_view_page.php" file from the installation, but I guess it would be the right one.
From the github I see that an authorization check was placed in the past https://github.com/mantisbt/mantisbt/commit/e9fd168c519a46c2cd0f3cb835e9ce5dba77fc4d but probably with the specific permission setup, the check fails somewhere.
What I can do is to propose a call with a person from the end customer who has privileged access to the mantisbt instance so that he can answer your questions or show you the configurations/permissions.

P.S.
Rest API seems to be disabled, but the version is anyway gathered.
Sending API keys:
HTTP/1.1 503 API disabled
Date: Mon, 02 Oct 2023 07:32:34 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.2k-fips PHP/7.2.34
X-Powered-By: PHP/7.2.34
Set-Cookie: PHPSESSID=il9pk5ipu6ni8of76icouggh1d; path=/; secure; HttpOnly
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Last-Modified: Tue, 11 Apr 2023 22:55:08 GMT
X-Mantis-Username: Pentest_2023
X-Mantis-LoginMethod: api-token
X-Mantis-Version: 2.25.7
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8

Some more evidences retrieved from the end user.

mantis-001.png (11,607 bytes)   

mantis-001.png (11,607 bytes)   

mantis-002.png (28,049 bytes)   

mantis-002.png (28,049 bytes)   

Thanks for confirming the version, but as atrol explained (0032980:0068149), the problem you describe is not reproducible.
In the conditions described (i.e. reporter user with no permission on any project), we just get an access denied error as expected.

I got the file retrieved from the installation, and it has the "# Make sure user is allowed to view revisions" block, so should be the right version.

The end user is available for a Teams meet today from 14 to 15 CEST (UTC+2)
Let me know if you are available, otherwise I'll ask to have a couple of options for next week.

I had a call with the end user and we noticed that the vulnerability seems to be only on projects with "obsolete" state and not if the state is "development".
I guess that something changes on the authorization checks, based on the project state.
I hope that this is why you didn't reproduced the bug.

Please let me know, otherwise I'll try to organize another meet when you're available.

The end user is available for a Teams meet today from 14 to 15 CEST (UTC+2)
Let me know if you are available, otherwise I'll ask to have a couple of options for next week.

I'm sorry, but at least for me (and probably for atrol and vboctor too) that will not be possible. We support MantisBT in our spare time, don't get paid for it, and to be honest there is no way I would take time off from my day job to provide this kind of assistance.

As mentioned previously, we are currently unable to reproduce the issue. That does not mean it does not exist of course, but we need you or your client to provide a reproducible test case (step-by-step instructions, including system setup).

we noticed that the vulnerability seems to be only on projects with "obsolete" state and not if the state is "development".
I guess that something changes on the authorization checks, based on the project state.

I'm afraid the project status (obsolete/development) is a red herring, the project_status_enum_string is not used in access checks.

More likely there are some project-specific settings in your client's system configuration that are different from the globally-defined values and/or the project where the vulnerability exists.

In this context, you should check:

• the value of bug_revision_view_threshold config ? Make sure you check at all levels, i.e. user, project, global level
• is the bugnote being accessed public or private ? If private, what is the value of private_bugnote_threshold (again, at all levels) ?
• the user's access level in the issue's project
• the value of private_project_threshold config ?
• is the user the reporter of the issue being accessed ?

If you have some PHP knowledge, you can have a closer look at access_can_view_bugnote_revision() in core/access_api.php, and debug/trace the code to understand why it's not returning false as it should.

Hello, I am sorry for the misunderstanding, I am not familiar with the project at all, and could not imagine that there was not some sort of developer funding within it.
Clearly I cannot ask for too much effot from you, I would just like to find a way to identify and help solve the problem.
Since I do not even know the security features, related to the project, I would need more context to find the information you have indicated. For example 'private_bugnote_threshold', where is it visible?
My proposal to meet was based on the idea that since you are most familiar with the product, you could suggest what and where to look with just a few clicks.
I'll try to do this part, now I know what to look for, if you can give me some suggestions on where or how to look (from the GUI? directly on the DB?), I'll do my best.
I have some familiarity with php, the problem is that the client can't share a copy of the DB with me, as they have sensitive data inside, and I can't freely edit the code on their systems.
Is there any debugging mode that writes the results of the various steps/functions to screen or logfile?

Thank you very much

P.S.
If the company I did the tests for were willing to pay for your consultancy, for the resolution of this bug, since they use your product, would this be manageable?
Could you give me an idea of the costs? Thank you again

Configuration settings are defined in config/config_inc.php file; some of these configs can be overridden in the database (stored in config table), from the GUI you can view and change these from the Manage > Configuration > Configuration Report page (adm_config_report.php).

Unfortunately, there is no MantisBT setting that will give you any useful logging to troubleshoot this specific issue without touching the code. PHP can be configured to run in debug mode, which would allow to trace execution step by step, but this is not something that you would want to do in a production environment. Maybe they have a test env that can be used for that purpose. Anonymizing sensitive data may be another option.

I may be wrong of course, but I don't think the problem here is data driven. It's most likely caused by configuration (metadata), so the key is to find out what config(s) to set in order to build a reproducible case on a fresh installation. Start with checking the indications I gave you in 0032980:0068176.

I know they had a 2.1.0 installation and than upgraded to 2.25.7. I also know that the issue is only on older projects.
I'll try to install and configure things on 2.1.0 and then upgrade.
It sound strange to me that they have manually modified configurations, but anything may be..
I'm more oriented in thinking something that changed from a version to another. Is this plausible?

What about the paid consultancy, is it something you would like to manage?
(The my point is that it would be better to pay 1/2h of your time, instead of risk to pay and waste 8h of mine)

I'm more oriented in thinking something that changed from a version to another. Is this plausible?

I don't have time to go over the differences in code that could have an impact on this, but to be honest I doubt it.

What about the paid consultancy

I sent you an email last night, didn't you get it ?

Yes, I'll write you back soon.
Thanks

As part of the upgrade process, not following the upgrade instructions from the Admin Guide the user replaced the 2.25.7 config_defaults_inc.php file with the old version from 2.1.0.

This caused some config options to be undefined, including $g_bug_revision_view_threshold which is the problem's root cause here.

With increased log levels ($g_log_level[E_USER_WARNING] = DISPLAY_ERROR_INLINE;), the problem becomes obvious, as shown in the attached screenshots.

The MantisBT source code should never be modified, this is not supported.

We could upgrade the WARNING to ERROR to make this kind of problem more obvious, but considering that these are normally caught at development time and this is really a corner case, I don't think it's really worth it.

image-2.png (107,061 bytes)   

image-2.png (107,061 bytes)   

image.png (148,391 bytes)   

image.png (148,391 bytes)   

Resolving the issue as "no change required" as the problem was caused by an incorrect upgrade.

You might consider putting some sort of integrity check, on the version of the most vital files, such as the "config_defaults_inc.php."
If raising the error from WARNING to ERROR blocks execution, that might be a viable alternative.
I am aware that the problem was introduced by an erroneous user operation, but the concept of resilience and "security by default" should protect the user as much as possible, even from his own unconscious errors.

It remains to report version-related information leakage (fingerprinting), via /mantisbt/api/rest/. Since I did not identify it myself, I imagine dregad will handle it directly.

Best regards and thanks for the assistance

Paolo

It remains to report version-related information leakage (fingerprinting), via /mantisbt/api/rest/. Since I did not identify it myself, I imagine dregad will handle it directly.

Thanks for the reminder. This was discussed internally, but I forgot to create an issue to formally track it. See 0033017.

You might consider putting some sort of integrity check, on the version of the most vital files, such as the "config_defaults_inc.php."

Such integrity check was actually implemented in the past, but unfortunately following a server migration some of the source code got lost and was never recovered, and the developer who worked on it left the project, so it's there but currently disabled. You may see the remnants of it here:
https://github.com/mantisbt/mantisbt/blob/2c458db0b0e7ac48cc4aac8539aff5aab5758655/admin/check/check_integrity_inc.php

If raising the error from WARNING to ERROR blocks execution, that might be a viable alternative.

I'll discuss it with the team.