Rocket.chat: Policy violation - server pulling update messages from Rocket.Chat cloud without permission

[reetp]

Description:

This is really a security violation.

RocketChat seem to have awarded themselves permission to push messages to my server via rocket.cat and a notification bar in my channels with a readme URL.

Steps to reproduce:

Be logged into Rocket. Don't have a registration.

See attached screenshots

Expected behavior:

Keep your fingers out of my server. I don't expect you to be able to control anything on my server without my express permission. Ever.

Actual behavior:

Someone at Rocket has the ability to control some aspects of my server without my permission. No evidence to show if this can be controlled or stopped. If there is it has been sneaked in and enabled by default. Undocumented as far as I can see.

How can you contact MY rocket.cat user when there is no Internal Hubot control anymore? And the instance is NOT registered with a token or apparently connected. But clearly is somehow.

Some sort of little Easter egg on a timer? No indication of this.

Who does it appear for? Just an admin, users? I have no control of this. May be I don't WANT notifications???

Server Setup Information:

• Version of Rocket.Chat Server: 3.2.2
• Operating System: Linux
• Deployment Method: Docker
• Number of Running Instances: 1
• DB Replicaset Oplog: Enabled
• NodeJS Version: 12.16.1
• MongoDB Version: 18.06

Client Setup Information

Apps. Browser. Desktop client

Additional context

Clear violation of my privacy.

I am sure that few people realised you could do this, and there is nothing I can see in your policies that says you can.

https://rocket.chat/privacy/

Administrators are still in full control over the configuration of their instance.

Clearly not then.

Our code is open source, there are no back doors whatsoever.

So, what would you call it then?? How can I tell what else you can or cannot do?

Relevant logs:

I'd love to find where it tells me this happened, but I guess it is conveniently hidden.

This really is as low as you can go and you should be completely and utterly ashamed of your behaviour. I really thought you were better than this.

Presumably the venture capitalist corporate mentality has now woven it's tentacles throughout what was once a really good organisation.

This is really sad, and a complete vindication of why I chose to stop volunteering my time to help Rocket.

[sschueller]

Another issue is that push notifications for mobile devices are on by default on your private instance. These go via rocketchat servers and can possibly be viewed before going to google/apple.

[rodrigok]

Just to give more context here, it's not something pushed to the instances, but a cron job that runs every day checking for new release, security releases and alerts from the Rocket.Chat cloud. It's not possible to disable it right now.

[cs35-owncloud]

It seems to call this URL: https://github.com/RocketChat/Rocket.Chat/blob/5cf9c1be6a5b908d2de33a040aea635e7d028e5d/app/version-check/server/functions/getNewUpdates.js#L37

If it's not possible yet to disable it, you can change on your RC machine the DNS in /etc/hosts of releases.rocket.chat to 127.0.0.1, so the call should fail thus it won't "leak" data. I don't know if it could add bug to your RC, so I wouldn't do it.

[nahga]

So this embedded cronjob runs daily, but can't be disabled? Nice.

[sschueller]

It seems to call this URL:

https://github.com/RocketChat/Rocket.Chat/blob/5cf9c1be6a5b908d2de33a040aea635e7d028e5d/app/version-check/server/functions/getNewUpdates.js#L37

If it's not possible yet to disable it, you can change on your RC machine the DNS in /etc/hosts of releases.rocket.chat to 127.0.0.1, so the call should fail thus it won't "leak" data. I don't know if it could add bug to your RC, so I wouldn't do it.

That call also sends some information of your instance to rocket:

uniqueId: uniqueID.value,
installedAt: uniqueID.createdAt,
version: Info.version,
oplogEnabled,
osType: os.type(),
osPlatform: os.platform(),
osArch: os.arch(),
osRelease: os.release(),
nodeVersion: process.version,
deployMethod: process.env.DEPLOY_METHOD || 'tar',
deployPlatform: process.env.DEPLOY_PLATFORM || 'selfinstall',

