> I will not make any further comments on exploitability, at least not until the bug is fixed. The report has too much info on that as it is (I really didn't expect this one to miss the deadline).
Worth mentioning that "Goes Public" implies there was a human who pulled the trigger; it was a bot:
> This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
>"Goes Public" implies there was a human who pulled the trigger; it was a bot:
Meaningless distinction, a human designed the bot that pulled the trigger. Building a robot that then murders someone doesn't absolve the designer from the ramifications of what they built.
It's not meaningless. It would be more appropriate to compare it to a human-designed insurance algorithm that will refuse to offer a discount for extenuating circumstances. That's not so much an analogy as it is a reimplemented example of the same philosophy in practice.
The meaningful distinction is that a human can be persuaded to extend the deadline, at least in theory. A bot cannot be persuaded to do anything, and if a deadline passes an action is triggered like a dead man's switch. In one scenario, a human needs to maintain the decision to uphold that deadline without bias every single time it comes into question. In the other, they only have to do it once: when the bot is initially designed.
They're different things entirely. Arguing that they're not is like arguing that it's easy to maintain a diet or exercise regimen because you just have to uphold a New Year's resolution for a week. This has important ramifications for a security disclosure deadline, because it (theoretically) reduces bias. There are other elements of a disclosure that can still elicit bias, but at least the deadline time itself will not be one of them.
I think you're being pedantic. It's pretty clear what the headline implies and what the parent commenter is saying.
From headline reading "X goes public with...", most people would infer a scenario where something out of the ordinary is taking place. Pointing out that this disclosure was made by a bot is a meaningful distinction.
The distinction is game theoretical. The fact this is a process that has no exception sets the standard and doesn't allow more "costly" bugs to be ignored knowing that they will continue to embargo anyway.
This process and the costly signal associated ensures better behaviour from vendors in the long run.
> a human designed the bot that pulled the trigger.
And a human designed the insecure code on IE. That programmer isn't "absolved of the ramifications" of exposing their user base to god-knows-what kind of malware/ransomware.
> Meaningless distinction, a human designed the bot that pulled the trigger. Building a robot that then murders someone doesn't absolve the designer from the ramifications of what they built.
Not meaningless at all. A better analogy is that you built a robot that pointed a gun at a chair, and said, "this robot will pull the trigger on date X, so don't sit in that chair on date X."
It's not trivial to argue that the robot designer shares the lion's share of the blame here.
I think the person making that comment is confused about how this works. The bug was filed in November. The deadline passed before the comment was made.
The "Deadline exceeded -- automatically derestricting" comment was posted on Feb 23, 90 days[0] after Nov 25.
The account that posted it, [email protected], is listed[1] as the "owner" of Project Zero, which implies to me that they may be a user account, but quite likely one that has a script running under its permissions.
There certainly could be a human-controlled kill-switch to this release process, of course, and it's possible that "hawkes" manually goes through a list of vulnerabilities every day and clicks "release".
The one who didn't expect it to miss the deadline is the same as the person who originally reported the vulnerability. It is therefore a safe assumption that this person understands the disclosure process involved.
Furthermore it is a safe bet that the bug is exploitable. I'm sure that the black market will shortly have people using it.
The P0 people at Google are apparently surprised about this as well, so expect the answer here to be complicated. Three possibilities among many:
1. Reliable exploitation might be difficult in such a way that the P0 people know how to get an exploit working, but Microsoft doesn't, and so it got deprioritized. A related (less likely) possibility is that the bug simply isn't easily exploitable in the configuration Microsoft ships, or expects to be shipping, these browsers in, due to environment differences in Google's testing lab.
2. Patching the bug might be more difficult than P0 anticipated (it might break compat, for instance).
3. The bug may be part of a pattern which is apparent to Microsoft but not to P0, so they may be holding off to get everything patched all at once rather than release an incremental patch that tips attackers off to a bunch more vulnerabilities.
Communication between P0 and other vendors isn't always great. (I think this is the fault of other vendors, by the way, and not P0).
Unfortunately the issue has no log of communications with Microsoft, this is something we usually see in P0 issues from taviso and others. Not sure why it isn't included in this case.
Because it takes time to write a fix, test it, test it some more to make sure it doesn't break any of you 1 billion users, then ship it, then wait some more because people ain't updating that often.
That's in total contrast to web development where you can deploy a fix in ~ 1 hour to all your users simultaneously.
MS could have also chosen to push a fix that crippled CSS on table header rows or whatnot. Web rendering would break and users would complain, but at least users wouldn't have been intentionally exposed.
It's a false dichotomy to suggest that MS's only options were an actual fix vs. do nothing. There are always other options.
> Because it takes time to write a fix, test it, test it some more to make sure it doesn't break any of you 1 billion users, then ship it, then wait some more because people ain't updating that often.
Why does IE have a problem with this whereas other popular browsers do not?
To be fair to MS, a local bank switched their systems and introduced a vuln that leaves the username and password in the form as it opens the account in a new tab. It's still there 3 weeks later.
They still release "out-of-band" patches for critical security bugs. There was one a few days ago for Flash Player that presumably would have been in February's patch bundle but was too important to wait for the next one.
Yes, but Flash Player updates are always pushed as separate items from the Cumulative Update. They are much less likely to push an out-of-band CU, especially when it sounds like they botched their last CU.
Presumably these two facts are related? I would assume this was supposed to get patched this month within the 90 day deadline but some last minute issue delayed the patch.
They probably are. However, I also expect them to be related because of Microoft's own decisions of integrating security patches with one another, instead of keeping them more modular: the so called "patch bundle" policy. It's hard to believe that say some Flash bug couldn't be patched because of some other unrelated bug.
But I hope Microsoft can prove me wrong and explain in detail next month why it couldn't deliver any of the 20-30+ bug patches because of a couple of other unrelated and broken patches.
Sad to see this downvoted, but it's definitely war of some sort between Google and Microsoft and Google actively targeting MS products could easily be a factor. Altruism it likely isn't.
Keep in mind that the Google docs/drive/whatever suite is the competitor for Microsofts Office 365 product.
Has Google ever released info about an unpatched critical bug on their own systems/applications?
All the data I have seen point to "altruism" [1] more than a war with Microsoft. Consider the list of Project Zero reports where the deadline was exceeded (thanks to brainfog for the URL): https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...
[1] Certainly not literally altruism. I suppose Google thinks this projects benefits everybody including themselves.
> I suppose Google thinks this projects benefits everybody including themselves.
That's quite possible but once you start releasing unpatched vulnerabilities about competitor products there is at least a chance that 'including themselves' trumps 'everybody'.
So, google made a nice little 'hands-off' automatic disclosure feature which gives them a reason to say 'computer did it' but I don't think for an instant 'altruism' of any kind is the reason they do this.
If google really had the well-being of internet users at heart they'd shut down google analytics and stop accumulating profiles.
Until they do that my money is on Google estimating that they will do others more damage than they will do themselves through Project Zero and as such yes, we will all benefit but Google will benefit the most of all.
That's a false dichotomy, and it's also a very one dimensional take on what altruism means in the context of capitalism. There is a world of nuanced altruism between "has analytics that violate some peoples' privacy expectations" and "totally altruistic."
What's more, their analytics have nothing to do with the point at hand. Why even bring it up, except as an opportunity for a tangential soapbox? We're talking about disclosure timelines.
It has a lot to do with the point at hand because you can't really attack Microsoft on their web tracking because they don't do any.
So if Google wanted to attack MS on the subject of privacy they'd have to go all the way to Skype to get some traction. So instead they attack on a front where Google is strong and Microsoft slightly weaker.
Google is anything but altruistic, their each and every move is to improve the bottom line for Google and their shareholders. If something is really altruistic it likely falls in their PR budget.
There are much greater concerns with browser exploits than just privacy unless you're being really literal-minded and saying that someone getting their bank account emptied just had an extreme privacy violation.
The answer is: Yes, thev're had critical Android bugs pass the deadline. And what I wrote 88 days ago still holds - still can't see what the actual android bug says, which is annoying.
(FD: Google pays me a day per week, but they don't pay me to spout of on HN in the evenings; this is all my opinionated opinion. :-)
Advance knowledge helps: such as: knowing well prior to the initial report that your people are working on something. Or you might decide not to record the flaw until a fix is in the works.
There is so much missing in terms of transparency here. For instance: was there positive confirmation the message was received by the right people at the vendor? Was there any attempt at communication as the expiry date drew close?
Of course the onus is technically on Microsoft but Google has been at this before and it did not look clean to me at the time.
I can't believe I'm defending MS here.
I'm all for competitors keeping each other sharp but it helps to keep in mind they're competitors first.
One possible way around this is to set up something like project 0 independent of Google, Microsoft and so on and have all of them commit to contributing funding to keep it alive.
IMHO There should be an in between step, not just 90 day timeout for full disclosure, and saying nothing. Maybe CVE
ID and vague description, then extend full disclosure by 7-14 days.
I disagree, 90 days is sufficient time to work offline with the reporting entity. If they cannot come to agreement in 90 days what is another <arbitrary amount of time> going to matter? It just further extends what they are already doing, not prioritizing it.
"Project Zero's disclosure deadline policy has been in place since the formation of our team earlier in 2014. It's the result of many years of careful consideration and industry-wide discussions about vulnerability remediation. Security researchers have been using roughly the same disclosure principles for the past 13 years (since the introduction of "Responsible Disclosure" in 2001), and we think that our disclosure principles need to evolve with the changing infosec ecosystem. In other words, as threats change, so should our disclosure policy.
On balance, Project Zero believes that disclosure deadlines are currently the optimal approach for user security - it allows software vendors a fair and reasonable length of time to exercise their vulnerability management process, while also respecting the rights of users to learn and understand the risks they face. By removing the ability of a vendor to withhold the details of security issues indefinitely, we give users the opportunity to react to vulnerabilities in a timely manner, and to exercise their power as a customer to request an expedited vendor response."
> On balance, Project Zero believes that disclosure deadlines are currently the optimal approach for user security
You mean, like when they disclosed the cloudflare vulnerability after about a week and then the web turned into a race to whomever could find older-than-a-week cache with valuable information.
They disclosed the cloudflare issue after cloudflare confirmed that the issue was resolved (no additional data was being leaked). The fact that data existed from before then wouldn't have changed at any point for anyone who simply said, "No, we're keeping this random data that could be valuable".
The danger of wider knowledge was significantly eclipsed by the danger of a malicious attacker finding the cached data without public knowledge.
The vast majority of the people scrambling to find an older cache were the owners of those caches, who really didn't want to own data they shouldn't have been sent in the first place.
Basically it was required to be disclosed for it to be "fixed" further. The action that needed to be taken was for everyone to delete their web caches. And everyone can't delete their web caches unless they know about the vulnerability.
Technically, it's not. It's being sued by a sister company, both owned by the shared parent 'Alphabet'. Whether there is collusion or not, they are theoretically separate entities.
Yeah, there would likely be a real net-positive to corporations trying to damage each other's credibilities via security disclosures. (No sarcasm - I believe it).
NSA guy #1: "Hey, Fred, Google released another Microsoft zero day. Those things cost us millions to buy. Can we punish Google somehow?"
NSA guy #2: "Sure, let's release our Google zero day!"
#1: "Oh, but didn't we spend millions on that?"
#2: "Yeah, but it'll really screw up Google!"
#1: "Okay, do it."
Google: "Oh my, thanks for pointing out that exploit. We're so glad the NSA is getting back to its mandate to alert American companies and organizations when it had identified security holes. And....fixed. Let us know if you find any more!"
Yes, I'll happily support Microsoft finding bugs in all the Android devices on the market. No to mention it would be paid work anyway, considering the billions of dollars a year Microsoft is making extracting royalties for bogus patents from Android OEMs.
Please get angry and do it Microsoft! Show Google how it's done.
I hope they do! If this sort of team becomes commonplace we may have a good shot at a lot better standard level of security. (Or we may have a chance of it devolving into a corporate shitshow between rivals, idk... I can hope though)
Disclosure: work at Google, but very far away from security.
They actually have a 14-day grace period now, but only if the vendor says it has a patch that's almost ready to go (and can be deployed within that 14-day period).
So I guess Microsoft missed both of those deadlines.
Or at the very least acknowledge and work with the reporting entity to delay disclosure or come to an agreement on how you plan to resolve. 90 days is plenty of time to get your ducks in a row.
> So I guess Microsoft missed both of those deadlines.
No. It was 90 days from the time the bug was filed to the time it automatically disclosed. There was no additional 14-day period (for whatever reason).
The grace period isn't automatic, otherwise that would just be a 104 day window. The grace period applies when the vendor has been in communication with P0 that a patch is in the works and will be released within 2 weeks of the end of the 90 day window. Presumably that didn't happen here.
I wasn't proposing that it was automatic. "For whatever reason" means just that. I wasn't making any statement about why there was no additional 14-day window.
There is always an additional 14-day period on offer, but the vendor has to choose to use it, and has to actually land the patch within the 14 extra days.
So, a deadline miss is often really a 104 (!!) day deadline miss. As an industry that's trying to refocus on security, surely we can do better than that.
> This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
Is this a common pattern in the bugs world ? publicizing a critical bug after 90 days of no response ?
Quite good, comparable with that of Google and Apple. Each of those three companies are good at different things. No big tech firm is as good at vulnerability research as Google; none is better at hardware security than Apple; none is better at security architecture and design than Microsoft. Google and Microsoft have the two largest, most ambitious security programs in technology.
You should be wary of anyone who casually tells you that Microsoft is bad at security. There are things Microsoft might not be great at, but it's complicated.
> None is better at security architecture and design than Microsoft
This is an interesting claim; most of what I (and probably most people) think about Microsoft software security is informed by its earlier history, where it was doing pretty badly overall. What has Microsoft been up to lately that's impressed you with their security architecture/design?
When Microsoft's platform code was notably weak, pretty much everyone else's was too. There was a time when they were maybe 2-3 years behind the state of the art on Unix servers, but the state of the art at the time wasn't good, and that time is mostly past.
For something like 10 years, Microsoft's been punching their weight with secure runtimes in particular, especially given the handicap they work with due to compatibility requirements. They're not perfect. But nobody is.
How does this compare to Google pioneering security architecture in Chrome, which gave it a strong record in Pwn2Own, and eventually became the basis for security in other browsers, including Edge?
Interesting. Does that imply security-conscious tech companies would be better off running .NET services on Windows Server on Azure than a typical FOSS stack?
Umm, not that great. Whatever security features they are adding to Windows 10, they seem to be overshadowed by all the other crap they're putting in Windows 10.
Whether or not Windows 10 is secure, I don't consider that report to be representative of the OS itself. Literally the first 5 "windows" bugs I clicked on were adobe vulnerabilities.
not that i'm saying that this is the case for the adobe vulnerabilities, but in practical terms the ecosystem is pretty tightly coupled to "the OS" when it comes to security.
if your OS needs a ton of cruft bolted onto it to make it useful, and that cruft has security issues then compare that to an OS that doesn't need that cruft, or has a more security software ecosystem. for example, adobe reader vs macos preview.
ecosystem is hard to change, and not entirely the fault of the owners/developers/etc of the software, but it's still important
That's for vulnerabilities found in 2016 though, right?
It would make sense that more are found in W10 (which was 5-17mos in 2016) than W8 (which was 40-52mos in 2016), because of their relative time on the market.
To answer the question, we'd have to look at W10 at this point in its life-cycle compared to W8 at a similar point (and control for things like more active vuln researchers).
I think project zero at Google use the Chromium bug tracker - maybe Google use it for all public bug stuff? I'm not sure why Chromium and not something more general though.
All of those projects are related to Chrome/Chromium, and maybe P0 is a part of the same team, all under @laparisa? http://www.googblogs.com/why-attend-usenix-enigma-2/ here you can see her introducing Ben Hawkes.
I don't think that they're all related. Gerrit, for example, isn't part of Chrome; it was initially developed for Android, AFAIK. Nor is Monorail. I think Breakpad even predates Chrome.
But it's quite likely they all had their bug trackers on Google Code.
"Microsoft Edge and IE: Type confusion in HandleColumnBreakOnColumnSpanningElement" ?
This really isn't a useful headline. It provides no information about the actual relevant event of Google releasing the bug. It just seems like any mundane bug report.
The original title is completely meaningless without context. It's linking to a bug tracker. I would say that this title is neutral, descriptive, and appropriate.
> I will not make any further comments on exploitability, at least not until the bug is fixed. The report has too much info on that as it is (I really didn't expect this one to miss the deadline).
Worth mentioning that "Goes Public" implies there was a human who pulled the trigger; it was a bot:
> This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.
...
> Deadline exceeded -- automatically derestricting