5 ms·

Heap Overflow in FFmpeg EXIF

85 points by retr0reg 9mo ago

ComputerGuru 9mo ago
Nice find. (I don’t see what this being reported during the Christmas holidays has to do with not revealing the disclosure and patch timeline, a “note that delays should be attributed to Christmas” would have sufficed.)
rvz 9mo ago
> Pwno is a AI cybersecurity startup... We all know that LLMs were used to find these vulnerabilities, specifically on high impact projects. That's fine. However, my only question is who actually provided the patch: The maintainers of FFmpeg? The LLM that is being used? Or the security researchers themselves after finding the issue? It seems that these two statements about the issue are in conflict: > We found and patched 6 memory vulnerabilities in FFmpeg in two days. > Dec, 2025: avcodec/exif maintainer provided patch.
- 9cb14c1ec0 9mo ago
  > We all know that LLMs were used to find these vulnerabilities How do we know that? You seem quite certain.
  - hedgehog 9mo ago
    They pitch their company as finding bugs "with AI". It's not hard to point one of the coding agents at a repo URL and have it find bugs even in code that's been in the wild for a long time, looking at their list that looks likely to be what they're doing.
    - bgwalter 9mo ago
      The list is pretty short though for 8 months. ossfuzz has found a lot more even with the fuzzers often not covering a lot of the code base. Manually paying people to write fuzzers by hand would yield a lot more and be less expensive than data centers and burning money, but who wants to pay people in 2026?
      - hedgehog 9mo ago
        I can't speak to what exactly this team is doing but I haven't seen any evidence that with-robot finds less bugs than without-robot. I do have some experience in this area.
      - tptacek 9mo ago
        Bugs are not equivalently findable and different techniques surface different bugs. The direct comparison you're trying to draw here doesn't hold.
        bgwalter 9mo ago
        It does not matter what purported categories buffer overflows are in when manual fuzzing finds 100 and "AI" finds 5. If Google gave open source projects $100,000 per year for a competent QA person, it would cost less than this "AI" money straw fire and produce better results. Maybe the QA person would also find the 5 "AI" detected bugs.
        tptacek 9mo ago
        This would make sense if every memory corruption vulnerability was equivalently exploitable, which is of course not true. I think you'll find Google does in fact fuzz ffmpeg, though.
        bgwalter 9mo ago
        Google gives a pittance even for full ossfuzz integration. Which is why many projects just have the bare minimum fuzz tests. My original point was that even with these bare minimum tests ossfuzz has found way more than "AI" has.
        tptacek 9mo ago
        Another weird assumption you've got here is that fuzzing outcomes scale linearly with funding, which, no. Further, the field of factory-scale fuzzing and triage is one Google security engineers basically invented, so it's especially odd to hold Google out as a bad actor here. At any rate, Google didn't employ "AI" to find this vulnerability, and Google fuzzing probably wouldn't have outcompeted these researchers for this particular bug (totally different methods of bugfinding), so it's really hard to find a coherent point you'd be making about "fuzzers", "AI", and "Google" here.
- tredre3 9mo ago
  PWNO provided a patch but it was rejected for being too large[1]. A maintainer fixed it himself[2]. I don't know if PWNO used a LLM but it seems clear that the maintainer had a preferred specific style in mind so it was likely hand written (albeit inspired by the initial patch). 1. https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21258 https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21258 2. https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/4bfac71ecd96488dd2dcd5649e08edb039a17a8b https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/4bfac71ecd96488...
  - j1elo 9mo ago
    I just need to say that "commits" has been translated to Spanish as "confirmations" in that website, and it made me chuckle. Is Forgejo using LLM-assisted translations? Or simply somepne without any context whatsoever in order to understand the word's meaning? ---- EDIT: I went on a fun detour to inform myself better, and ended up finding [1] where Gitlab had the same discussion. Seems some translations have tried to use "confirmation" as translation for a git commit. But really, this is one of those cases where no local word is able to appropriately describe such an unique concept oridea. I'd love to retroactively chime in and confirm (hah) that the english word "Commit" has trascended any translation attempts, and absolutely nobody would know what you're talking about if you say "confirmation" in an attempt to use a spanish term. So Forgejo authors if you read this: it'd better to do as Gitlab did. [1]: https://gitlab.com/gitlab-org/gitlab/-/issues/215956 https://gitlab.com/gitlab-org/gitlab/-/issues/215956
renewiltord 9mo ago
Hmm interesting. You can see recent edits to the file here https://github.com/FFmpeg/FFmpeg/commits/master/libavcodec/exif.c https://github.com/FFmpeg/FFmpeg/commits/master/libavcodec/e... This specific issue is fixed here https://github.com/FFmpeg/FFmpeg/commit/4bfac71ecd96488dd2dcd5649e08edb039a17a8b https://github.com/FFmpeg/FFmpeg/commit/4bfac71ecd96488dd2dc...
- jeffbee 9mo ago
  Well, maybe it does and maybe it doesn't. Since this commit neither adds nor fixes any tests, we'll never know.
