[HN Gopher] Hacking YouTube with a MP4
___________________________________________________________________
Hacking YouTube with a MP4
Author : Keyb0ardWarr10r
Score : 107 points
Date : 2021-10-11 18:31 UTC (4 hours ago)
(HTM) web link (realkeyboardwarrior.github.io)
(TXT) w3m dump (realkeyboardwarrior.github.io)
| 1023bytes wrote:
| >Regards, Google Security Bot
| [deleted]
| dylan604 wrote:
| If you've played around with video formats long enough, you'll
| have seen something like this. This is the basis for most speed
| change "filters". Only the high end ones do any kind of pixel
| based motion estimation so that super slo-mo does not look like a
| slide show.
|
| Also, it's not uncommon to get odd frame rates in the containers.
| Even on things as "innocent" as listing the frame rate as 29.97
| vs 30000/1001 will affect timing (depending on usage). The
| variations on 23.976 is fun too: 24000/10001. 2997/125.
|
| The muxer is an important step. When using software decoders,
| things can be a lot more flexible. Back when shiny round discs
| were popular, there were verifiers that ensured your muxed data
| was correct. When your decoders are in hardware, there is a very
| strict set of parameters the input is expected. Any deviation
| means the hardware cannot play the video. Early days of "cheaper"
| DVD software had issues with the muxing.
| kmeisthax wrote:
| Video editors (or at least Adobe Premiere) have similar
| problems: they ignore the timestamps entirely, and any clips
| you import into them will desynchronize unless you've either
| recorded them from a known-good source with a constant
| timebase, or re-encoded them at a constant frame rate.
| chx wrote:
| Remember zip quines? Ah, good old days.
| warent wrote:
| Folks, just because the author wasn't wearing a Guy Fawks mask
| with a black hoodie and made no mention of gaining access to the
| Central Meme Database, that doesn't mean they weren't hacking.
|
| They were hacking around with MP4 muxers and YouTube. This is
| definitely the hacker spirit. The word doesn't need to be re-
| appropriated by Hollywood caricatures.
| swyx wrote:
| i thought this as well explained. title a bit clickbaity, but it
| got me to click.
|
| i'm interested in learning more about the mp4 format. where can I
| read more? is there a canonical read that everyone but me knows
| about?
|
| OP seems like he has some kind of file explorer UI for it - also
| interested in that
| nightpool wrote:
| "This is clickbait-y enough that I fell for it" is uh. Not
| exactly an endorsement? It seems like kind of the opposite of
| what you'd want to encourage?
| 99112000 wrote:
| MP4 Inspector (Windows)
|
| The MP4 format is fundamentally pretty easy, at least the box
| structure. But there have been so many standards that overlap
| that the MP4 format is also really messy. Aaand you need to pay
| to get access to the specs of the format..
| koprulusector wrote:
| I 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
| rozab wrote:
| I've seen many strange mp4s and webms floating around various
| discord communities. Some crash your client at a fitting moment
| in the video, some appear to be thousands of hours long, some
| appear to be seconds long but are actually hours long, some even
| loop! somehow.
| bluedino wrote:
| One of my favorite "breaking YouTube" (jpeg, really) demos was
| the slow motion glitter
|
| https://youtu.be/BtYKDamqo2I
| smoldesu wrote:
| What'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.
| ndesaulniers wrote:
| 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.
| DrewRWx wrote:
| I ran into a similar issue when I tried to generate a podcast
| RSS feed from a website whose built-in feed didn't go back
| far enough. I was trying to do HTTP range requests on the mp3
| files to save bandwidth and just fetch their metadata. Sure
| enough, mostly no duration and if the encoder did put it in a
| custom field it was usually different than what VLC says.
| mgamache wrote:
| 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.
| ajsnigrutin wrote:
| 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.
| jeffbee wrote:
| 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.
| ajsnigrutin wrote:
| Infinitely large doesn't mean anything, when your disk
| space is limited.
|
| If your drive is 500GB, there is no practical difference
| between a 10TB log file a 10PB zip file or an infinite
| zip bomb... once the disk is full, the unzipping stops.
| jeffbee wrote:
| Narrowly true, except it's trivial to scan a very large
| archive without actually storing the entire thing,
| whereas if you tried to do the same thing with a zip
| quine you'll eventually run out of memory. Zip quines are
| strictly worse.
| tyingq wrote:
| 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.
| smoldesu wrote:
| 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.
| ikiris wrote:
| 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?
| usmannk wrote:
| What is xcow?
| [deleted]
| chedabob wrote:
| I think they might've meant xqcow
| https://en.wikipedia.org/wiki/XQc
| [deleted]
| phit_ wrote:
| looks like Discord is vulnerable to this too, oopsie
| jhgg wrote:
| We don't transcode video, so no.
| phit_ wrote:
| the player is malfunctioning anyway, similarly to those
| videos that report short runtime and then go on forever that
| get passed around quite frequently
| jhgg wrote:
| 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.
| LinuxBender wrote:
| 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.
| dapids wrote:
| "Hacking YouTube" is a stretch description ...
| amelius wrote:
| Yes:
|
| > To the best of my knowledge, the impact was rather low
| because their transcoders are setten up in such a way that they
| will eventually give up on file if it takes too many resources.
| [deleted]
| retox wrote:
| On some sites with a video duration limit that don't do
| transcoding, at least those that allow vp8 WEBM uploads, you can
| change a few bytes on the input to report a false duration and
| upload longer videos. If you're uploading audio only, with a
| static image, you can sometimes upload hours of audio before you
| hit the filesize limit.
| AtlasBarfed wrote:
| So it's basically a compression bomb? Like those small zip files
| that can expand to gigantic sizes?
| 0x000000001 wrote:
| 42.zip, yep. i have a copy if anyone wants it
| swyx wrote:
| never heard of this, TLDR on how it works?
| jffry wrote:
| From https://www.unforgettable.dk/ :
|
| "The file contains 16 zipped files, which again contains 16
| zipped files, which again contains 16 zipped files, which
| again contains 16 zipped, which again contains 16 zipped
| files, which contain 1 file, with the size of 4.3GB. So, if
| you extract all files, you will most likely run out of
| space :-)"
|
| Why recursively extract zip files? Well maybe a security
| tool is truing to inspect or process zip file contents
___________________________________________________________________
(page generated 2021-10-11 23:00 UTC)