[cs35-owncloud]

It seems to call this URL:
https://github.com/RocketChat/Rocket.Chat/blob/5cf9c1be6a5b908d2de33a040aea635e7d028e5d/app/version-check/server/functions/getNewUpdates.js#L37

If it's not possible yet to disable it, you can change on your RC machine the DNS in /etc/hosts of releases.rocket.chat to 127.0.0.1, so the call should fail thus it won't "leak" data. I don't know if it could add bug to your RC, so I wouldn't do it.

That call also sends some information of your instance to rocket:

uniqueId: uniqueID.value,
installedAt: uniqueID.createdAt,
version: Info.version,
oplogEnabled,
osType: os.type(),
osPlatform: os.platform(),
osArch: os.arch(),
osRelease: os.release(),
nodeVersion: process.version,
deployMethod: process.env.DEPLOY_METHOD || 'tar',
deployPlatform: process.env.DEPLOY_PLATFORM || 'selfinstall',

You're right, sending the uniqueId could be some privacy intrusion. IMHO installedAt also is not really useful to check if there's an update for that specific platform. I still suggest changing the DNS while waiting for an answer about privacy from RC.

[geekgonecrazy]

Another issue is that push notifications for mobile devices are on by default on your private instance. These go via rocketchat servers and can possibly be viewed before going to google/apple.

To be clear this is completely unrelated. We only configure via our gateway if you chose to register during sign up and agree to terms and privacy policy. This code has been there since super early versions of Rocket.Chat. If you chose the second option it doesn’t use our push gateway. This choice is always up front and in users control. This hasn’t changed and we won’t be taking that choice away.

[reetp]

You're right, sending the uniqueId could be some privacy intrusion. IMHO installedAt also is not really useful to check if there's an update for that specific platform. I still suggest changing the DNS while waiting for an answer about privacy from RC.

As they are now forcing you to have a cloud account they want to enforce a uniqueid to track your server usage. That will log your individual instance with a name, address etc etc. with your 'cloud' account(*) that you are force to create (if you actually can as that seems pretty broken right now). There will be no escape from that.

So they will get it one way or another. The problem is they just aren't open and honest about all this stuff. Half cock, badly implemented and lastminute dot com rushing around. It makes you question what else are they are being 'economical with the truth about'?

Sure, the code is Open Source and you can inspect it. How many people really do?? And that is how it works - the general assumption that stuff can be added and most people will not notice.

Note - I'm not AGAINST this. I am against the way that it is being IMPLEMENTED.

(*) which despite being advised that logging in to your cloud account does not set cookies I have discovered it does - see https://forums.rocket.chat/t/enforcing-registration-requirement-to-utilize-push-gateway/7545/55 Clearly some tie up with stripe.com for payment services I guess.

[makibras]

Dear community

please find a statement from our team here: https://forums.rocket.chat/t/update-on-sending-notifications-to-private-workspaces/7735

the pull request to disable this is ready to be merged asap: https://github.com/RocketChat/Rocket.Chat/pull/18339

[engelgabriel]

@reetp you are really starting to upset me. I had high regard for you, but you are definitely crossing a line here. What do you mean by "_economical with the truth about_"?

You are the one factually incorrect in A LOT of your statements. We are not "forcing you to have a cloud account". All the source for the apps is open source. Do you know what it means? It means you can use it any way you want. We simply cannot force anyone to do anything. How can you say "There will be no escape from that." when you can, like many people did, get the code for the mobile apps, and compiled your own apps, that won't use any of the servers we pay to maintain. But guess what? If you want to do so, you will have to create accounts with Google and Apple, sign terms of services, validate your address with Dun & Bradstreet, and pay yearly fees. I do not understand why you feel we have the obligation to do all that for you or for anyone for free and get surprised if we are not willing to be just an open relay service for push notification.

For these reasons, I'll not engage further in this conversation.