helge9210 9mo ago
https://x.com/FFmpeg/status/2006773495066464580 https://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.
- bgwalter 9mo ago
  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.
  - nospice 9mo ago
    > ... go into the official statistics. There are no "official" statistics. None of this matters. If we judged projects by the number of security holes they had, then no one would be using ffmpeg, which had hundreds of serious vulns. Vulnerability research is useful insofar that the bad guys are using the same techniques (e.g., the same fuzzing tools), so any bugs you squash make it harder for others to attack you. If your enemy is a nation state, they might still pack your laptop / phone / pager with explosives, but the bar for that is higher than popping your phone with a 0-day. Vulnerability research is demonstrably not useful for improving the security of the ecosystem in the long haul. That's where sandboxing, hardening, and good engineering hygiene come into play. If you're writing a browser or a video decoder in C/C++, you're going to have exploitable bugs.
    - toast0 9mo ago
      > Vulnerability research is demonstrably not useful for improving the security of the ecosystem in the long haul. That's where sandboxing, hardening, and good engineering hygiene come into play. If you're writing a browser or a video decoder in C/C++, you're going to have exploitable bugs. IMHO, vulnerability research is the stick that drives the ecosystem towards all those things. Reports of vulnerabilities in the codec for Rebel Assult videos (or whatever) leads one to disable codecs other than those they need. Reports of vulnerabilities in playlist support leads one to disable playlist support where it's unnecessary and run transcodes in a chroot sandbox with no network access. Reports of buffer oveflows leads one to prefer implementation in memory safe languages where available with sufficient performance and also to sandbox when possible.
M95D 9mo ago
What 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.
- viraptor 9mo ago
  > What does it even need EXIF for? Just bloated, unnecessary things like figuring out which colour space the image uses ;)
  - M95D 9mo ago
    What image? It's a video processor.
    - viraptor 9mo ago
      It's so much more than that. As one example, it's commonly used to split the video into image frames or merge images into a video. But it can compose static elements into the video stream as well.
rurban 9mo ago
So how is this a heap overflow in ffmpeg when it was only in the git version for 3 days? Nobody runs git master. And there tons of boring exif fuzzer cases fixed recently, because they use oss-fuzz: https://code.ffmpeg.org/FFmpeg/FFmpeg/commits/branch/master/search?q=Exif+&all= https://code.ffmpeg.org/FFmpeg/FFmpeg/commits/branch/master/...

85 points by retr0reg 9mo ago

Nice find. (I don’t see what this being reported during the Christmas holidays has to do with not revealing the disclosure and patch timeline, a “note that delays should be attributed to Christmas” would have sufficed.)

rvz 9mo ago

> Pwno is a AI cybersecurity startup... We all know that LLMs were used to find these vulnerabilities, specifically on high impact projects. That's fine. However, my only question is who actually provided the patch: The maintainers of FFmpeg? The LLM that is being used? Or the security researchers themselves after finding the issue? It seems that these two statements about the issue are in conflict: > We found and patched 6 memory vulnerabilities in FFmpeg in two days. > Dec, 2025: avcodec/exif maintainer provided patch.

9cb14c1ec0 9mo ago
> We all know that LLMs were used to find these vulnerabilities How do we know that? You seem quite certain.
- hedgehog 9mo ago
  They pitch their company as finding bugs "with AI". It's not hard to point one of the coding agents at a repo URL and have it find bugs even in code that's been in the wild for a long time, looking at their list that looks likely to be what they're doing.
  - bgwalter 9mo ago
    The list is pretty short though for 8 months. ossfuzz has found a lot more even with the fuzzers often not covering a lot of the code base. Manually paying people to write fuzzers by hand would yield a lot more and be less expensive than data centers and burning money, but who wants to pay people in 2026?
    - hedgehog 9mo ago
      I can't speak to what exactly this team is doing but I haven't seen any evidence that with-robot finds less bugs than without-robot. I do have some experience in this area.
    - tptacek 9mo ago
      Bugs are not equivalently findable and different techniques surface different bugs. The direct comparison you're trying to draw here doesn't hold.
      - bgwalter 9mo ago
        It does not matter what purported categories buffer overflows are in when manual fuzzing finds 100 and "AI" finds 5. If Google gave open source projects $100,000 per year for a competent QA person, it would cost less than this "AI" money straw fire and produce better results. Maybe the QA person would also find the 5 "AI" detected bugs.
        tptacek 9mo ago
        This would make sense if every memory corruption vulnerability was equivalently exploitable, which is of course not true. I think you'll find Google does in fact fuzz ffmpeg, though.
        bgwalter 9mo ago
        Google gives a pittance even for full ossfuzz integration. Which is why many projects just have the bare minimum fuzz tests. My original point was that even with these bare minimum tests ossfuzz has found way more than "AI" has.
        tptacek 9mo ago
        Another weird assumption you've got here is that fuzzing outcomes scale linearly with funding, which, no. Further, the field of factory-scale fuzzing and triage is one Google security engineers basically invented, so it's especially odd to hold Google out as a bad actor here. At any rate, Google didn't employ "AI" to find this vulnerability, and Google fuzzing probably wouldn't have outcompeted these researchers for this particular bug (totally different methods of bugfinding), so it's really hard to find a coherent point you'd be making about "fuzzers", "AI", and "Google" here.
