107
Would YOU donate your idle CPU cycles to TankieTube? (hexbear.net)
submitted 3 weeks ago* (last edited 1 week ago) by TankieTanuki@hexbear.net to c/chat@hexbear.net
40 comments fedilink hide all child comments

I was just setting up remote runners for TankieTube when I had an epiphany:

I could ask comrades to volunteer their own computers! quagsire-pog

That way those who can't or don't care to donate monetarily could still contribute.

How would it work?

Conceptually, you can think of it like a crypto mining botnet. Except it transcodes videos for the community instead of producing heat for individual profit. And it's voluntary ofc.

It can run on any operating system with an internet connection. I'm going to use my gaming desktop and at least one VPS.

Tech level required: comfortable copy-and-pasting things into a CLI.

OpSec considerations: negligable as far as I can tell. There is no P2P involved. Your computer talks directly to the TankieTube server using sicko-to-HTTPS communication. The server would see your IP address, but that's always the case on every website.

Thoughts?

all 45 comments
sorted by: hot top controversial new old
[-] trompete@hexbear.net 24 points 3 weeks ago

Video decoders are all written in C and almost certainly full of exploitable bugs, thus people participating in this are making their personal computers vulnerable to attack via manipulated video files. You'd at least want this sandboxed as much as possible, and have it run as it's own user.

[-] TankieTanuki@hexbear.net 16 points 3 weeks ago* (last edited 3 weeks ago)

Yeah, I use a designated user prunner like the docs suggested.

Is ffmpeg really that much of a security concern?

making their personal computers vulnerable to attack via manipulated video files

Is this any more dangerous than BitTorrenting anime? All the video files would be coming from https://tankie.tube only.

[-] toys_are_back_in_town@hexbear.net 15 points 3 weeks ago* (last edited 3 weeks ago)

Is ffmpeg really that much of a security concern?

Yes. Video decoders are complex software and ffmpeg has a long history of security patches. If those are the bugs we caught, what's left?

Is this any more dangerous than BitTorrenting anime?

Not really except that tankietube is probably more of a target than random anime pirates. But comrades, if you have a need for decent opsec, don't be sailing the high seas.

This seems more like the sort of thing to run on something you can periodically nuke, and maybe put behind an external firewall that only allows communication with the tankietube servers. Maybe some comrades have spare credit on a cloud provider that would be suited for this.

This is a great idea but unfortunately security is always a concern.

edit: sorry if you got hit with a bunch of notifications, the reply was silently failing and I didn't know what was going on so I retried oops

[-] PorkrollPosadist@hexbear.net 10 points 3 weeks ago* (last edited 3 weeks ago)

I think it is worth further research, at least. Setting aside potential exploits in ffmpeg, containerization (if not virtualization) seems necessary. A process running as root in a Docker container effectively has root access to the host, but a properly designed container should run all the work as non-privileged users. This work can be isolated using the cgroups APIs (docker should manage this, I think) and potentially reinforced with SELinux policies. Done correctly, this would effectively limit the impact of remote code execution in ffmpeg to denial of service. The attack surface for privilege escalation would then be limited to the Linux syscall API, utilities with the setuid flag, etc (highly, highly audited stuff that would allow you to root any machine if it were broken).

Alternately, it might be worth looking at bubblewrap, which is the basis of FlatPak containerization.

[-] TankieTanuki@hexbear.net 4 points 3 weeks ago

What is the threat model? The TankieTube server sends a malicious MP4 to the remote runner machine? Or a malicious remote runner sends a malicious MP4 to the server?

The former is easy to avoid by me not being evil. The latter is only a security concern for the TankieTube server, not the contributors.

[-] PorkrollPosadist@hexbear.net 11 points 3 weeks ago* (last edited 3 weeks ago)

Hostile user uploads a malicious video file, peertube instance sends it to a volunteer for transcoding, RCE occurs on volunteer's machine.

[-] TankieTanuki@hexbear.net 2 points 3 weeks ago* (last edited 3 weeks ago)

