alt Hacker NewsThe custom get_buffer2 path is not something the attacker needs shell access to invoke. It is a normal public libavcodec API used by applications embedding FFmpeg. The attacker’s input is still just the crafted RASC/AVI media. The target application invokes FFmpeg/libavcodec during normal media processing. The PoC uses a custom buffer provider to make the heap layout deterministic and to place a demonstrable callback pointer next to the decoded PAL8 plane. That proves the bug can redirect control flow in a valid libavcodec decode flow. It does not mean the exact same file will pop calc under stock ffmpeg -i everywhere, but definitely not impossible. I popped a few shells today with it on a few websites for testing purposes. Reported it to them all, of course.
I'm sorry but again, I dont see how an 4 byte OOB write will realistically lead to RCE without the custom buffer in the POC that explicitly puts a function pointer directly where the overflow happens, then invokes it.
I'm happy to be shown what I'm missing but this seems like a memory corruption bug, not RCE, and if it was feasible w/o the custom buffer then why not provide that as the example? In the real world, a ffmpeg invocation would use the default buffer handler that will use padding/alignment/etc that makes the heap even less predictable, and incredibly unlikely to have a function pointer exactly following the frame buffer that will deterministically be invoked by a process placing it there?
It seems very far fetched.