Mattermost-server: x-version-id headers containing version of the running product - is this really neccessary ?

[sokoow]

https://github.com/mattermost/mattermost-server/blob/1ee872578c734956acc7f5e4168638de244c3ce2/model/client4.go#L21

So seems like mattermost discloses its version in headers - not a very good practice. Let's assume that you had a critical flaw, some users fail to upgrade, and you're disclosing the version, and you know who/what to attack. Can this be removed or made optional please ?

[SmartHoneybee]

Hi,

if you don't like it, just hide it, e.g., with nginx's proxy_hide_header

Regards,
Bee

[hanzei]

There are many ways to determinate the server version e.g. changes in the API. Hiding the header does not enchant the security. See also https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle.

[amyblais]

Hi all, we just opened a ticket to fix this - we'll give you an update when a fix is in.

[sokoow]

@hanzei I don't disagree, but your approach will require effort and won't just return a product version in first response to login page - that will filter out 90% of attackers out there. I'm a believer of doing something like in nginx - want to disclose a product version - here's a clear flag for that, otherwise you need to use a tool that checks timing and correlations of this and that to figure out what you run.

@amyblais thank you for response and reaction, but this is not over - I found two more places where version disclosure is happening , mostly in fetch/json communication:

• response headers contain a header called etag, which literally is a version of the product and build, example taken from a random internet mattermost server: etag | 4.10.0.azmoobkzipf1bgs4hm4fqh3m5h.1541581769971.0.48
• request headers contain header called If-None-Match, which again is matching build and version of the product, example: If-None-Match | 4.10.0.azmoobkzipf1bgs4hm4fqh3m5h.1541581769971.0.48

Can these be made not related to product build and version info please?

[amyblais]

Hi @sokoow, some feedback from our developers for your latest post:

At this point we feel that these are not vulnerabilities, and they are mostly a "nice to have". We will consider these in the long-term, but in the short-term there would be a breaking change if we fix these.

We are working on some fixes around the overall issue with version headers, but I can't provide more details until after the fix is in, since this is considered confidential.

[hanzei]

Actually there are a lot reliable of ways to get the server version:

• X-Version-ID http header
• /api/v4/config/client?format=old
• Filename of /static/main.*.css
• Hash of of /static/main.*.css
• Filename of /static/main.*.js
• Hash of /static/main.*.js

All of this methods require a simple bash script. Some just one line of code. I don't see a way of fixing them all.

[hanzei]

@amyblais Do you have update about this topic? Is there a JIRA ticket to track this?

[amyblais]

No updates; there is an internal ticket open for this.

[someone-somenet-org]

From a cyber-security perspective it doesnt matter at all if you disclose the version - an attacker will run all their exploits against the software, disregarding any version information (which might be faked to hide the fact that for some reason no updates were applied for a while) because it doesnt cost anything to try everything.

But +1 for removal, because i dont like unnecessary custom headers/transmitted data.