So the concern is that a volunteer could have a more vulnerable installation of ffmpeg compared to the local server? How does that happen?

[-] Tabitha@hexbear.net 4 points 3 weeks ago

I think most prospective volunteers just want ffmpeg to run in a secure context without root, and stronger vouching of security by multiple knowledgeable users. The specifics of ffmpeg having vulnerabilities is not that important.

[-] BountifulEggnog@hexbear.net 7 points 3 weeks ago

Do you vet all videos uploaded? I thought anyone could upload files to tankietube.

[-] TankieTanuki@hexbear.net 4 points 3 weeks ago

Yes. Anyone can upload, and videos are published automatically. I review the videos every day that have been published recently. I also rely on user reports.

[-] trompete@hexbear.net 10 points 3 weeks ago

Ffmpeg is used by everybody so you'd hope people are looking at it, but I'm sure there's security bugs in there, and probably plenty of them, since it's C parser/decoder code, probably the most dangerous kind of code. I think web browsers do some kind of sandboxing around ffmpeg, plus web browser restrict the kinds of formats they support, but ffmpeg (and peertube?) supports a lot more, many of which will not be audited/fuzzed to the same degree.

Ideally this would be sandboxed so much it can't call anything but read(2) and write(2). I have no idea if any of this software does any sandboxing at all.

Is this any more dangerous than BitTorrenting anime?

Maybe, depends on the what exactly you're worried about. There's potentially political actors that might be interested in fucking with tankie.tube, whereas you can't really target anyone specifically with bittorrent. Also the attacker knows exactly what software will be used to decode the videos, which makes this easier to exploit. I assume that videos can get uploaded to tankie.tube by basically anybody, and those videos would be sent out to be transcoded on random people's machines?

If you assume tankie.tube (maybe peertube in general) is just too small to be on anyone's radar, then that's probably fine.

[-] TankieTanuki@hexbear.net 5 points 3 weeks ago* (last edited 3 weeks ago)

I assume that videos can get uploaded to tankie.tube by basically anybody,

Yes.

and those videos would be sent out to be transcoded on random people's machines?

Randomly to anyone entrusted with a token bestowed by me.

BTW I love your avatar. :3

[-] trompete@hexbear.net 2 points 3 weeks ago

Hey thanks :)

[-] trompete@hexbear.net 1 points 3 weeks ago

Ffmpeg is used by everybody so you'd hope people are looking at it, but I'm sure there's security bugs in there, and probably plenty of them, since it's C parser/decoder code, probably the most dangerous kind of code. I think web browsers do some kind of sandboxing around ffmpeg, plus web browser restrict the kinds of formats they support, but ffmpeg (and peertube?) supports a lot more, many of which will not be audited/fuzzed to the same degree.

Ideally this would be sandboxed so much it can't call anything but read(2) and write(2). I have no idea if any of this software does any sandboxing at all.

Is this any more dangerous than BitTorrenting anime?

Maybe, depends on the what exactly you're worried about. There's potentially political actors that might be interested in fucking with tankie.tube, whereas you can't really target anyone specifically with bittorrent. Also the attacker knows exactly what software will be used to decode the videos, which makes this easier to exploit. I assume that videos can get uploaded to tankie.tube by basically anybody, and those videos would be sent out to be transcoded on random people's machines?

If you assume tankie.tube (maybe peertube in general) is just too small to be on anyone's radar, then that's probably fine.

[-] umbrella@lemmy.ml 2 points 3 weeks ago

ideally you should spin up a separated VM without access to your own network

[-] CarbonScored@hexbear.net 16 points 3 weeks ago* (last edited 3 weeks ago)

