Please improve reporting about security issues and fixes

[TLINDEN]

Release 6.10.0 changelog contains this item:

(#32690) Security Hotfix (https://docs.rocket.chat/guides/security/security-updates)

There is no associated issue, no mention of any related CVE, no description what is the nature of the vulnerability nor what the fix does to close the hole.

So, please, enhance your change reporting process to include such important security informations, so that people can verify if their instance is affected, how they can check if the vulnerability has already been used, if there's a workaround etc.

Just for the record, the CVE inquestion is CVE-2024-37405, the conversation about the CVE can be found here and the commit which fixes it is f85a4b5.

Especially if you look at this commit, you can see the problem. the commit message is just "fix: security hotfix", it does neither tell what nor how it fixes it. Then the commit adds 546 lines and removes 30 - this is a huge more or less uncommented change, no "hot fix", guys. Also, the associated PR #32690 does not contain a word about the nature of the vulnerability or about the fix. In most organizations such PR's are usually rejected, especially if they are security related.

So, please, enhance your processes.

Thanks in advance,
Tom

[reetp]

This is really a support request and not a bug in itself.

Rocket is open source - you are well aware that means that the source is there for you to read and use at your own risk, and there is no compulsion on Rocket.Chat to advise anything else.

Note the link to security policy below:

https://github.com/RocketChat/Rocket.Chat/blob/16a9c862d20d93c614ce76801f29d03f41b98abe/SECURITY.md

The obvious answer is that if they publish information then it is much easier for hackers to discover and attack, and anyone who has not bothered to upgrade is more vulnerable if the exploit is 'published'. Unless you use the cloud offering or snaps, systems cannot be 'force' updated.

You have kindly draw attention to this particular exploit..... You should probably have addressed your concerns directly to the security team rather than publish it all here.

I have raised this internally for an 'official' answer, and whether it is possible to formalise reporting on security issues eg add the CVE to the PR.

I have also asked if the exploit exists on older versions and if so, whether there will be backports to supported versions.

In future please contact security @ rocket.chat directly if you have further questions or concerns.

You can also contact me on https://open.rocket.chat

[julio-cfa]

HI @TLINDEN,

Our whole application security program is currently being redesigned and there are new processes being implemented. I'd say that for now HackerOne, CVEs, and the "releases" tab here on GitHub are the sources of truth when it comes to security updates, but we are thinking about an effective way of centralizing and reporting / disclosing vulnerabilities. We will probably have it in the following months.

[paulchen]

In addition to the concern raised by @TLINDEN, I noticed that only 6.10.0 contains the hotfix. Are security patches not backported to older minor versions that are still supported?

As it was discussed recently in #32600, it is not advisable to update to the most recent minor version as soon as it's available.

Hence, if security patches are not backported, this leaves operators of Rocket.Chat instances with two possibilites:

• Stay on the old minor version and leave security vulnerabilities unpatched.
• Update to the most recent minor version and possibly cope with major issues.

[TLINDEN]

Hi @reetp

thanks for your kind response.

Rocket is open source - you are well aware that means that the source is there for you to read and use at your own risk, and there is no compulsion on Rocket.Chat to advise anything else.

Yes, thanks goodness :)

The obvious answer is that if they publish information then it is much easier for hackers to discover and attack, and anyone who has not bothered to upgrade is more vulnerable if the exploit is 'published'.

Well, security professionals call this "security by obscurity". Believe me, hiding information only harms users. Adversaries are always able to find what they're looking for.

You have kindly draw attention to this particular exploit..... You should probably have addressed your concerns directly to the security team rather than publish it all here.

Will do.

I have raised this internally for an 'official' answer, and whether it is possible to formalise reporting on security issues eg add the CVE to the PR.

The point is, that not everyone follows the usual channels where CVEs are reported etc. I do it because I work in the industry, others might just not be aware. These users are the reason a project needs to publish such things somewhere prominent, so that average joe admin is able to find it.

Take a look at other projects, for example how the freebsd guys do it. Each vulnerability gets its own advisory which contains at least these data points (and which is being mentioned+linked on the release page):

• originator
• severity
• versions affected
• versions patched
• the nature of the vulnerability
• possible impact on affected users
• workaround if possible
• upgrade information

best,
Tom

[Gummikavalier]

I agree with pretty much anything that can be said about this. Security is the most important matter.

But security by obscurity, while not real long term security, buys time to fix issues.

Features equals bugs, bugs equals security vulnerabilities. RC has lots of features. Particularly fixing security issues that come from design issues require time to redesign the affected features and their implementation.

