Comment by ~reivilibre on ~tdeo/serde_bare
You're right, you can use a
&mut Cursor(or indeed&mut WwhereWis any otherWriteimplementation!).Thanks for your time :).
REPORTED RESOLVED INVALID
Ticket created by ~reivilibre on ~tdeo/serde_bare
The current deserialise functions seem to consume a reader or a slice, but don't give information about how many bytes were consumed, or so on.
It would be nice to be able to continue deserialising further messages in the stream, since I think the length of the data is clear from the format anyway?
Ticket created by ~reivilibre on ~tdeo/serde_bare
As it stands, it's very hard to find this ticket tracker without knowing to replace git by todo in the URL.
Comment by ~reivilibre on ~cadence/tube
Some thoughts:
- 'slow HTTP' attack — would need to time-out connections so that a malicious instance can't trickle back bytes at a time and keep a connection open for a long time
- need to limit the size of the response body
Things like issues in the JSON decoder are so severe that they could probably also be exploited through other means (e.g. on the public HTTP web interface provided by CloudTube)
Comment by ~reivilibre on ~cadence/tube
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 '127.0.0.0/8' but permit the single service '127.0.0.1:7331'.
Comment by ~reivilibre on ~cadence/tube
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:4242on 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.
Comment by ~reivilibre on ~cadence/tube
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.
Comment by ~reivilibre on ~cadence/tube
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 :)
Comment by ~reivilibre on ~cadence/tube
I sent one through on the mailing list, but it's my first e-mail patch, please let me know if it's fine :)
Comment by ~reivilibre on ~cadence/tube
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…).