I've got a couple machines lying around, and due to set up a server some point soon, so I'd be all down to contribute with that. Even if there are possible sec concerns (which I don't know if there are without looking harder), I'd personally sandbox it all anyway.

[-] hypercracker@hexbear.net 14 points 3 weeks ago

how much firewall bullshit is likely to be needed

[-] TankieTanuki@hexbear.net 11 points 3 weeks ago

None. It uses the same port as the web browser you're on right now.

[-] hypercracker@hexbear.net 8 points 3 weeks ago

So basically the client periodically initiates connections to the server resolved over DNS and the server replies to these requests?

[-] TankieTanuki@hexbear.net 8 points 3 weeks ago

Yeah, just regular HTTP(S) afaik.

[-] FuckyWucky@hexbear.net 14 points 3 weeks ago

I have a sever. I'm lazy though so I would prefer a docker guide.

[-] TankieTanuki@hexbear.net 13 points 3 weeks ago

Okay. I could probably cook one.

[-] Erika3sis@hexbear.net 10 points 3 weeks ago

Tanuki we need to cook

[-] umbrella@lemmy.ml 1 points 3 weeks ago

@ me too when you do

[-] neo@hexbear.net 13 points 3 weeks ago

I think this would best work by writing up a simple Dockerfile for Docker or Podman (one may already exist out there) and at minimum containerizing the work. That level of constraint is likely all that's needed and the end user can also control how much CPU is used, the networking interface to possibly proxy the connection if desired, and what directories are accessible.

Alternatively, a VM could accomplish the same in terms of safety. Of course a VM requires a pre-allocated block of RAM and a full guest OS installation.

[-] OptimusSubprime@hexbear.net 9 points 3 weeks ago

Mods pin this thread.

[-] TheDoctor@hexbear.net 8 points 3 weeks ago

Are you sure you want to give out the direct IP address to your server? Or do you have a proxy set up for ddos protection?

[-] TankieTanuki@hexbear.net 8 points 3 weeks ago

Are you sure you want to give out the direct IP address to your server?

The server IP is public. I'm not using a cloudflare proxy because they're whack. What would you recommend for DDOS protection?

[-] nothx@hexbear.net 7 points 3 weeks ago

I have some credit on a random cloud provider, I may be interested as long as usage doesn’t raise any red flags to them.

[-] TankieTanuki@hexbear.net 5 points 3 weeks ago* (last edited 3 weeks ago)

Bandwidth usage?

[-] nothx@hexbear.net 5 points 3 weeks ago

Any usage really. If resources start getting pegged on the VPS, they may CPU limit it to preserve performance of the neighboring VPS instances.

[-] TankieTanuki@hexbear.net 4 points 3 weeks ago

I see. You can always throttle the CPU usage in the configuration. Or run the service only x hours per day.

[-] nothx@hexbear.net 2 points 3 weeks ago

Yeah that’s very true.

[-] PM_ME_YOUR_FOUCAULTS@hexbear.net 5 points 3 weeks ago

I'd be happy to done some idle CPU's if you get it up and running

[-] umbrella@lemmy.ml 3 points 3 weeks ago* (last edited 3 weeks ago)

Would Cygwin be the way to go for Windows users?

Try either WSL or a Linux VM if you want to do this on Windows.

[-] sharkfucker420@lemmy.ml 1 points 3 weeks ago

It'd be an honor

this post was submitted on 15 Oct 2024
107 points (99.1% liked)

chat

8174 readers
472 users here now

Chat is a text only community for casual conversation, please keep shitposting to the absolute minimum. This is intended to be a separate space from c/chapotraphouse or the daily megathread. Chat does this by being a long-form community where topics will remain from day to day unlike the megathread, and it is distinct from c/chapotraphouse in that we ask you to engage in this community in a genuine way. Please keep shitposting, bits, and irony to a minimum.

As with all communities posts need to abide by the code of conduct, additionally moderators will remove any posts or comments deemed to be inappropriate.

Thank you and happy chatting!

founded 3 years ago
MODERATORS
EmmaGoldman@hexbear.net
Quimby@hexbear.net
ZoomeristLeninist@hexbear.net
SexUnderSocialism@hexbear.net
InsidiousTrackers@hexbear.net