3 ms·

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

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.
      - 0x0 9y ago
        I think it is unreasonable to expect every semi-public coffeeshop style wifi to be operated by someone manually compiling and curating patches for the router firmware every time a vulnerability surfaces. An embargo would have kept a lot of users safer because their neighborhood script kiddies wouldn't be able to go on a hacking spree. I don't think a 12-24 hour delay coordinating patches with vendors would matter for the case where a select few elite blackhats were sitting on the same bug, because they most likely have had the bug for months or years already.
        tptacek 9y ago
        I don't expect it of coffee house wireless operators, at all. If some startup comes into being that manages those wireless networks for the coffee shops, I will very much expect it of them. 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.
        0x0 9y ago
        Agreeing on those points :)

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.
    - 0x0 9y ago
      I think it is unreasonable to expect every semi-public coffeeshop style wifi to be operated by someone manually compiling and curating patches for the router firmware every time a vulnerability surfaces. An embargo would have kept a lot of users safer because their neighborhood script kiddies wouldn't be able to go on a hacking spree. I don't think a 12-24 hour delay coordinating patches with vendors would matter for the case where a select few elite blackhats were sitting on the same bug, because they most likely have had the bug for months or years already.
      - tptacek 9y ago
        I don't expect it of coffee house wireless operators, at all. If some startup comes into being that manages those wireless networks for the coffee shops, I will very much expect it of them. 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.
        0x0 9y ago
        Agreeing on those points :)