Security: User-configurable instance may access internal services

Requests are made to the user-provided URL by CloudTube. This means that services running on the same intranet which are not exposed to the public internet, may be able to have data leaked by setting an IP as the instance field so CloudTube connects to and returns data from it.

This can be prevented by restricting the possible values that can be entered in that field. The instance owner should have some amount of control over how this is done.

#Use cases that should still be supported

  • People using a public Invidious instance
  • People using their own private Invidious instance with a public CloudTube instance

#Possible solution 1

List of IPs that can't be connected to in CIDR format. Disallowing 127., 10., 192.168.*, and so on, would solve this issue.

Potential issue: CIDR format is complex and easy to get wrong.

#Possible solution 2

Only connect to a pre-approved list of domains.

Issue: People wouldn't be able to use their own private Invidious instances any more, unless they were on the list, but then they'd be public.

Potential issue: Bad actor sets up an Invidious instance, puts it on the public list, gets it into CloudTube, updates the DNS to (or another internal IP) and then is able to issue requests to the intranet, for a short period of time until the domain is banned.


Assigned to
3 years ago
3 years ago
cloudtube discussion

~cadence closed duplicate ticket #32 3 years ago

~reivilibre 3 years ago

Here is a list of private ranges in CIDR notation from another project with similar security concerns: https://github.com/matrix-org/synapse/blob/e12077a78afb8f0e7931a0930aebe5081023d5f9/docs/sample_config.yaml#L169-L187

I think solution 1 is preferable, but it would benefit from having an extra list of 'exceptions' to the block list, e.g. block '' but permit the single service ''.

~cadence 3 years ago

Ugh, right. We'd also have to allow/deny by port, since some services (NewLeaf!) should be accessible, and others shouldn't be, on the same server.

That's so annoying, but I guess we'll have to live with it...

~lomanic 3 years ago

What about both solutions at the same time?

Have a configurable list of disallowed CIDRs and a configurable whitelist of instances (extended from the public ones retrieved in #13)?

Register here or Log in to comment, or comment via email.