5 ms·

Pretty unimpressive as security vulnerabilities. It would be better to just say these are simple bugs for the most part.

unnouinceput 3mo ago
all vulnerabilities are just bugs.
- stonogo 3mo ago
  But not the other way around, which makes them different.
  - void-star 3mo ago
    Actually, Mudge of the l0pht (and later DARPA) once famously made the claim that all bugs are security issues waiting to be exploited in some way (I’m probably paraphrasing). I kind of agree. Although, the bugs on this dump are indeed mostly pretty lame, which is exactly what I’ve seen you get a lot of when you let an llm go bug hunting with no human vetting and confirmation in the loop. It’s possible/likely that whomever is running this experiment is keeping the non slop bugs to themselves. It’s probably what I’d do.
    - stonogo 3mo ago
      Such claims can both be true and pointless. For those of us who have to decide what actions to take, there is a point in differentiating between bugs and vulnerabilities, and breathlessly proclaiming "we found a vulnerability but we don't have an exploitation vector or proof that there's a meaningful security consequence" is annoying and likely to get the proclaimer ignored in the future.
      - void-star 3mo ago
        The context in which that statement was made, and in which I’m repeating it, I think, is just to say that any bug has the potential to be used maliciously. Ignore it, fine, but also don’t overreact to the intended message…
        stonogo 3mo ago
        Phrased this way, nothing changes: both true and irrelevant. In other words, any action taken in response to this message is an overreaction. It's just noise.
        necovek 3mo ago
        It is mostly meaningless and tautological claim: even every non-buggy feature of a software system has the potential to be used maliciously; a working system itself too. Yes, maliciously used features should sometimes drive change (eg. in how to reduce or reduce impact of social engineering attacks), but as a claim it has no value.
    - ok123456 3mo ago
      Peiter Zatko profits, personally and professionally, from conflating the two. Making such bold pronouncements is a way for him to stay relevant. Also, I've known some thoroughly unimpressive people who have affiliated themselves with DARPA. I wouldn't use it as an appeal to authority.
- GTP 3mo ago
  Vulns are a subset of bugs. What the above commenter is saying, is that some bugs don't belong to this category.
- wavemode 3mo ago
  No, not all vulnerabilities are bugs. "Bug" implies a system working in a way its creators did not intend, but a system can be working exactly as intended yet have a vulnerability. For example, if you allow weak passwords, then you have a trivial vulnerability to people guessing other people's passwords. But nothing about the login system is working differently from how anyone intended. It's just that the intentions themselves were naïve.
newguy33 3mo ago
I disagree. That FFmpeg code execution is absolutely nasty
- albroland 3mo ago
  Maybe I'm missing something but the ffmpeg buffer "exploit" involves passing a custom exploited buffer callback to parse a RASC file that presumably has been crafted to contain a packet that can exploit the custom buffer passed in? I don't see how this would be used in practice in the wild as to achieve the first step (custom buffer invocation) would require you to already have access to the machine to even invoke ffmpeg with it? Like yes there is a heap OOB issue in an incredibly old file format, but without already having arguably compromised access to a machine, exploiting it for RCE seems impossible?
  - breadwinner8 3mo ago
    The 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.
    - albroland 3mo ago
      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.

unnouinceput 3mo ago

all vulnerabilities are just bugs.

stonogo 3mo ago
But not the other way around, which makes them different.
- void-star 3mo ago
  Actually, Mudge of the l0pht (and later DARPA) once famously made the claim that all bugs are security issues waiting to be exploited in some way (I’m probably paraphrasing). I kind of agree. Although, the bugs on this dump are indeed mostly pretty lame, which is exactly what I’ve seen you get a lot of when you let an llm go bug hunting with no human vetting and confirmation in the loop. It’s possible/likely that whomever is running this experiment is keeping the non slop bugs to themselves. It’s probably what I’d do.
  - stonogo 3mo ago
    Such claims can both be true and pointless. For those of us who have to decide what actions to take, there is a point in differentiating between bugs and vulnerabilities, and breathlessly proclaiming "we found a vulnerability but we don't have an exploitation vector or proof that there's a meaningful security consequence" is annoying and likely to get the proclaimer ignored in the future.
    - void-star 3mo ago
      The context in which that statement was made, and in which I’m repeating it, I think, is just to say that any bug has the potential to be used maliciously. Ignore it, fine, but also don’t overreact to the intended message…
      - stonogo 3mo ago
        Phrased this way, nothing changes: both true and irrelevant. In other words, any action taken in response to this message is an overreaction. It's just noise.
      - necovek 3mo ago
        It is mostly meaningless and tautological claim: even every non-buggy feature of a software system has the potential to be used maliciously; a working system itself too. Yes, maliciously used features should sometimes drive change (eg. in how to reduce or reduce impact of social engineering attacks), but as a claim it has no value.
  - ok123456 3mo ago
    Peiter Zatko profits, personally and professionally, from conflating the two. Making such bold pronouncements is a way for him to stay relevant. Also, I've known some thoroughly unimpressive people who have affiliated themselves with DARPA. I wouldn't use it as an appeal to authority.
GTP 3mo ago
Vulns are a subset of bugs. What the above commenter is saying, is that some bugs don't belong to this category.
wavemode 3mo ago
No, not all vulnerabilities are bugs. "Bug" implies a system working in a way its creators did not intend, but a system can be working exactly as intended yet have a vulnerability. For example, if you allow weak passwords, then you have a trivial vulnerability to people guessing other people's passwords. But nothing about the login system is working differently from how anyone intended. It's just that the intentions themselves were naïve.

newguy33 3mo ago

I disagree. That FFmpeg code execution is absolutely nasty

albroland 3mo ago
Maybe I'm missing something but the ffmpeg buffer "exploit" involves passing a custom exploited buffer callback to parse a RASC file that presumably has been crafted to contain a packet that can exploit the custom buffer passed in? I don't see how this would be used in practice in the wild as to achieve the first step (custom buffer invocation) would require you to already have access to the machine to even invoke ffmpeg with it? Like yes there is a heap OOB issue in an incredibly old file format, but without already having arguably compromised access to a machine, exploiting it for RCE seems impossible?
- breadwinner8 3mo ago
  The 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.
  - albroland 3mo ago
    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.