Disclosing vulnerabilities to protect users
security.googleblog.com
security.googleblog.com
Compare vulnerabilities
Chrome 6% code execution, 0.4% gain privileges
Firefox 48% code execution, 8.4% gain privileges
Safari 60% code execution, 9.4% gain privileges
IE 79% code execution, 7.2% gain privileges
Edge 55% code execution, 16.4% gain privileges
Before you complain Firefox and IE are older is older we can compare just the last 2 years of vulerabilities
https://docs.google.com/spreadsheets/d/1nqBd7zmg6grVBEws_UPX...
I expect Firefox's newer stats to get better on this front as they move to electrolysis and servo
It's interesting to note that Safari has zero "gain privileges bugs" for the last 2 years even if it has 22x the code execution bugs as Chrome
http://www.cvedetails.com/product/15031/Google-Chrome.html?v... http://www.cvedetails.com/product/3264/Mozilla-Firefox.html?... http://www.cvedetails.com/product/2935/Apple-Safari.html?ven... http://www.cvedetails.com/product/9900/Microsoft-Internet-Ex... http://www.cvedetails.com/product/32367/Microsoft-Edge.html?...
Aren't these the correct numbers according to the spreadsheet?
Browser vulnerabilities 2015/01 - 2016/10
=========================================
Browser Code Execution Gain Privileges
------- -------------- ---------------
Chrome 2.89% 0.58%
Firefox 43.59% 2.88%
Safari 69.11% 0.00%
IE 69.08% 6.07%
Edge 55.22% 2.24%
The percentages refer to vulnerabilities discovered between 2015 and 2016 and so may apply to older software.
And it's not Safari but rather WebKit as in there are issues listed for specifically the AppleTV which doesn't even run Safari.
It doesn't support your assertion but it's still interesting 2008-2010 data from an antivirus vendor. It's talking about about how long some vulnerabilities were exploited by malware before getting disclosed, use in targeted attacks, and so on.
It does say "In this paper, we consider only exploits that have been used in real-world attacks before the corresponding vulnerabilities were disclosed" so it's unsurprising that in their dataset this is the case :)
> Chrome's sandbox [...] prevents exploitation of this sandbox escape vulnerability.
It reads to me as though Google disclosed an 0day to promote Google Chrome.
This is fine.
•••
Edit: http://venturebeat.com/2016/10/31/google-discloses-actively-...
> A source close to the company also shared that the exploit Google describes requires the Adobe Flash vulnerability. Since Flash has been patched, the Windows vulnerability is mitigated.
If the immediate risk has been mitigated (barring other unknown attack vectors, this was the immediate one of which Google appears to have been aware), this makes the disclosure seem even more shamelessly promotional. I'd presume the Flash vuln would be to enable drive-by exploitation, so if that risk is mitigated, then they really seriously could've let this one wait.
the Windows version is an important part of that statement since it's unclear from this what versions of Windows are affected by the vulnerability.
If anything, this just makes it worse, since it tells me Windows 7 users are SOL.
Makes what worse? There's no mention of other browsers (so how could this be an ad for Chrome? Is Edge vulnerable? Is Firefox?) and the plain implication is that Chrome on Windows 7 is indeed SOL.
If this wasn't an ad and was merely a security disclosure, I'd have expected appropriate research into which configurations mitigate the risk, not just a single configuration which happens to favor the browser maker.
Add on top of that the trivialization of "Windows 10" as the noun in a second-order preposition of place as well as the reference to Chrome as the primary subject of the sentence, and even basic analysis of the sentence in question shows a bias.
They are under NO responsibility to research each and every possible fix. Hell, they technically didn't even have to come up with a mitigation for Chrome.
Then they should've waited until an official fix was out. They know one's being actively worked on. They know the primary exploit path (via Flash) was patched. To my earlier point: they should've just waited.
> That assumption is just plain idiotic.
That's not necessary. You might not see my face, but I'm still a person deserving of some amount of respect.
This question is strange. On the one hand, the disclosure scares users into switching to Chrome even though Microsoft asserts Edge offers protection. On the other hand, the disclosure actually does not disclose the details of a vulnerability that people are exploiting already.
Would you rather have had the disclosure include the exact vulnerability?
I've addressed your other questions surrounding the benefits and drawbacks in other threads. No point in re-hashing them.
Now that that's settled:
I didn't move the goalposts at all. I called into question the inconsistency in your implied assertion that people know the details thanks to this disclosure:
> How is anyone better off not knowing the details of a vulnerability that people are exploiting already?
People do not know the details. The disclosure gave enough to inform those not privy on where to look. It did not inform the world as to the details of the issue.
I'd rather Google have disclosed nothing because as I've stated in the vast majority of my other comments. My position hasn't changed: no one is benefited by a public disclosure here other than
• Google (getting people to use Chrome as a defensive measure even though arguably Edge has this one covered), and
• any unprivy malware authors who now know where to look.
Microsoft isn't going to act any more quickly here. Security vendors are already rolling out mitigations. Google's only advice was "use our browser" even though there are multiple solutions, both in terms of software (Edge) and advising on user actions for the general untargeted population. They included nothing other than:
> Chrome's sandbox [...] prevents exploitation of this sandbox escape vulnerability.
You asserted that they disclosed the details, which Google did not.
So now that my position is set clearly in stone without you able to turn it around with an argument about moving goalposts, let's get back to my current question: Since you asserted that Google disclosed the details even though they did not, would you rather have had the disclosure include the exact vulnerability?
Edited for formatting.
https://news.ycombinator.com/item?id=12842909
I have full confidence that one of the most mature software security groups in tech isn't looking for breathing room on an 0day. Since you've been scouting out my posts, you know better than to put words in my mouth given that one of my biggest assertions here is that Microsoft's already moving as fast as it can and that a disclosure speeds nothing up here.
> Lots more words
I appreciate the attempt at a dodge, so I'll get right back to it: since you asserted that Google disclosed the details even though they did not, would you rather have had the disclosure include the exact vulnerability?
Firefox/others will still be affected if they don't opt-in.
Just in case anybody wonders, this mitigation is opt-in because what it does is it disables all win32k.sys calls (GDI, ...).
> This is the first major invocation of the policy in the three years since it was put in place
http://venturebeat.com/2016/10/31/google-discloses-actively-...
> This is not the first time that Google has disclosed Windows vulnerabilities before a patch was ready. In fact, the company did this for Windows 8.1 twice in January 2015. Microsoft understandably wasn’t pleased, but this time around is even more serious. Both of those earlier vulnerabilities weren’t being actively exploited. [emphasis added]
•••
A longstanding policy doesn't make it a good one.
Not at all. That's actually the crux of my argument that this is promotional.
Google, Microsoft, and Facebook all collaboratively met at an event outside defcon this year called bountycraft. In it, they shared their practices handling vulnerability disclosure and other related events. All three have arguably the best secure development lifecycles in tech right now. All three are intimately aware of each other's practices.
Microsoft is assuredly fixing this into overtime. Microsoft assuredly knew this was in use in the wild. They're already working beyond full speed, and Microsoft has a history of sharing mitigations with third party security vendors. Given the relationship I described above, Google certainly knows all of this and knows that Microsoft won't be able to act any faster to handle this.
No one is served well by this disclosure except for two parties:
· Unprivy malware authors (the vast majority) who are now actively researching this disclosure.
· Google, by convincing users to use their browser for protection.
This was a marketing play.
> A longstanding policy doesn't make it a good one.
If this was a disclosure by the books, there would've been broader, less overtly promotional mitigations discussed.
Project zero would be better off reformulating its disclosure policy here if credibility is what they're going for. Sometimes it's healthier to admit being wrong.
That said, even if the wording was "Browsers such as Chrome which block win32k.sys system calls using the Win32k lockdown mitigation on Windows 10 prevent exploitation of this sandbox escape vulnerability," I would've given them a partial pass.
Don't remember this. Can someone point me to a link?
Citation needed.
No one is served well by this disclosure except
for two parties...
Even though this gives an information advantage to an attacker (e.g., aforesaid "unprivy" malware authors), as a member of the general public, I would rather know that I'm vulnerable to some attack. I might change my behavior to limit my exposure. I may take additional precautions that would otherwise be too costly were it not for the additional risk. I might choose to accept the risk and continue working normally. My point is that by not disclosing, the security researcher makes my risk management choices for me, and I am not convinced they have my best interests at heart.
Likewise, public disclosure makes it possible for the customers of a software vendor to pressure them into addressing the vulnerability in a more timely fashion. Otherwise, these companies will not take security issues seriously. I have seen that pattern repeat over and over and over. The only way to get vendors to change is to name and shame, hit 'em in their wallet and hit them hard. Microsoft does SDLC now because of full disclosure, not in spite of it.
And they still can't fix it in 7 days? Well, then they have to shape up or be replaced by a competitor who can. It's harsh, but customers benefit.
Chrome on Windows 10 is protected. So if anything, it's an ad for Windows 10, not Chrome. Chrome is still vulnerable on Windows 7 and Windows 8/8.1 - which is what, 70-80% of the Windows users? And as others have said, it probably affects all the other browsers, too, so if Google was indeed the "good guy" in this story, it would still do this so the users of other browsers find out about the vulnerability, too.
Speaking grammatically, that's the least important part of the sentence. Quoting my reply to the same point elsewhere,
> Add on top of that the trivialization of "Windows 10" as the noun in a second-order preposition of place as well as the reference to Chrome as the primary subject of the sentence, and even basic analysis of the sentence in question shows a bias.
A proper non-promotional security disclosure would've included multiple mitigating strategies, even if they're user actions such as browsing only trusted sites until a patch is released. Even if that sentence was worded differently ("Browsers which block win32k.sys system calls using the Win32k lockdown mitigation on Windows 10, such as Chrome, prevent exploitation of this sandbox escape vulnerability."), I would've given them a partial pass.
A mental model of Mehta that has served me pretty well: if he says something publicly like this, it's probably because it's important and correct.
The idea that he'd be wasting his time on marketing stunts for the Chrome browser is a bit naive.
If that's the case, though, then he could benefit from reading this HN submission in writing future disclosures.
Benefit how exactly?
By becoming another mindless conformist whitehat who never exercises full disclosure when a vendor isn't taking security seriously (but oh man will they ever pay lip-service to the idea of taking security seriously)?
That's what a lot of the comments in this thread would have him do, anyway.
I think the best benefit he could get from reading the comments here is the realization that so much of the tech industry knee-jerk-defends software vendors without realizing the importance of diverse vulnerability disclosure practices. Then when someone gets particularly nasty with him, he can shrug it off as just a particularly-vocal entitled developer who has probably never found a security vulnerability before, and proceed with following the established P0 policies.
But he probably already knows/realizes this.
But ultimately, I think the comments here would be a waste of time that could better be spent on things that matter far more than the egos of most HN commenters. Myself especially.
Therefore:
> Benefit how exactly?
Benefit by observing more nuanced language practices in the future. If tptacek's point stands (and I have no reason to doubt him), then Neel benefits by receiving less controversy for a highly controversial practice simply through tweaking the write-up.
It has nothing to do with "egos of most HN commenters." I'd like to think most commenters on HN have practical roles at their organizations and likewise have to deal with the fallout from disclosures like this much the way I now have to.
Even if the wording was "Browsers such as Chrome which block win32k.sys system calls using the Win32k lockdown mitigation on Windows 10 prevent exploitation of this sandbox escape vulnerability," I would've given a partial pass because it looks less overtly self-promotional.
3 minutes later, after a second read:
I understand that you're uncomfortable with the idea that for some users, switching to Chrome is the most reasonable workaround for a very serious vulnerability. But it is a factual statement.
Elsewhere, I also stated a preference for conveying multiple solutions, "even if they're [only] user actions such as browsing only trusted sites until a patch is released." This would've been great to disclose for the many corporate users on Windows 7 since the specific mitigating feature implemented by Chrome (and Edge, if Microsoft's implication is to be trusted) in Windows 10 isn't available to these users.
You're suggesting that Google give terrible security advice simply to dull the discomfort you think they should feel about the fact that their browser's security model defeats this particular vulnerability. I feel like either I'm missing something, or you can't really be thinking this through carefully.
An experienced attacker, sure. Targeted campaigns, sure. I'd argue this doesn't apply all that readily to attackers who might just buy an exploit kit for quick mass-mailed wins, though.
It's not terrible advice at all (though perhaps "only sites you know" might be better). It's only marginally effective, but for most users it's absolutely better than nothing at all. When the only advice an 0day disclosure gives is to use the disclosing company's product, it compels people to question the motive for the disclosure especially when, as discussed elsewhere in the thread, literally nothing is achieved by the public disclosure itself.
There are multiple solutions here. They might not all be nearly as effective as "Use Chrome" (paraphrasing), but they're all more effective than merely informing users that there's an 0day for a superset of users and then giving only a subset of those users a mitigation path.
I'm rather surprised we're not in agreement here, actually.
The attackers this disclosure contemplates have both browser RCE and a zero-day Windows kernel privilege escalation vulnerability. There is no site you can direct them to that an attacker can't briefly replace with a malware installation vector. The advice you're suggesting Google provide simply doesn't apply.
Elsewhere in the thread (and far prior to our discussion here), I linked to http://venturebeat.com/2016/10/31/google-discloses-actively-...
> A source close to the company also shared that the exploit Google describes requires the Adobe Flash vulnerability. Since Flash has been patched, the Windows vulnerability is mitigated. That said, Microsoft still needs to plug the security hole as it could be leveraged in other types of attacks.
So, it would appear there's no RCE and that there's just an 0day priv-esc.
• targeted attacks (much more likely)
• mass campaigns (I'd argue much less likely)
Since Google's disclosure is to everyone, advice which applies to everyone will also cover the set of people who:
• aren't targets of attackers with an unknown RCE, and
• are likely to download attachments w/ the priv-esc alone.
I don't have the stats, but telling everyone to be careful also tells this likely-majority subset of people to be careful, optimistically mitigating the substantially higher risk that they'll be owned by the priv-esc alone. The remaining at-risk set is the population of people for whom attackers may decide that burning an unpublished RCE is a valuable trade.
•••
If you're also talking about known and patched RCEs, then users who are missing those updates have bigger problems.
•••
To quote one of my employees who's got an eye on this thread: "At this point, the argument between the two of you is entirely pedantic in nature." heh
The modern browser security model depends in part on the idea that arbitrary RCE does not equate to system privileges. That's what sandboxes and multi-process models are for.
A kernel privesc vulnerability bypasses the modern browser security model. That's why it's a big deal.
The disclosure points out that Chrome's sandbox preemptively blocks this particular privilege escalation bug, by not exposing its vector in its sandbox. But other browsers don't.
Microsoft seems to disagree without explicitly stating it, and Google didn't explicitly state this either.
Edit with relevant PR-speak from Microsoft: "We recommend customers use Windows 10 and the Microsoft Edge browser for the best protection."
It would be interesting to see if Project Zero tested for this in Edge, but since they gave no indication that other browser are vulnerable or not, it's fair to assume they haven't. Heh.
There is a shovel here.
>
This isn't some elaborate scheme to hype up Chrome.
If I were Microsoft I'd tell them to mind their own damn business as well. It's obvious anyway that the only thing Google cares about in this instance is making themselves look good at the expense of Microsoft.
Chromium OS is alive and well. Perhaps you're thinking of the Chrome-specific "application" APIs, which have been deprecated in favor of web technologies?
>If I were Microsoft I'd tell them to mind their own damn business as well.
What would you tell their customers that were infected by their negligence? Let me guess? "Mind your own damn business".
On the one hand, you don't tell anyone other than Microsoft and wait for them to patch as many people as possible while the bug is ACTIVELY being exploited and possibly thousands are getting hacked by the hour.
On the other hand, you tell people, and many are now able to patch it themselves RIGHT NOW, force an update on their machine, not use affected software, and potentially avoid a hack that would've happened if they didn't know.
So yes, it's not black and white, but I think their call of waiting a week was an okay one.
The Nexus 5 was already dropped in October 2015, having been released in October 2013.
Same with the Nexus 6 (it was dropped yesterday, being 2 years old).
It’s always been 18-24 months of updates max, and only if you buy on release day. https://support.google.com/nexus/answer/4457705#nexus_device...
> Nexus devices get security patches for at least 3 years from when the device first became available, or at least 18 months from when the Google Store last sold the device, whichever is longer.
Google is still releasing security patches for Nexus 5
http://www.androidpolice.com/2016/08/01/august-security-patc...
The most recent one for Nexus 5 aka Hammerhead was this month: M4B30X, Oct 2016
https://developers.google.com/android/images
You're mistaking the major version releases (6.x.x vs 7 x.x) with security patches, they are not promising major updates here only security patches for 6.x.x.
Which is illegal, EU law demands 24 months from when it was lost sold anyway.
> they are not promising major updates
That’s another issue, many security features are only added in major updates (sandboxing Mediaserver, etc).
So you only get hotfixes, and not long-term fixes.
If IoT security wasn't even worse Android would have been the new botnet platform.
What I mean is, that all major browsers are trying to create their own sandbox environment to be more secure, right? But maybe it is better to do the other way round: give them all permissions, but put them in a controlled and restricted sandbox environment (container). And browser window will be just a small app that talks to that container, sends requests and gets resulting page (rendered) and just shows it? So, it will literally have no access to outside of the container.
As a bonus, it decouples UI from backend.
Asking, because the purpose of containers is to isolate and create sandbox environments, and the purpose of browser is to render and show web pages. So why do browsers care about security, if we already have containers?
Or that makes no sense and gives no advantage/security?
This is partially true: for example there are sandboxes considering the website origin and related restrictions, but on the process level browsers reuse the system mechanism instead of implementing their own. For example on linux, chrome uses seccomp and a number of other ways to separate the ui from the backend. Windows has its own solutions for this.
So I don't think it's right to say they create their own sandboxes. At least not in a NIH meaning.
Containers are just a fancy package for the protections offered directly by namespaces and other existing restrictions. User namespaces are already used in chrome sandboxes for example (https://chromium.googlesource.com/chromium/src/+/master/docs...)
https://blogs.windows.com/msedgedev/2016/09/27/application-g...
Workstations are often locked down, so employees can't install or upgrade anything.
The second most popular version? IE 6. Not even 8. IE 6.
Who still uses it? Employees of other government departments...
(Disclaimer: I work on analytics.usa.gov.)
It gets worse... People write apps that use Flash (online training) or Java applets.
There are solutions to this, but none of them involve using the one true SOE, one SOE to rule them all!
This. These supposedly risk-averse organisations also have no concept of the risk of stasis, only the risk of change.
The general premise was, if you apply an update and something breaks (note that "changed behaviour" means "broken"), someone's head will roll. If you do nothing and get compromised, it's those damned <country> hackers again.
Never underestimate the management's ability to fire a Enterprise IT workers for applying an update that the developer's swear changes no behavior in the companies enterprise software, but actually does.
// been on both sides, we suck at testing and risk assessment in this profession
Companies and citizens, live with that.
But sadly no, they don't follow this kind of stable release.
https://bugs.chromium.org/p/chromium/issues/detail?id=658606
Link to Xerox issue: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_...
Source: I've done these things before based off notices like this, and caught malware with it
I'd expect AV vendors to already have signatures for this given that it's being actively exploited, which means there must be malware samples to know this.
When there are known exploits attacks against users, giving a short time to get out quick patches to trusted software vendors makes a lot of sense, but I don't see a good reason for giving more than 24-48 hours before public disclosure.
In this case, the exploit was being actively used in the wild. That means bad actors already had access to this and it was the users who were in the dark. Now it may be added to the "toolkits" of scripters and people who buy exploit frameworks but the people who do real damage were already using it according to Google.
OK I'll bite. What do you think the motive is?
According to the post's byline, it was written by Neel Mehta and Billy Leonard of the Threat Analysis Group at Google. Are you questioning their professional judgement and claiming they are individually biased?
If not, are you suggesting that there is some management directive to look for Windows exploits and publish them on an aggressive timeline in order to embarrass Microsoft publicly? Do you think professional security researchers would abide by such a directive?
There's no good reason for Google not to respect coordinated disclosure here. Making an arbitrarily tight deadline their policy isn't protecting users.
Now, tell me, how users would know about that without disclosing.
And, remember, there are already exploits
> The Windows vulnerability is a local privilege escalation in the Windows kernel that can be used as a security sandbox escape. It can be triggered via the win32k.sys system call NtSetWindowLongPtr() for the index GWLP_ID on a window handle with GWL_STYLE set to WS_CHILD.
Which is enough information for someone to write an exploit from scratch.
If they'd just said there is a win32k.sys vulnerability and advised users to make sure Flash is up to date, this would have been fine.
I'm starting to think the ultimate PC OS for IT would be one with a transactional audit trail on all changes to the PC.
1) try calling Google about a problem if you disagree with this statement
Also there's the consideration that security-critical environments who pay attention these have much more value-at-risk than the average Windows user. You want your safety critical systems who pay attention to be protected.
We don't yet know if this was being widely exploited (versus being a niche exploit used by an APT, for example), but it will be now either way.
https://security.googleblog.com/2013/05/disclosure-timeline-...
Stop spreading FUD without evidence.
n.b. https://adamcaudill.com/2015/11/19/responsible-disclosure-is...
There's no "right" answer because this is a holy war that's been going on for a very, very long time now.
It's not just that people affected by this vulnerability are being protected by its disclosure (though there are reasons why that might be the case) it's that in the future vendors will take deadlines from P0 far more seriously when they realise that their reputation is on the line if they fail to patch in time.
If you let vendors get away with "we know that this is being actively exploited, but we haven't been able to come up with a timely fix, so please don't tell our customers how screwed they are", then that becomes the standard line and you need to keep letting deadlines slip. Or you don't let them slip and you end up with this sort of situation.
It goes both ways. As they said, this is active in the wild and many are being hacked AS WE SPEAK completely unaware of it. Imagine you had some information that is worth millions of dollars on your computer who is vulnerable to this. Now that you know, the first thing you'll do it turn off your computer or find a way to protect yourself. If they hadn't released it, you could've been hit in the coming week or month or however long it takes Microsoft.
As you can see, this isn't a black and white problem.
So if Google doesn't have any way to mitigate the vulnerability, all putting these details out do is allow more actors the chance to use the vulnerability until Microsoft can release a patch, which is exactly the opposite of responsible.
I wonder why they would not do the same for Microsoft?
Why they didn't in this specific instance is probably because it was being actively exploited in the wild, but that's just a guess.
Basically the plugin operates at a higher level than the regular page DOM, so by running angular from a plugin you gain the ability to both execute (arbitrary) javascript from the page but also read/write to the disk. very bad. cannot be fixed. arbitrary code execution by design.
Protect users AND educating script kiddies, this is a hard trade off, and all lazy updating users will be more vulnerable then before.
(more being more script kiddies, not so much more vulnerabilities).
As long as it is done responsible and vendors are given chances to fix this before. Not disclosing is worse i guess in any case.
However, "We encourage users to verify that auto-updaters have already updated Flash"
While adobe recommends to not install it, meh.. :)
IE, a script kiddie is more likely to use python or php to SQL inject than to execute a timing attack against a crypto library.
Telling the world about vulnerabilities is a knife that cuts on two sides. Inform users about security. Inform wankers how to abuse stuff.
"someone who downloaded a DOS tool for example"
https://en.wikipedia.org/wiki/United_States_free_speech_exce...
>Microsoft harshly criticized the disclosure. “Today’s disclosure by Google puts customers at potential risk,” a Microsoft spokesperson said. “We recommend customers use Windows 10 and the Microsoft Edge browser for the best protection.”
Really? Because I thought "your customers" were already at risk for an in the wild zero day exploit that's currently being used to infect Windows computers. How dare Google warn the public to allow them the time to take precautionary steps. I guess they think it's better for their customers to take it up the ass until they figure out how to patch it.
But if it's being actively exploited? Yes, thank you Google for letting us know ASAP. Would indeed be irresponsible not to in this case.
This is not a "wait until the next release cadence" kind of issue, but more like a "scramble all jets and work through the weekend" kind. If I were a Windows user, I don't think there's anything else I'd want MS to work on over fixing an actively exploited remote priv escalation vuln.
Google's security team worked through their Christmas vacations when they had an attack awhile back. To give other companies 7 days to patch their software is really quite generous.