4 ms·

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

by lvh 9y 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 9y 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 9y 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.
  - eganist 9y 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? Google is operating with limited-to-zero information on what exactly breaks when the bug is fixed, and Windows (or even just the .net framework) is a behemoth. Google and Microsoft do both have threat intelligence groups, but that's a separate thread. When you're producing software designed to run on many configurations with absolutely stable operation for at least a month at a time, it's extremely, extremely hard to say that "some bugs don't need 6 months of intense QA to fix." I'm not an engineer at Microsoft, but so long as Microsoft is giving routine updates on a private channel—which they did in this case—as to why it's taking so long, it at least signals that the team is in fact actively working towards a resolution. In fact, with this specific defect, Google applied its own rules/practices to decide whether Redstone 4 (which is my assumed read into what "RS4" means) would be considered a broad patch, whereas Microsoft considers system requirements for minor Windows 10 releases to be hardware-identical in need and entirely backwards-compatible. Timeline (per the report): -> 2018-01-19: Reported issue to secure@microsoft.com and received MSRC case number 43182 <- 2018-02-10: MSRC indicates that the issue has been reproduced and will determine if it's to be fixed. <- 2018-02-12: MSRC indicates that due to unforeseen code relationship this will not be fixed in April PT <- 2018-04-02: MSRC requests the 14 day extension. -> 2018-04-02: Informed MSRC that as the issue will not be fixed with 90+14 days then the grace extension does not apply. <- 2018-04-05: MSRC again requests withholding of disclosure until 2018-05-08, giving more context on the deadline miss. -> 2018-04-06: Informed MSRC that this isn't possible. Made it clear that the issue isn't particularly serious and other .NET based DG bypasses are still unfixed. <- 2018-04-11: MSRC again requests grace extension based on the upcoming release of RS4 which will have the fix -> 2018-04-12: Informed MSRC that as there's no firm date for RS4 this couldn't be applied, and RS4 wouldn't be considered a broadly available patch per the disclosure conditions. -> 2018-04-19: Issue exceeds deadline. —————————— —————————— As an aside: > You are again only interacting with a tiny part of my argument. I'm developing RSIs and would prefer to minimize my interaction to what's most relevant to the debate. I apologize if that makes it more difficult. Edit: though for what it's worth, I'm enjoying interacting. I bear no ill will towards you for your perspective; I've seen and learned quite a bit about balancing security and managing business impact as I've continued to climb the career ladder, things which were shielded from me when I was a lowly developer or security engineer.

by lvh 9y ago

eganist 9y 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 9y 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.
- eganist 9y 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? Google is operating with limited-to-zero information on what exactly breaks when the bug is fixed, and Windows (or even just the .net framework) is a behemoth. Google and Microsoft do both have threat intelligence groups, but that's a separate thread. When you're producing software designed to run on many configurations with absolutely stable operation for at least a month at a time, it's extremely, extremely hard to say that "some bugs don't need 6 months of intense QA to fix." I'm not an engineer at Microsoft, but so long as Microsoft is giving routine updates on a private channel—which they did in this case—as to why it's taking so long, it at least signals that the team is in fact actively working towards a resolution. In fact, with this specific defect, Google applied its own rules/practices to decide whether Redstone 4 (which is my assumed read into what "RS4" means) would be considered a broad patch, whereas Microsoft considers system requirements for minor Windows 10 releases to be hardware-identical in need and entirely backwards-compatible. Timeline (per the report): -> 2018-01-19: Reported issue to secure@microsoft.com and received MSRC case number 43182 <- 2018-02-10: MSRC indicates that the issue has been reproduced and will determine if it's to be fixed. <- 2018-02-12: MSRC indicates that due to unforeseen code relationship this will not be fixed in April PT <- 2018-04-02: MSRC requests the 14 day extension. -> 2018-04-02: Informed MSRC that as the issue will not be fixed with 90+14 days then the grace extension does not apply. <- 2018-04-05: MSRC again requests withholding of disclosure until 2018-05-08, giving more context on the deadline miss. -> 2018-04-06: Informed MSRC that this isn't possible. Made it clear that the issue isn't particularly serious and other .NET based DG bypasses are still unfixed. <- 2018-04-11: MSRC again requests grace extension based on the upcoming release of RS4 which will have the fix -> 2018-04-12: Informed MSRC that as there's no firm date for RS4 this couldn't be applied, and RS4 wouldn't be considered a broadly available patch per the disclosure conditions. -> 2018-04-19: Issue exceeds deadline. —————————— —————————— As an aside: > You are again only interacting with a tiny part of my argument. I'm developing RSIs and would prefer to minimize my interaction to what's most relevant to the debate. I apologize if that makes it more difficult. Edit: though for what it's worth, I'm enjoying interacting. I bear no ill will towards you for your perspective; I've seen and learned quite a bit about balancing security and managing business impact as I've continued to climb the career ladder, things which were shielded from me when I was a lowly developer or security engineer.