The only other option would be to disable affected features until the fix is out, which then again would require implementing security by design thinking into whole RC code base. (Everything would be sandboxed from each other and require stable switches to turn the features on/off and RC would still be in working condition after that.)

Also some security issues originate and can be fixed only in the dependencies of RC.

(Note: I'm not RC developer. I'm just a sysadmin who maintains RC and has a habit of peeking at the changes sometimes. Regarding adversaries who know what to look for; that level of adversaries already know bunch of previously completely unknown 0-days anyway, and have access to your system through those all the time, unless you design the environment against it yourself.)

[reetp]

In addition to the concern raised by @TLINDEN, I noticed that only 6.10.0 contains the hotfix. Are security patches not backported to older minor versions that are still supported?

They usually are and I have enquired about what is happening. I will respond as soon as I hear anything, or possibly the team will comment directly.

As it was discussed recently in #32600, it is not advisable to update to the most recent minor version as soon as it's available.

Absolutely. You per that bug you should never use 'latest' and only upgrade when you are happy. As it transpires with 6.10 it may fox some bugs, but it appears to break some other stuff - see some other recent issues here with apps etc :-(

Hence, if security patches are not backported, this leaves operators of Rocket.Chat instances with two possibilities:

* Stay on the old minor version and leave security vulnerabilities unpatched.

* Update to the most recent minor version and possibly cope with major issues.

Indeed. I do not know why this has not been backported as yet as it would be normal to do so for supported versions. I presume they are doing some regression testing on other versions due to other back end changes that have recently been made.

As soon as I know more I'll get back to you all.

[reetp]

Hi @reetp

thanks for your kind response.

I try :-)

I just might have the answers you want! Note I am not a Rocket.Chat employee though I did work for them for a short while a few years back. I'm just a long time community trusted member with good communication channels with the team. Opinions are my own, but I know they essentially echo the team.

The obvious answer is that if they publish information then it is much easier for hackers to discover and attack, and anyone who has not bothered to upgrade is more vulnerable if the exploit is 'published'.

Well, security professionals call this "security by obscurity". Believe me, hiding information only harms users. Adversaries are always able to find what they're looking for.

As per the comment by Gummikavalier above who summarises things nicely. There are no easy options.

You have kindly draw attention to this particular exploit..... You should probably have addressed your concerns directly to the security team rather than publish it all here.

Will do.

That is the route for anything in the future.

I have raised this internally for an 'official' answer, and whether it is possible to formalise reporting on security issues eg add the CVE to the PR.

The point is, that not everyone follows the usual channels where CVEs are reported etc. I do it because I work in the industry, others might just not be aware. These users are the reason a project needs to publish such things somewhere prominent, so that average joe admin is able to find it.

To be quite honest with you, in my experience VERY few admins using Rocket.Chat, or most other systems, EVER read ANYTHING at all. The only time they pop up is when something breaks.

You could write the CVE info in the changelogs in 2 mtr tall letters with lights and dancers and they will be completely unaware as they never, ever, read the changelogs. Most don't even know such things exist. They use snaps and it auto-updates at some point and that's it.

It is the problem with making things 'easy'. They all suddenly think they are admins. I see it day in, day out.

I'm really not sure if there is anything you can do about it. The IT industry as a whole has let them down.

Take a look at other projects, for example how the freebsd guys do it. Each vulnerability gets its own advisory which contains at least these data points (and which is being mentioned+linked on the release page):

Yup I also work on a Linux distro and fully understand how we do things there.

But every org is different and every org has a different point of view and policy.

As mentioned above, this has prompted more conversations internally at Rocket and they are working on updating this. It might not be entirely what you want, but suffice to say work is ongoing.

I think this should probably be converted to a discussion rather than a bug.

If you want to discuss in more depth then do please contact me on open.rocket.chat and I will be happy to elaborate. We need some more community members to step up and help with general support, bug triage etc.....

[reetp]

As this is not a bug in Rocket.Chat itself I am moving this to a discussion.

By all means follow up there.

[TLINDEN]

Good idea to turn this into a discussion, I just was not aware of the feature. Thanks.

Yeah, I know these types of "admins" :) But IMHO it's way better to have the infos somewhere easily reachable for the occasional security aware user - than to have nothing.

Look at it from this perspective: a transparent security process is a huge plus for the project and the company. Users will trust you more and although most people might not actually read security advisories, they will take it into account when deciding between RC and a competitor.

And there will be one or another happy Tom out there :)

Best,
Tom

[casalsgh]

FYI On recent Security items; the backport of fixes are out an available for 6.6.11; 6.7.6; 6.8.4; 6.9.4