Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking YouTube with a MP4

realkeyboardwarrior.github.io

Post reply on HN
Print view View original

21–30 of 94 posts

Re: Hacking YouTube with a MP4

#21

Post by ajsnigrutin »

jeffbee wrote: post #17
ajsnigrutin wrote: post #12

Earlier quoted context omitted.

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.

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.

Re: Hacking YouTube with a MP4

#22

Post by jeffbee »

ajsnigrutin wrote: post #21
jeffbee wrote: post #17

Earlier quoted context omitted.

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.

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.

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.

Re: Hacking YouTube with a MP4

#24

Post by amelius »

dapids wrote: post #15

"Hacking YouTube" is a stretch description ...

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.

Re: Hacking YouTube with a MP4

#26

Post by DrewRWx »

ndesaulniers wrote: post #8
smoldesu wrote: post #2

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.

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 libstage…

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.

Re: Hacking YouTube with a MP4

#27

Post by dylan604 »

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.

Re: Hacking YouTube with a MP4

#28

Post by kmeisthax »

dylan604 wrote: post #27

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 affe…

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.

Re: Hacking YouTube with a MP4

#30

Post by usmannk »

ikiris wrote: post #14
smoldesu wrote: post #7

Earlier quoted context omitted.

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?

What is xcow?
Post reply on HN