Vulnerability Research Is Cooked (sockpuppet.org)

It's not much different from what we're doing, and due to the high volume we can only triage now. Syzbot reports are systematically redirected to public lists, all the stuff that doesn't represent an immediate risk of escalation but might only be used to lower some barriers (e.g. local kASLR defeats) or stuff that's outside the threat model gets the same fate, and the rest is often challenged a bit (e.g. unclear or too old version, dubious claims etc), we ask for patches and most of the time the reporters are interested in helping and they do their final share of the work, then we forward to maintainers and try to help both to get the issue fixed and merged ASAP. Many reporters are not familiar with processes, and it's the same for maintainers getting begged for the first time. It's extremely rare these days that issues are attempted to be resolved within the list (except if the maintainer is already there) as all subsystems are willing to participate to the resolution now, so the fixes are super fast, in a matter of days you can count on a single hand most of the time, which would make embargoes totally pointless anyway and even counter-productive.

> The previous approach, with the desire to have fixes available at the time of disclosure (with or without embargo/grace period for distributions) does not seem to work anymore. It doesn't encourage community collaboration, and it paves the way for rather extreme forms of freeloading.

I totally agree. And the only way it makes sense is when there's a risk of remote exploitation (e.g. RCE) but then it keeps users exposed longer, which is against the initial goal. Also this doesn't take into account the different levels of exposure of different classes of users due to different use cases. On the kernel, with a release every week, it's best to just merge and release. OpenSSL for example does one thing well, since they don't release often, they often indicate upfront that a fix is going to be released a few days later so that users can get prepared to downloading the fix and deploying. In haproxy as well we're going away from embargoes. We keep them only for critical stuff that affects common deployments with no reasonable workaround (e.g. about once a year or so), and we leave two or three days to some high profile users to deploy a fix and to distros to prepare packages. Each time it remains confusing for everyone involved and the risk of mistake remains high, so the least often the better. BTW it's well known that embargoed issues generally need two fixes: the first one which works on the reporter and the developer's machine, and the second one which fixes regressions in the field.

That's an incorrect simplification. A significant number of Linux developers are:
- virulently opposed to _proprietary_ tools (Bitkeeper etc). Understandable.
- virulently opposed to centralized tools / SPOF. Understandable.
- resistant to spending a lot of time dumping their existing tools and learning brand new ones. Like everyone else.

This can all give the impression that they are opposed to "modern" workflows. But they are not opposed to automated checks, new tools and evolution in general. Examples:
- https://lore.kernel.org/lkml/?q=0day
- https://lwn.net/Articles/1063303/ b4
- https://lwn.net/Articles/1064830/ Sashiko.

My home setup has two Radeon GPUs with 64Gb VRAM in total, and it can run models that produce adequate results with reasonable speed. Top-of-the line inference accelerators use about 1000W of power and have ~300Gb of VRAM, they can comfortably run quantized models just on one chip. The amortized cost of the complete inference system is around $30k per chip (~1 concurrent user).

If we spread this over 5 years of use, that's $500 per month. If you're using it 10% of the time, that's around $50 per month cost, which is in line with many AI subscriptions. And one thing we learned from the history of semiconductors is that this number will likely rapidly decrease.

I don't expect inference tokens to become scarce any time soon. Companies may clamp down on the totally free use, but I don't expect it to become a luxury good.

(And sure, you can write e.g. Rust code that doesn't panic, because you always use the try_ methods and always do proper error handling - but that puts the burden on the developer to write good code, which is kind of the point here, because we wouldn't need Rust if everybody could and would write excellent C code. ;-))

> > And there are a lot of classes of bugs that a memory-safe language doesn't even address
> Obviously, nobody said otherwise.
But people keep _implying_ otherwise. Read the article - it talks about the number of vulnerability reports, and then _implied_ the way it was written that once we've moved to memory-safe languages we'll not have this problem anymore, and that techniques such as sandboxes are a stop-gap measure until we've arrived there.

And precisely _that_ implication that I've seen many, many times is what I'm arguing about.

I'm **not** saying memory safety is superfluous, I'm just saying that I'm constantly seeing the _implication_ that it will solve all of our problems, which it won't.

> But that does not mean removing memory safety issues and preventing UB in general is not worth it.
I don't disagree with that statement, in fact I did agree in my posting beforehand.

> [...] e.g. one can employ a good type system to good effect.
I also completely agree with this - but that then puts the burden again on the programmers to write good code, and there's no enforcement by the language that they _have_ to do so. (And I don't think you could design a language that enforces this properly anyway.)

> > And in release builds Rust doesn't enable integer overflow panics.
> Yes, but it is configurable, e.g. in Linux we provide a Kconfig option for users and, by default, they are enabled.
But outside of the kernel I haven't seen this used in practice. (I'm sure you can point to some individual examples, but it's not the default.)