Hacker News Reader

Comment by ok123456 | Hacker News Reader

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

View on HN

I disagree. That FFmpeg code execution is absolutely nasty

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?

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.

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.

Apparently nobody cares. A few days ago I bumped-into and submitted this: https://news.ycombinator.com/item?id=48655747 . I thought given the general trust people seem to place in media files it would have raised a few eyebrows but it did not ̄\_(ツ)_/ ̄

all vulnerabilities are just bugs.

But not the other way around, which makes them different.

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.

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.

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…

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.

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.

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.

Vulns are a subset of bugs. What the above commenter is saying, is that some bugs don't belong to this category.

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.

Reply on news.ycombinator.com