7 ms·

My thinking would be exactly the opposite - severe bugs have to be disclosed sooner while non-severe can be left lingering around.

by cesis 8y ago

eganist 8y ago
And Google has actually had a track record of using that reasoning as well, so it's not like their words actually mean much. Great example of a drive-by high-sev exploit getting exposed long before Microsoft could patch: https://www.digitaltrends.com/computing/google-project-zero-publishes-microsoft-browser-zero-day-bug/ https://www.digitaltrends.com/computing/google-project-zero-... I appreciate the work they do, and I sure as hell appreciate the talent, but Google is mostly treating this entire endeavor as a giant marketing and recruiting trick. (It worked well; they stole my favorite pentester from one of my preferred boutique consulting firms.)
- lvh 8y ago
  “Long before Microsoft could patch” meaning when Microsoft decided to cancel a patch Tuesday? If Microsoft decided that the correct patch cadence was quarterly or annually (because so much QA work goes into a release), does that change what a disclosure deadline should look like? Also in the bug you’re referring to, Google expresses surprise Microsoft let it get through because of the severity, and declined to comment on details that would only help exploitation. I also don’t see anything on the bug re: will disclose _because_ sev:hi (your core argument AIUI); but I agree that it doesn’t really impact what their policy should be. You say Google’s words don’t mean anything, but it sounds like you’re advocating for their 90 day disclosure policy to not mean anything whenever a company doesn’t get its act together in time, which I’m sure isn’t your intention. P0 might have some of the best pentesters in the world (it does) but that doesn’t matter much if everyone else gets a ton more time to find and exploit bugs.
  - eganist 8y ago
    You're reading far more into my comment than I put to paper, but I'll indulge. > If Microsoft decided that the correct patch cadence was quarterly or annually (because so much QA work goes into a release), does that change what a disclosure deadline should look like? Absolutely and enthusiastically yes, and for absolutely the reason you wrapped in parens. When so much software runs on your platform, availability matters (and is a critical component of security, which I feel Google doesn't quite understand for reasons not entirely related to p0). QA-test the hell out of a patch unless there's evidence of 0d or imminent exploitation. Plenty of examples exist where that kind of regression testing was provably necessary, such as this one case: https://technet.microsoft.com/library/security/MS15-011 https://technet.microsoft.com/library/security/MS15-011 https://blogs.technet.microsoft.com/srd/2015/02/10/ms15-011-ms15-014-hardening-group-policy/ https://blogs.technet.microsoft.com/srd/2015/02/10/ms15-011-... I'm happy as hell it wasn't p0 who found that one.
    - lvh 8y ago
      What did I read into your comment that you didn't say? You claimed Google used a line of reasoning when it suits them, I refuted that. Your argument only works if a few things are true: * P0 is unwilling to budge from the 90 day disclosure if a bug is legitimately hard to fix. But that isn't true: for example, they kept Spectre/Meltdown under wraps for a very long time. It's not just bugs that conveniently affect Google, either: plenty of Windows issues were given grace periods (usually to hit a patch Tuesday). They've even re-restricted bugs after MSRC _failed to request a grace period in time_ (e.g. P0-395). * If a bug was being exploited, you'd know. (If this isn't true, delay just means attackers have more time to exploit the bug.) But that isn't (generally) true: plenty of bugs are hard to detect remotely, and we have no clue what hoard attackers are sitting on. Never mind the fact that that the onus is on Microsoft to show that a period is warranted (attackers aren't nice enough to leave them a detailed reproducer), can we even come up with a plausible reason for this bug being delayed that isn't "we didn't prioitize it"? Is there code that legitimately tries to load the wrong DLL? If the argument is just 'QA should win by default" and mine is "disclosure should win by default", we're just going to have to agree to disagree. Vendors do not get to arbitrarily model their business to manipulate how disclosure works. Attackers don't care.
      - eganist 8y ago
        > Vendors do not get to arbitrarily model their business to manipulate how disclosure works. Attackers don't care. Right, hence my earlier point, emphasis added: > When so much software runs on your platform, availability matters […]. QA-test the hell out of a patch unless there's evidence of 0d or imminent exploitation. At the expense of sounding like a broken record: (from an arguably oversimplified angle), confidentiality, integrity, and availability all matter.
        lvh 8y ago
        I already addressed why that doesn't really hold water: it assumes that you're likely to know if a bug is being exploited or not. Google found the bug. They're already doing the free research, giving Microsoft a reproducer, and giving Microsoft a well-established policy for when they're going to go public with the bug. Are you suggesting they're responsible for knowing if a bug is being exploited in the wild, or that we should take Microsoft's word for it if it is or not? To be clear: Microsoft can do whatever they want with the bug they themselves found too. (I imagine their internal teams would want similar policies to make sure that they can hold internal teams accountable for fixing their bugs, though, but whatever, that's on them.) You are again only interacting with a tiny part of my argument. We're taking it as read that somehow this bug requires significant QA. Can we agree that some bugs don't need 6 months of intense QA to fix? A UAF is a UAF.
  - IncRnd 8y ago
    > If Microsoft decided that the correct patch cadence was quarterly or annually (because so much QA work goes into a release), does that change what a disclosure deadline should look like? Microsoft uses a regular patch cadence so enterprise users can allocate the necessary resources for review and update of their computers. There are scores of enterprises that use tens of thousands or hundreds of thousands of computers per install. The manner of Google's expected information release puts many end-customers at risk. It is true that in this case the vulnerability was due to Microsoft, but the release of exploitable information will put enterprises at risk. That is why Microsoft asked for additional time. This is a business decision not a technical decision. Sure, Microsoft may have encountered technical issues in their fixing of the issue, but the risk upon exploit information being released is the issue. Google shoulders that risk all by themselves.
    - lvh 8y ago
      I already demonstrated that this is false: there are tons of examples of Google giving MSRC grace periods to hit a patch Tuesday, and in the example GF cited, Microsoft _skipped the patch Tuesday_!
      - IncRnd 8y ago
        That doesn't demonstrate this is false. This is true, because these are the actions being taken at this time... That different things happened for other vulnerabilities is not relevant to this situation. Google is threatening to publicly release an exploit for which Microsoft has admitted they are already working on a fix. Google is not a lawmaker, and if they continue to release 0-day exploits in this manner, even after being instructed otherwise by the vendors, at some point they will be made to shoulder some of the burdens of their having done so. Google knows this to be true, or they would not have held some recent vulnerabilities past their stated 90 day release window. Thoughts about the relative technical merits of the companies or source codes doesn't come into play here. These are business decisions that affect real world companies and people.
        lawnchair_larry 8y ago
- lawnchair_larry 8y ago
  ”I appreciate the work they do, and I sure as hell appreciate the talent, but Google is mostly treating this entire endeavor as a giant marketing and recruiting trick.” No, they aren’t. Don’t make things up. You don’t know what you’ talking about.
  - deleted 8y ago
    [deleted]

My thinking would be exactly the opposite - severe bugs have to be disclosed sooner while non-severe can be left lingering around.

by cesis 8y ago

My thinking would be exactly the opposite - severe bugs have to be disclosed sooner while non-severe can be left lingering around.

eganist 8y ago

And Google has actually had a track record of using that reasoning as well, so it's not like their words actually mean much. Great example of a drive-by high-sev exploit getting exposed long before Microsoft could patch: https://www.digitaltrends.com/computing/google-project-zero-publishes-microsoft-browser-zero-day-bug/ https://www.digitaltrends.com/computing/google-project-zero-... I appreciate the work they do, and I sure as hell appreciate the talent, but Google is mostly treating this entire endeavor as a giant marketing and recruiting trick. (It worked well; they stole my favorite pentester from one of my preferred boutique consulting firms.)

lvh 8y ago
“Long before Microsoft could patch” meaning when Microsoft decided to cancel a patch Tuesday? If Microsoft decided that the correct patch cadence was quarterly or annually (because so much QA work goes into a release), does that change what a disclosure deadline should look like? Also in the bug you’re referring to, Google expresses surprise Microsoft let it get through because of the severity, and declined to comment on details that would only help exploitation. I also don’t see anything on the bug re: will disclose _because_ sev:hi (your core argument AIUI); but I agree that it doesn’t really impact what their policy should be. You say Google’s words don’t mean anything, but it sounds like you’re advocating for their 90 day disclosure policy to not mean anything whenever a company doesn’t get its act together in time, which I’m sure isn’t your intention. P0 might have some of the best pentesters in the world (it does) but that doesn’t matter much if everyone else gets a ton more time to find and exploit bugs.
- eganist 8y ago
  You're reading far more into my comment than I put to paper, but I'll indulge. > If Microsoft decided that the correct patch cadence was quarterly or annually (because so much QA work goes into a release), does that change what a disclosure deadline should look like? Absolutely and enthusiastically yes, and for absolutely the reason you wrapped in parens. When so much software runs on your platform, availability matters (and is a critical component of security, which I feel Google doesn't quite understand for reasons not entirely related to p0). QA-test the hell out of a patch unless there's evidence of 0d or imminent exploitation. Plenty of examples exist where that kind of regression testing was provably necessary, such as this one case: https://technet.microsoft.com/library/security/MS15-011 https://technet.microsoft.com/library/security/MS15-011 https://blogs.technet.microsoft.com/srd/2015/02/10/ms15-011-ms15-014-hardening-group-policy/ https://blogs.technet.microsoft.com/srd/2015/02/10/ms15-011-... I'm happy as hell it wasn't p0 who found that one.
  - lvh 8y ago
    What did I read into your comment that you didn't say? You claimed Google used a line of reasoning when it suits them, I refuted that. Your argument only works if a few things are true: * P0 is unwilling to budge from the 90 day disclosure if a bug is legitimately hard to fix. But that isn't true: for example, they kept Spectre/Meltdown under wraps for a very long time. It's not just bugs that conveniently affect Google, either: plenty of Windows issues were given grace periods (usually to hit a patch Tuesday). They've even re-restricted bugs after MSRC _failed to request a grace period in time_ (e.g. P0-395). * If a bug was being exploited, you'd know. (If this isn't true, delay just means attackers have more time to exploit the bug.) But that isn't (generally) true: plenty of bugs are hard to detect remotely, and we have no clue what hoard attackers are sitting on. Never mind the fact that that the onus is on Microsoft to show that a period is warranted (attackers aren't nice enough to leave them a detailed reproducer), can we even come up with a plausible reason for this bug being delayed that isn't "we didn't prioitize it"? Is there code that legitimately tries to load the wrong DLL? If the argument is just 'QA should win by default" and mine is "disclosure should win by default", we're just going to have to agree to disagree. Vendors do not get to arbitrarily model their business to manipulate how disclosure works. Attackers don't care.
    - eganist 8y ago
      > Vendors do not get to arbitrarily model their business to manipulate how disclosure works. Attackers don't care. Right, hence my earlier point, emphasis added: > When so much software runs on your platform, availability matters […]. QA-test the hell out of a patch unless there's evidence of 0d or imminent exploitation. At the expense of sounding like a broken record: (from an arguably oversimplified angle), confidentiality, integrity, and availability all matter.
      - lvh 8y ago
        I already addressed why that doesn't really hold water: it assumes that you're likely to know if a bug is being exploited or not. Google found the bug. They're already doing the free research, giving Microsoft a reproducer, and giving Microsoft a well-established policy for when they're going to go public with the bug. Are you suggesting they're responsible for knowing if a bug is being exploited in the wild, or that we should take Microsoft's word for it if it is or not? To be clear: Microsoft can do whatever they want with the bug they themselves found too. (I imagine their internal teams would want similar policies to make sure that they can hold internal teams accountable for fixing their bugs, though, but whatever, that's on them.) You are again only interacting with a tiny part of my argument. We're taking it as read that somehow this bug requires significant QA. Can we agree that some bugs don't need 6 months of intense QA to fix? A UAF is a UAF.
- IncRnd 8y ago
  > If Microsoft decided that the correct patch cadence was quarterly or annually (because so much QA work goes into a release), does that change what a disclosure deadline should look like? Microsoft uses a regular patch cadence so enterprise users can allocate the necessary resources for review and update of their computers. There are scores of enterprises that use tens of thousands or hundreds of thousands of computers per install. The manner of Google's expected information release puts many end-customers at risk. It is true that in this case the vulnerability was due to Microsoft, but the release of exploitable information will put enterprises at risk. That is why Microsoft asked for additional time. This is a business decision not a technical decision. Sure, Microsoft may have encountered technical issues in their fixing of the issue, but the risk upon exploit information being released is the issue. Google shoulders that risk all by themselves.
  - lvh 8y ago
    I already demonstrated that this is false: there are tons of examples of Google giving MSRC grace periods to hit a patch Tuesday, and in the example GF cited, Microsoft _skipped the patch Tuesday_!
    - IncRnd 8y ago
      That doesn't demonstrate this is false. This is true, because these are the actions being taken at this time... That different things happened for other vulnerabilities is not relevant to this situation. Google is threatening to publicly release an exploit for which Microsoft has admitted they are already working on a fix. Google is not a lawmaker, and if they continue to release 0-day exploits in this manner, even after being instructed otherwise by the vendors, at some point they will be made to shoulder some of the burdens of their having done so. Google knows this to be true, or they would not have held some recent vulnerabilities past their stated 90 day release window. Thoughts about the relative technical merits of the companies or source codes doesn't come into play here. These are business decisions that affect real world companies and people.
      - lawnchair_larry 8y ago
lawnchair_larry 8y ago
”I appreciate the work they do, and I sure as hell appreciate the talent, but Google is mostly treating this entire endeavor as a giant marketing and recruiting trick.” No, they aren’t. Don’t make things up. You don’t know what you’ talking about.
- deleted 8y ago
  [deleted]