7 ms·

I love it when vulnerabilities are publicly disclosed the moment they have patches. Now we all get to choose between patching them ourselves and manually managi

I love it when vulnerabilities are publicly disclosed the moment they have patches. Now we all get to choose between patching them ourselves and manually managing patches for the affected software from now on, or leaving them unpatched until the fixes eventually find their way downstream to us.

tptacek 9y ago
The alternative is to deprive people willing to manually manage patches of the ability to protect their networks, so that everyone can wait for people who don't take that level of responsibility over their networks to get a one-line installer. That's no alternative at all.
- eric_b 9y ago
  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.
- xyzzy_plugh 9y ago
  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.
  - 3pt14159 9y ago
    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.
    - thephyber 9y ago
      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.
      - 3pt14159 9y ago
        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.
    - zhengyi13 9y ago
      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.
      - 9y ago
- peterwwillis 9y ago
  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.
  - tptacek 9y ago
    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.
    - peterwwillis 9y ago
      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.
jlgaddis 9y ago
At least they were kind enough to wait until patches were available. Others sometimes aren't so kind.
- blacksmith_tb 9y ago
  They seem to have shipped Android security patches a little early as a result, I just flashed the October 5 2017 OTA on my Nexus 6P (in spite of it being October 2 and all).
deleted 9y ago
[deleted]
tedunangst 9y ago
Exploit developers don't wait until the vulnerability is announced. Pretending a critical bug fix is really no big deal until after people patch only gives them more time to exploit, because nobody will upgrade until they're told it's urgent. If then.
edoceo 9y ago
The patches are already committed to the git repo. There is very little burden for the sysadmin here.
johnbrodie 9y ago
Is there a real alternative? The patches themselves form as a notice, if anyone happens to be looking closely at the project. I'm sure a blog post widens the audience, but once the patches are public, the cat is out of the bag.
- 0x0 9y ago
  Sometimes, the oss community is able to coordinate patches through an embargo where the commits are hidden until major players have packages ready and staged. I wouldn't mind a 12-24 hour long embargo if that meant conveniently deployable upgrade patches were available when the issue is announced. 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?
  - tptacek 9y ago
    This is just hubris. It's not just that the embargoes leak like sieves --- and they do --- but also the baked-in assumption that if the Google security team is first to publish something, they must have been the first to find it.
    - 0x0 9y ago
      All I know is that I'll have to wait for the various *wrt distros to release updates, because setting up a cross compilation toolchain to build a patched firmware would take me longer than just waiting out for official updates. In the meantime it would've be swell if not every next-door script kiddie on the planet had a new toy in their hands...
      - tptacek 9y ago
        It takes you longer because you waited for a disaster before figuring out how to build your production dependencies from source. If your network isn't important and the only person you're putting at risk is yourself, this is fine. But our standards for people operating networks that other people's data depends on are too low. 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.

tptacek 9y ago

The alternative is to deprive people willing to manually manage patches of the ability to protect their networks, so that everyone can wait for people who don't take that level of responsibility over their networks to get a one-line installer. That's no alternative at all.

eric_b 9y ago
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.
xyzzy_plugh 9y ago
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.
- 3pt14159 9y ago
  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.
  - thephyber 9y ago
    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.
    - 3pt14159 9y ago
      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.
  - zhengyi13 9y ago
    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.
    - 9y ago
peterwwillis 9y ago
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.
- tptacek 9y ago
  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.
  - peterwwillis 9y ago
    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.

jlgaddis 9y ago

At least they were kind enough to wait until patches were available. Others sometimes aren't so kind.

blacksmith_tb 9y ago
They seem to have shipped Android security patches a little early as a result, I just flashed the October 5 2017 OTA on my Nexus 6P (in spite of it being October 2 and all).

deleted 9y ago

[deleted]

tedunangst 9y ago

Exploit developers don't wait until the vulnerability is announced. Pretending a critical bug fix is really no big deal until after people patch only gives them more time to exploit, because nobody will upgrade until they're told it's urgent. If then.

edoceo 9y ago

The patches are already committed to the git repo. There is very little burden for the sysadmin here.

johnbrodie 9y ago

Is there a real alternative? The patches themselves form as a notice, if anyone happens to be looking closely at the project. I'm sure a blog post widens the audience, but once the patches are public, the cat is out of the bag.

0x0 9y ago
Sometimes, the oss community is able to coordinate patches through an embargo where the commits are hidden until major players have packages ready and staged. I wouldn't mind a 12-24 hour long embargo if that meant conveniently deployable upgrade patches were available when the issue is announced. 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?
- tptacek 9y ago
  This is just hubris. It's not just that the embargoes leak like sieves --- and they do --- but also the baked-in assumption that if the Google security team is first to publish something, they must have been the first to find it.
  - 0x0 9y ago
    All I know is that I'll have to wait for the various *wrt distros to release updates, because setting up a cross compilation toolchain to build a patched firmware would take me longer than just waiting out for official updates. In the meantime it would've be swell if not every next-door script kiddie on the planet had a new toy in their hands...
    - tptacek 9y ago
      It takes you longer because you waited for a disaster before figuring out how to build your production dependencies from source. If your network isn't important and the only person you're putting at risk is yourself, this is fine. But our standards for people operating networks that other people's data depends on are too low. 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.