7 ms·

Can anyone explain to me the need to release the exploit information the same day as the patches?

by ar0b 10y ago

Retr0spectrum 10y ago
People would be able to reverse engineer the patches anyway.
- kittiepryde 10y ago
  Some people even managed to figure it out before the patches; doesn't mean we should expedite the release of exploits. Its gonna take more than a day for everyone to get patched.
  - Laaw 10y ago
    It makes the "hair on fire" nature of critical security vulnerabilities unavoidable. It's much easier to sell an outage to management if you can more easily demonstrate that anyone could have this exploit (which is true regardless).
  - eadz 10y ago
    "Bad Lock" - maybe there's a clue
    - daveloyall 10y ago
      Yep, sounds like a clue to me. "windows and samba" is a bigger clue. (See https://news.ycombinator.com/item?id=11337626 https://news.ycombinator.com/item?id=11337626 and/or the badlock website itself, first sentence...) As I see it, there are a couple options here... One: the bug is in the SMB protocol itself. Two: the bug is in some library code that is common to both Windows and Samba. (One and two could be the same thing, but they need not be.) Either way, coupled with the 'badlock' hint, I will be watching for some bright/lucky soul to find it before 20160412.
  - EdHominem 10y ago
    No. As an admin I'd rather have the details so I can make sure even my non-standard, non-patchable, fleet is safe. (Where I might need to implement custom firewall rules to inspect data for bad patterns, etc.) Once my coworkers and I protected our ISP's customers against a worm at the external boundary. If we'd only had the patch and some sanitized information to work from that would have rattled around our system for months until we'd harassed every customer to update and would have caused tons of harm in the meantime. I understand that in a make-believe scenario it'd be good to make sure bad-guys don't hear the info, but in a real-world scenario where you don't get to choose it's far better that the good guys have all the info even if a few more bad guys do to. And I say a few more because it's almost 100% certain that for every bug found there were attackers who knew about it beforehand. Also, as others have mentioned, for anyone skilled a patch reads like a changelog. When I see security patches I often read the patched code or do a bindiff/disassemble and try to spot the issue and I'm only a hobbyist. We might as well level the field and give everyone the info, not just the reverse-engineers. (Who disproportionally are on the "other" side.)
yurymik 10y ago
Usually it's other way around: patches are released on the day of the disclosure. Without firm date, companies have little to no incentive to fix the bug sooner (cough Adobe cough).

Can anyone explain to me the need to release the exploit information the same day as the patches?

by ar0b 10y ago

Can anyone explain to me the need to release the exploit information the same day as the patches?

Retr0spectrum 10y ago

People would be able to reverse engineer the patches anyway.

kittiepryde 10y ago
Some people even managed to figure it out before the patches; doesn't mean we should expedite the release of exploits. Its gonna take more than a day for everyone to get patched.
- Laaw 10y ago
  It makes the "hair on fire" nature of critical security vulnerabilities unavoidable. It's much easier to sell an outage to management if you can more easily demonstrate that anyone could have this exploit (which is true regardless).
- eadz 10y ago
  "Bad Lock" - maybe there's a clue
  - daveloyall 10y ago
    Yep, sounds like a clue to me. "windows and samba" is a bigger clue. (See https://news.ycombinator.com/item?id=11337626 https://news.ycombinator.com/item?id=11337626 and/or the badlock website itself, first sentence...) As I see it, there are a couple options here... One: the bug is in the SMB protocol itself. Two: the bug is in some library code that is common to both Windows and Samba. (One and two could be the same thing, but they need not be.) Either way, coupled with the 'badlock' hint, I will be watching for some bright/lucky soul to find it before 20160412.
- EdHominem 10y ago
  No. As an admin I'd rather have the details so I can make sure even my non-standard, non-patchable, fleet is safe. (Where I might need to implement custom firewall rules to inspect data for bad patterns, etc.) Once my coworkers and I protected our ISP's customers against a worm at the external boundary. If we'd only had the patch and some sanitized information to work from that would have rattled around our system for months until we'd harassed every customer to update and would have caused tons of harm in the meantime. I understand that in a make-believe scenario it'd be good to make sure bad-guys don't hear the info, but in a real-world scenario where you don't get to choose it's far better that the good guys have all the info even if a few more bad guys do to. And I say a few more because it's almost 100% certain that for every bug found there were attackers who knew about it beforehand. Also, as others have mentioned, for anyone skilled a patch reads like a changelog. When I see security patches I often read the patched code or do a bindiff/disassemble and try to spot the issue and I'm only a hobbyist. We might as well level the field and give everyone the info, not just the reverse-engineers. (Who disproportionally are on the "other" side.)

yurymik 10y ago

Usually it's other way around: patches are released on the day of the disclosure. Without firm date, companies have little to no incentive to fix the bug sooner (cough Adobe cough).