Heap Overflow in FFmpeg EXIF
31–36 of 36 posts
Re: Heap Overflow in FFmpeg EXIF
#32What does it even need EXIF for? Or any image formats other than (M)JPEG? This is a typical example of how bloatware increases security risks.
Just bloated, unnecessary things like figuring out which colour space the image uses ;)
Re: Heap Overflow in FFmpeg EXIF
#33https://x.com/FFmpeg/status/2006773495066464580 > Seeing as this has made the orange site, let it be known this person is a model security researcher. > The issue was not in any FFmpeg release, and a report was sent three days after a new code was added to FFmpeg Git. > There was no big CVE ADVISORY "MUH SECURITEH" "you need to fix this now or you will be hacked and the world will end" associated with the report.
This is another drawback of security research, but one that had already existed before "AI" with ossfuzz. You basically cannot commit in public to the main branch and audit and test everything 3 months before a release, because any error can be picked up, will be publicized and go into the official statistics.
Re: Heap Overflow in FFmpeg EXIF
#34What does it even need EXIF for? Or any image formats other than (M)JPEG? This is a typical example of how bloatware increases security risks.
> What does it even need EXIF for? Just bloated, unnecessary things like figuring out which colour space the image uses ;)
Re: Heap Overflow in FFmpeg EXIF
#35Earlier quoted context omitted.
> What does it even need EXIF for? Just bloated, unnecessary things like figuring out which colour space the image uses ;)
What image? It's a video processor.
Re: Heap Overflow in FFmpeg EXIF
#36And there tons of boring exif fuzzer cases fixed recently, because they use oss-fuzz: https://code.ffmpeg.org/FFmpeg/FFmpeg/commits/branch/master/...