~cadence/tube#32: 
CloudTube — concerns about user-configurable NewLeaf instance

I'm not sure how much of an issue this is, versus just security paranoia, but the idea of a user being able to configure the NewLeaf instance arbitrarily makes me a little bit uncomfortable, because it could be used to prod some services which are not meant to be external.

I realise it will only access various Invidious-like API endpoints, but the wriggly feeling is still there? Is it mistaken?

Status
RESOLVED DUPLICATE
Submitter
~reivilibre
Assigned to
No-one
Submitted
3 years ago
Updated
3 years ago
Labels
cloudtube discussion

~cadence 3 years ago

That's a fair concern, because they can send requests that originate from inside the intranet. I considered putting in a configurable blocklist of things the end user is not allowed to connect to, but this would be a little annoying to code, because it would have to be based on the IP address, because if it was based on domain names anyone could create an alias. So I'd have to manually resolve each instance input to its IP and check it before connecting. Even then, several IP addresses correspond to the same machine. Anything starting with 127. is localhost.

The internet sucks and I don't know how I could implement this in a way that is both configurable, and easy for instance admins to not mess up.

~reivilibre 3 years ago

You're right, the IP address would have to be resolved first before doing an actual HTTP request.

I think a sensible default would be to have the private IP spaces blocked — I suppose the config format should be a list of CIDR-notation IP ranges.

My first thought is that Matrix Synapse has such a list which could be 'borrowed', at least as a starting point: https://github.com/matrix-org/synapse/blob/e12077a78afb8f0e7931a0930aebe5081023d5f9/docs/sample_config.yaml#L169-L187

But it absolutely must be the case that this is resolved and checked and the domain name never used again (since you can do DNS round-robin or other such tricks, so the DNS result isn't deterministic...).

As a first thought: does it work if you replace the hostname in the URL with the IP address, but set a custom Host: header? (perhaps there is a proper way of doing it instead, too…)

(Actually, that wouldn't work, probably, since TLS Server Name Indication needs to know the name as well…).

~cadence 3 years ago

The actual sending of requests won't be an issue.

I am concerned that the complexity of CIDR and the number of subnets that must be blocked may lead instance admins to incorrectly set up their instance. A lot of people in the chatroom are also trying to insist that configuration files should be optional, which would mean most admins wouldn't even be aware that this is something that needs to be changed, if they get their way.

It would be better to do that than no validation, yes, but I don't want people to end up in a false sense of security, and I don't want to start with a half-baked implementation that's terrible to configure.

Suggestions welcome!

~reivilibre 3 years ago

If the list of private IP ranges is used as a default, that seems broadly sensible to me.

The only issue I see that would come if they their own NewLeaf instance in the private range, and not publically accessible. This seems to me like we would want to accept minor exceptions to the deny-list.

My suggestion would be to have a deny-list, which is pre-configured with the private ranges and doesn't need to be overridden by the admin (this is still compatible with your 'no config required' idea, and also means admins don't need to touch it!) — but then an allow-list can be specified which overrides the deny-list (and has a default or special case to allow the NewLeaf instance that is declared as the default by the server…)

The actual sending of requests won't be an issue.

If you don't mind, how would you do it? I'm curious :)

~abeltramo 3 years ago

How about the other way around? Isn't it easier to have a whitelist instead of a blocklist? So that when you host your instance you fill a list of known good invidious/newleaf apis and users will only be able to pick from one of those. There's no checking of IP ranges, DNS or anything really because users will only be able to pick one of the servers.

Having a blocklist is pointless with an open text input where users can really enter anything. A few issues with this approach:

  • Who will populate the blocklist and who will keep it updated?
  • How do you recognise bad traffic?
  • Even if you recognise a bad server how do you block it? You can easily get a new IP in seconds by deploying an instance on one of the cloud providers: AWS, Digitalocean etc and it will cost you cents. In most countries restarting the router gives you a new IP.

~reivilibre 3 years ago*

Admittedly, I don't know what the intent of having it be user-configurable was (to evade YouTube bans?).

For my personal use I doubt I'll ever be using anything other than my own instance. For this usecase, removing the user option and having a 'whitelist' of just the configured instance would suit. (But I assumed the option is there for a reason :))

Edit: In my opinion, the idea for the blocklist would be to prevent your server from poking internal services that shouldn't be accessible to the broader internet. There was nothing about malicious traffic — since the CloudTube server is acting as a client, I'm not sure what malicious traffic would look like or what would need to be dynamically blocked as such.

~abeltramo 3 years ago

I think the point is that you can easily host your own newleaf instance and point any cloudtube installation to your API to avoid YouTube bans. But this really opens up lots of issues, you give an attacker a sure entrypoint into your application, they know exactly what kind of requests you'll do and they can provide any kind of payload back to your cloudtube instance. I'm not a security expert but this seems to me easily exploitable by a bad actor.

~reivilibre 3 years ago

Ah, you're considering security from the other angle.

What you're talking about should only be exploitable if the output from the NewLeaf API is being treated as trusted in some way. I would hope that's not the case. (Perhaps I could imagine XSS happening this way, which can be avoided if the templating language makes it very obvious when strings aren't being HTML escaped, for example.) Unless something is wrong, it shouldn't be any more of an attack entrypoint than the HTTP web interface that CloudTube exposes.

However, what I'm talking about is: what if I have a service listening to TCP 127.0.0.1:4242 on my server, and someone tries to configure that as the NewLeaf instance in order to get CloudTube to send requests to it — there may be scope for exploiting strange quirks in these internal services.

~abeltramo 3 years ago*

Ah I see what you mean, that's another possibility but it would be fairly complex for an attacker to know where to look at, and at least they can't forge a payload to be sent to a local endpoint. Another security concern could be people using cloudtube to DDOS another server. Unless there's rate limit you can easily point a cloudtube instance to a remote endpoint and hammering it with as much requests as your server is able to make.

I keep thinking that having a free text input for a server address is really too much.

~cadence REPORTED DUPLICATE 3 years ago

I'll close this and split it off into 2 threads for the 2 main security issues that have been brought up here.

Security: User-configurable instance may access internal services
https://todo.sr.ht/~cadence/tube/33

Security: User-configurable instance may return bad data
https://todo.sr.ht/~cadence/tube/34

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