I agree. I used to be the sole maintainer of a small Linux distribution for my employer (only a side-project, responsibility wise). This was a Fortune 50 company. I'd often have patches applied and new versions released within hours. It's very easy to do. Usually by the time someone else in the office found out, it had been patched long ago. And I'd like to be clear that I am not actively subscribed to any lists, I just casually find these issues by reading where other professionals write, often. And lo, we were more up to date than most other companies.

Sure, we were vulnerable for a brief window, and without a doubt there were other vulnerabilities, but we were pretty much as safe as possible, let alone for a half-person team.

You just don't leave windows broken. You don't leave the holes unfilled. If you find a crack in the foundation, you fix it. To do otherwise is not only irresponsible to your peers and employer, but to your customers.

My only criticism is that often the roles responsible for such things are unpleasant, come with little respect, visibility and/or pay. Companies should just suck it up and overpay a handful of engineers and security specialists, charged with the responsibility of ensuring the company avoids being vulnerable. Think of it as insurance -- it's worth far more than a bad press cycle or having your customers exploited and rightful loss of trust. The bang for your buck is off the charts.

Executives don't realize that it can end a company until it does. Apple gets it. Google gets it. Facebook gets it. But very few other companies do. Cyber vulnerabilities killed Nortel back in the day. Huawei got not just designs, but details about bids, key people, everything.

Maybe 5-10 years ago companies didn't realize it. I think every major corporation has started to consider that kind of scenario now. Smaller companies may still delude themselves into thinking they aren't targets, but they probably are much less capable than big companies of investing in the required preparations to prevent those attacks.

The "black swan" events aren't costless to mitigate. In fact, they are extremely expensive. And just like there can be a black swan for cyberattacks, there can be a black swan like a terrorist attack (like companies in World Trade Center Towers 1 and 2), a massive natural disaster (think businesses in Puerto Rico right now), massive electrical outages (say an EMP or simply just Enron malfeasance), etc.

Spending to protect against and mitigate all possible black swans approaches infinity and doesn't every pay off until the extremely rare but extremely impactful event ever happens. And in cyber security, you never know because your defenses prevented it before it ever started.

If they were doing as you describe they would at the very least keep their versions of Windows updated and they would enable things like two-factor authentication and TLS for their email. They don't. We're not talking expensive to prevent black swan, we're talking routine defences against white swans.

Has this been written about anywhere? If there's a document that covers this as a case of industrial espionage, I'd love to read it.

Yes. Read the book Cyberspies it covers this and other events.

> Companies should just suck it up and overpay a handful of engineers and security specialists, charged with the responsibility of ensuring the company avoids being vulnerable. Think of it as insurance -- it's worth far more than a bad press cycle or having your customers exploited and rightful loss of trust. The bang for your buck is off the charts.

While my gut agrees with your proposal, my brain tells me that simply patching doesn't fix either the most common issues (basic fraud, phishing, social engineering, malicious insider, etc) or the most dangerous issues (infected supply chain, zero days, etc).

Companies will still pay for insurance because your proposal doesn't insure against those other scenarios, so they will see insurance as a crutch which mitigates some of the costs which come with unpatched vulns and the race to patch.

Of course, I'm not saying that you don't need to handle all those things -- you do. You have to have insurance, and anti-fraud departments, etc.

But compared to the costs associated with insurance or damage control, having a small team of security minded people that can make changes is basically free.

If the vuln was public before the patch, sure, get patches out asap. If the vuln is not public, wait to get downstream vendors to generate packages based on unrelease patches, and then release everything at once. This should be the de-facto stance for almost all vuln disclosure.

One line installers are the difference between a 3-day mitigation and a 3-hour mitigation. Sometimes the difference is in weeks.

It's definitely not about who "takes that level of responsibility" to patch manually, it's about what's operationally feasible. Dnsmasq is probably the widest deployed networking service for consumer devices. Now every consumer device running an old version, which includes Linux desktops, Android devices, home internet routers, etc are vulnerable. They even state how big the problem is in the release:

  This software is commonly installed in systems as varied as desktop
  Linux distributions (like Ubuntu), home routers, and IoT devices.
  Dnsmasq is widely used both on the open internet and internally
  in private networks.

On top of the wide-spread severity of this issue, they've included PoC code. It's like they want everyone to get owned.

How do they know whether the vulnerability is public or not? There's no way to know. Repeated discovery --- or even simultaneous discovery --- of vulnerabilities is common. People who abuse vulnerabilities don't publish them, so there's no way to be sure something isn't being actively exploited.

Meanwhile, as soon as you publish a vulnerability, responsible network owners can make integrity vs. availability tradeoffs, even without manually managing a patch. Somehow, as an industry, we've come to the conclusion that nobody can shut a service off, even in response to a lethal security vulnerability. Better that we risk our customers data than violating an SLA. That's messed up.

If nobody has announced it, and there are no known exploits in the wild, it's not public. It could be available on 0day marketplaces, but that doesn't mean it is being widely used. It's probably less likely to be widely used if it's a valuable 0day.

But this isn't about shutting off a service to protect a company's bottom line. This is a vuln affecting consumer devices. SLA has nothing to do with it. People's home networks and devices, not to mention a myriad number of embedded devices and sensors all over the world, are going to be affected by this - not corporations protecting customer data. Affected consumers have no means to patch themselves. Releasing this before vendors could generate patched packages or firmware is just monumentally irresponsible.

This is ostrich logic. With our heads comfortable buried in the sand we don't have to consider that we're routinely being owned up by vulnerabilities Google hasn't yet published (we are, by the way). Not only that, but when Google does get around to publishing a vulnerability, we're not even obliged to patch it ourselves; rather, we blame Google for publishing.

This would be preposterous reasoning if it weren't overwhelmingly normalized in our industry. It's an embarrassment for the whole field.

I'm not against people patching things themselves. But my grandmother can't apply patched source code to the firmware for her Belkin cable modem. And I sure as hell can't patch the firmware for my carrier's locked Android phone. My Smart TV is probably just fucked. If these vendors were contacted before release, they may be able to keep people safe at publishing time.

What you seem to be suggesting is that we should simply all disconnect from the internet until vendor patches can be prepared, the reason being it's better to stop any potential and unknown exploits going on now, than stop the hundred-fold new exploits that absolutely will follow its public announcement.

> If these vendors were contacted before release, they may be able to keep people safe at publishing time.

You mean if hundreds of the popular vendors were notified for a coordinated release? And you think that's not making the exploit effectively public? Even skipping possible monitoring of emails, I don't expect that the set of blackhats and employed security engineers have no common elements.

Good point. Does that mean there should be zero coordination? What about coordinating with the security teams for a few big Linux distributions? That would be a much smaller list of people, and might make it easier/quicker for some commercial vendors to get fixed once the public announcement is made.

The problem is that we don't have any laws forcing vendors to keep their products (smartphones, TVs, embedded (networking) devices up to date. It's high time to change that.

Security people like to paint this as a binary choice, then inevitably siding with "disclose immediately". But it's not really is it?

Why do we put locks on our doors? It's not so that career hardened cat burglars can't get in - it's to prevent crimes of opportunity and small time crooks from getting an easy target.

I feel like there's an analog with software. Quietly commit fixes for the RCEs to DNSMasq. Those who care will stay on the latest version. You can even say "Fixes security issues" in the release notes. But, wait awhile to release the PoCs and detail the exploits completely.

The nation states will find a way to exploit it no matter what, of course. But you average cybercriminal will have a much harder time without PoCs clearly showing the attack vector.