>Regards, Google Security Bot
Hacking YouTube with a MP4
11–20 of 94 posts
Re: Hacking YouTube with a MP4
#12What's the bug here? It looks like you fooled the container codec with a incorrect timecode and then when it was uploaded to YouTube, the file was rasterized into a sane format. I don't really see an attack here, nor do I see a mitigation.
You could do something like a Zip bomb I guess. YouTube would just have to do some validation of the file before adding to pipeline.
zip bomb is a perfectly valid file.
I can set up a broken service, that outputs a gajillion lines of same errors to syslog, creating terrabytes of logs, zip all that into few megabytes, and that'd be a valid zip, that'd fill up most modern laptops and servers.
A surveillance camera video, with a very high frame rate when motion is detected and a very low frame rate when not (high framerate -> timelapse), can be a perfectly valid video, taking a few gigabytes in this format, and a few terrabytes when converted to fixed 60fps.
Re: Hacking YouTube with a MP4
#13looks like Discord is vulnerable to this too, oopsie
We don't transcode video, so no.
Re: Hacking YouTube with a MP4
#14Earlier quoted context omitted.
It seems like it sort of counts as an amplification DOS. Enough people uploading smallish videos that unravel into terabytes could probably create an issue. It's bypassing the YouTube limits of 256 GB/12 hours. I would guess YouTube will do some sort of fix or sanity check.
That makes sense, thank you. I'd assume a data engineer at Google somewhere has a small yellow light that goes off whenever someone exceeds those limits, but FAANG infrastructure never fails to disappoint me.
More like a graph that a single person generally can't hope to move unless they have a following to the level of xcow. If someone burns a tire in the middle of the rain forest.... can anyone tell until its 50,000 people doing it?
Re: Hacking YouTube with a MP4
#15"Hacking YouTube" is a stretch description ...
Re: Hacking YouTube with a MP4
#16looks like Discord is vulnerable to this too, oopsie
Not discord, but the default player is vulnerable to many different crash shenanigans. I get them sent to me all the time to look into and its usually just people using bogus timestamps, bogus seek times or concatenating multiple videos of different resolutions/rates that the player can't handle. If there was a way to get discord to spawn VLC for playing videos by default this would be less of a problem.
Re: Hacking YouTube with a MP4
#17Earlier quoted context omitted.
You could do something like a Zip bomb I guess. YouTube would just have to do some validation of the file before adding to pipeline.
zip bomb is a perfectly valid file. I can set up a broken service, that outputs a gajillion lines of same errors to syslog, creating terrabytes of logs, zip all that into few megabytes, and that'd be a valid zip, that'd fill up most modern laptops and servers. A surveillance camera video, with a very high frame rate when motion is detected and a very low frame rate when not (high framerate -> timelapse), can be a per…
Zip files that contain themselves are infinitely large when recursively decompressed, so that's much worse than a log file which is merely easy to compress.
Re: Hacking YouTube with a MP4
#18Re: Hacking YouTube with a MP4
#19Earlier quoted context omitted.
We don't transcode video, so no.
the player is malfunctioning anyway, similarly to those videos that report short runtime and then go on forever that get passed around quite frequently
This is how the video element works in chromium. I suspect it looks at the same metadata field. Beyond leading to a bit of absurd UI state though it's not the same kind of issue that this post describes, which deals with trying to transcode these kinds of videos which could multiply storage utilization on the backend.
Re: Hacking YouTube with a MP4
#20Remember zip quines? Ah, good old days.