Hacking YouTube with a MP4
realkeyboardwarrior.github.io
Hacking YouTube with a MP4
1–10 of 94 posts
Re: Hacking YouTube with a MP4
#2What'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.
Re: Hacking YouTube with a MP4
#3What'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.
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.
Re: Hacking YouTube with a MP4
#4What'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.
Re: Hacking YouTube with a MP4
#5I have no idea what or how YouTube’s backend works, but I thought it would be useful to share here that if using ffmpeg one can use the arguments -vsync drop to generate fresh time stamps based on frame rate
Re: Hacking YouTube with a MP4
#6looks like Discord is vulnerable to this too, oopsie
Re: Hacking YouTube with a MP4
#7What'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.
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.
Re: Hacking YouTube with a MP4
#8What'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.
The issue with "expensive to calculate" values like the duration of media (for example, variable encodings) is that the encoder tries to help others avoid rematerializing these values by saving its calculation in some metadata. The problem is consumers then have to "trust" the encoder; this post demonstrates a non-malicious case, but perhaps there are more malicious cases (like the vulnerability in Android's libstagefreight years ago).
For example, I wrote an iTunes-in-the-browser web app; I needed to know durations of songs to display them. MP3 doesn't include these in metadata IIRC, so I needed to pre-process them with ffmpeg just to have duration data. I wasn't doing anything with that other than displaying it. But it would have been nice to just have that info in the metadata.
Re: Hacking YouTube with a MP4
#9[deleted]
Re: Hacking YouTube with a MP4
#10What'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.
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.
[deleted]