Summarizer

> based on the unquestioned premise that delaying disclosure for the operational convenience of system administrators is a good thing. There are reasons to question that premise! Care to mention these reasons? With "convenience of system administrators", I'm guessing you mean that there's a patch available that sysadmins can install, ideally before the vulnerability is disclosed? What else are sysadmins supposed to do, in your opinion? Fix the vulnerability themselves? Or simply shutdown the servers? With the various copyfails of recent, it at least was possible to block the affected modules. If that were not the case, what would you have done, as a sysadmin?

Choose to take an availability hit rather than risk a breach.

Presumably you also have positive downstream effects in mind: when "taking the availability hit" feels like more of a live choice, operators feel the pain of running insecure designs more. Do what you describe a couple times, and you'll naturally start thinking things like "dammit, we need to finally get away from shared kernels; this is insane", "maybe we should figure out a way to do this that doesn't involve running software that runs in God mode", or even "we should see what it takes to port our application to a platform that is more secure by design". When you can't imagine or pretend that when a major vuln is disclosed (a) you've been secure up until the point of disclosure or (b) all you need to do now is apply a patch without thinking too much about what your blast radius just was, you might actually have stronger incentives to think about the design of the overall system so that when similar issues come up, you can avoid having to sweat those outages. It's interesting that "defense-in-depth" gets cited and repeated all the time but the standard attitude about patching still seems to be "what do you mean?? isn't patching the only thing we can do?". How about designing systems so that you can more quickly and easily throw up other kinds of mitigations when you need to? What about designing systems with robust enough notions of graceful degradation that when something crops up for a certain feature you can "just" say "okay, let's turn only that part off for a couple days"? How about getting really, really good at CI/CD so you can more confidently add and deploy mitigations to your application code, or redeploy with a feature flag that lets you temporarily drop an unpatched-and-vulnerable dependency? If you can manage to build a system without the assumption that just patching is always on the table, you might simply end up with better software , which would be pretty cool.

"Taking an availability hit" is also an "in the limit" case that mostly serves to illustrate the falsity of "disclose or patch" as a binary. Much more commonly: a fully disclosed vulnerability arms systems teams with enough information to mitigate; pull kernel modules, change permissions, that sort of thing.

Maybe some corporations like the "just patch" playbook because it takes less skill to execute or articulate. It might be as much a deprofessionalizarion/commoditization of labor thing as much as anything else.

With "availability hit" I'm assuming you mean to simply stop operations until patches are rolled out, so possibly for days? That would at least explain what's happening at GitHub...

Many vulnerabities seem to be in code paths for rarely used features. They can often be disabled.

You’re obviously one of the most knowledgeable people on this topic around here. What would the best solution be? And where do you believe the industry is headed (which may very well be something other than the best solution) ? I can’t think about anything other than improving operations, but given the state of the industry, this seems like a pipe dream.

We could get somewhere where clouds can provide a framework of secure primitives that act as a framework. E.g. you build an app, it stores data via api etc. etc. You can test in sandbox. The cloud deploys for customer who paid you via that cloud and you work at arms length. You may not even know their name. You just get the pro subscription fees. The idea bubbling in my head would be an app store for cloud products. But with competition i.e. you use Railway or Heroku or AWS for the best deal. Be gentle this is an idea in my head I am sure it can be torn down by a retort at this stage. But this exists in forms and I think it will emerge. It is inversion of control at the entire app level. This is similar to buying a hammer. If you make hammers you sell them to a store, the store knows the customer and only the customer can see the nails.

Since the exploit can be mitigated by simply blacklisting the AF_ALG module, why didn’t they release an advisory to disable the problematic module (which AFAIU is hardly used), and then only later, say after a week, release the patch for it? At least then you would have the immediate ability for a mitigation without giving away exactly how to exploit the bug.

It sounds to me like the safe assumption with software is that no matter how solid your stack is, there are vulnerabilities, potentially catastrophic. A question to folks more experienced than me - if my business depends on software, and I know that my software is almost certainly exploitable, how do I posture my business in such a way as to minimize the impacts of exploits like these?

When Windows was the predominant desktop OS in the 90s and maybe early 00s (ok, maybe still is), it was so badly insecure that you could be pretty much sure that it would be easy to compromise. That's when firewalls were widely deployed to provide some layer of protection. So you can ask yourself, what is the (possibly metaphorical) firewall in the software you depend on? Is there any way you can decrease attack surface, separate out the most important data in extra-secure (and thus less accessible) systems?

Perimeter defense is outdated. AI changes the attack surface from network edges to the data pipeline itself. We need to securing the prompt, the model, and the data.

On the other hand, automated fast rollouts leads to a crowdstrike type situation where you brick all the computers of the world immediately. Imo we are going to have to rely on more layers of security. Systems that are designed to be secure even in the presence of individual vulnerabilities. This has already been happening for a while on mobile platforms and game consoles. Even physical hardware designed to keep particular secrets /keys even from the kernel.

The crowdstrike situation wasn't due to fast rollouts, it was due to a total lack of testing. You can do fast rollouts, with testing, and a mandatory QA signoff. It's called 'continuous delivery' rather than 'continuous deployment'. I actually don't think more layers of security will fix this. It would be nice if our systems were more secure... but people are, if nothing else, lazy af. Even when adding security isn't a lot of work, people resist it if it "sounds complicated". So I think we're stuck with the status quo. But the big issue now isn't novel bug types, it's the speed in which they're found. Therefore we need to speed up our response.

Lack of care, slip ups, and bugs are basically a constant that will always exist. But we can architect systems which are secure even in the face of bugs. Multiple layers of security mean that even the most critical kernel bug in iOS can never extract your faceid data or encryption key because the hardware physically isn’t capable of it. OSs like Qubes utilise multiple VMs so any kernel bugs have limited reach. When you look at consoles, they have built software that is resistant to outright glitching the CPU.

How would you apply this logic to something like https://meltdownattack.com ? The vulnerability was in hardware, discovered by companies that make user level software, and mitigated by changes to OS kernels.