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.
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.
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.
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.
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.
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.
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.
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 would be preposterous reasoning if it weren't overwhelmingly normalized in our industry. It's an embarrassment for the whole field.
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.
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.
Especially for a LAN-only type issue like this - unlikely that someone trusted with the embargo would go blackhat LAN-side here during the wait, but now every script kiddie in the world has the knowledge to make a mess while we're still awaiting vendor patches?
I don't want to single you or anyone else out about this because it's a universal problem among startups. But that doesn't make it close to OK.
I generally don't have an issue with the security decisions of people who don't know better. I do have a problem with people who should know better and essentially refuse to because of cost and convenience and availability concerns. Security should trump availability most of the time, but almost never does in our industry. That is messed up.