tredre3 9mo ago
PWNO provided a patch but it was rejected for being too large[1]. A maintainer fixed it himself[2]. I don't know if PWNO used a LLM but it seems clear that the maintainer had a preferred specific style in mind so it was likely hand written (albeit inspired by the initial patch). 1. https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21258 https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21258 2. https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/4bfac71ecd96488dd2dcd5649e08edb039a17a8b https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/4bfac71ecd96488...
- j1elo 9mo ago
  I just need to say that "commits" has been translated to Spanish as "confirmations" in that website, and it made me chuckle. Is Forgejo using LLM-assisted translations? Or simply somepne without any context whatsoever in order to understand the word's meaning? ---- EDIT: I went on a fun detour to inform myself better, and ended up finding [1] where Gitlab had the same discussion. Seems some translations have tried to use "confirmation" as translation for a git commit. But really, this is one of those cases where no local word is able to appropriately describe such an unique concept oridea. I'd love to retroactively chime in and confirm (hah) that the english word "Commit" has trascended any translation attempts, and absolutely nobody would know what you're talking about if you say "confirmation" in an attempt to use a spanish term. So Forgejo authors if you read this: it'd better to do as Gitlab did. [1]: https://gitlab.com/gitlab-org/gitlab/-/issues/215956 https://gitlab.com/gitlab-org/gitlab/-/issues/215956

renewiltord 9mo ago

Hmm interesting. You can see recent edits to the file here https://github.com/FFmpeg/FFmpeg/commits/master/libavcodec/exif.c https://github.com/FFmpeg/FFmpeg/commits/master/libavcodec/e... This specific issue is fixed here https://github.com/FFmpeg/FFmpeg/commit/4bfac71ecd96488dd2dcd5649e08edb039a17a8b https://github.com/FFmpeg/FFmpeg/commit/4bfac71ecd96488dd2dc...

jeffbee 9mo ago
Well, maybe it does and maybe it doesn't. Since this commit neither adds nor fixes any tests, we'll never know.

helge9210 9mo ago

https://x.com/FFmpeg/status/2006773495066464580 https://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.

bgwalter 9mo ago
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.
- nospice 9mo ago
  > ... go into the official statistics. There are no "official" statistics. None of this matters. If we judged projects by the number of security holes they had, then no one would be using ffmpeg, which had hundreds of serious vulns. Vulnerability research is useful insofar that the bad guys are using the same techniques (e.g., the same fuzzing tools), so any bugs you squash make it harder for others to attack you. If your enemy is a nation state, they might still pack your laptop / phone / pager with explosives, but the bar for that is higher than popping your phone with a 0-day. Vulnerability research is demonstrably not useful for improving the security of the ecosystem in the long haul. That's where sandboxing, hardening, and good engineering hygiene come into play. If you're writing a browser or a video decoder in C/C++, you're going to have exploitable bugs.
  - toast0 9mo ago
    > Vulnerability research is demonstrably not useful for improving the security of the ecosystem in the long haul. That's where sandboxing, hardening, and good engineering hygiene come into play. If you're writing a browser or a video decoder in C/C++, you're going to have exploitable bugs. IMHO, vulnerability research is the stick that drives the ecosystem towards all those things. Reports of vulnerabilities in the codec for Rebel Assult videos (or whatever) leads one to disable codecs other than those they need. Reports of vulnerabilities in playlist support leads one to disable playlist support where it's unnecessary and run transcodes in a chroot sandbox with no network access. Reports of buffer oveflows leads one to prefer implementation in memory safe languages where available with sufficient performance and also to sandbox when possible.

M95D 9mo ago

What 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.

viraptor 9mo ago
> What does it even need EXIF for? Just bloated, unnecessary things like figuring out which colour space the image uses ;)
- M95D 9mo ago
  What image? It's a video processor.
  - viraptor 9mo ago
    It's so much more than that. As one example, it's commonly used to split the video into image frames or merge images into a video. But it can compose static elements into the video stream as well.

rurban 9mo ago

So how is this a heap overflow in ffmpeg when it was only in the git version for 3 days? Nobody runs git master. And there tons of boring exif fuzzer cases fixed recently, because they use oss-fuzz: https://code.ffmpeg.org/FFmpeg/FFmpeg/commits/branch/master/search?q=Exif+&all= https://code.ffmpeg.org/FFmpeg/FFmpeg/commits/branch/master/...