We're seeing a lot of incomplete or broken security fixes recently, across the board. Presumably this is leading to a lot of cheap bugs for attackers, who are generally going to be more incentivized to analyze patches than defenders are.
-
-
I can see that it's related, but most of the cases we've seen recently don't reach the level of complexity where it's clear that an additional N days of engineering time would have been the difference.
-
One of the options that we'd like to explore is being more involved in the patching process. We don't have a great level of engineer-to-engineer dialogue about this stuff, and we could be helping spot gaps early if we had more visibility.
-
I think involving researchers in the patch validation process is an interesting idea, but it does come with its own set of challenges. For example, if a researcher finds a variant or a bug in the fix, does that reset the disclosure clock (e.g. to ensure partial fix doesn't ship)?
-
It's up for discussion. Currently for broken fixes it would probably be considered the same finding, not a new bug report. Variants are trickier -- when does a bug become two bugs? Either way, the aim would be to surface concerns early enough that a timely fix is still practical.
-
Yep, agree on the aim. I think it raises an interesting question on which path creates more risk: shipping a fix that is known to be partial/buggy (that attackers might spot & exploit) vs. delaying disclosure for a complete fix (for an issue attackers might already be exploiting)
-
That may be a bit too close to the time-honored and much-loved tradition of disclosure debates on twitter, though. I definitely don't want to open that box of fun ;)
- End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.