This story is surprisingly hostile to Google. A 90-day window after which the bug is published is about as responsible as responsible disclosure gets. The headline really rubs me the wrong way, as though Google raced to publish this vulnerability to spite Microsoft.
Not talking about the bug doesn't mean it's not there, but talking about it sure makes people aware that they should perhaps take extra precautions until Microsoft patches the bug. The attitude that "you're giving info to the evil hackers and now we're all unsafe!11" is the very essence of the fallacy of security by obscurity - your ignorance of a bug is not guarantee of others' ignorance of it. Pinning blame on Google for putting us all at risk is the exact wrong response; Microsoft is at blame for taking more than three months to fix a critical security bug, which has been there for even longer.
This sentiment is very visible in the comment section - the story's suggestion that Google did something wrong here, and the torrent of clueless commenters raging about how evil Google is being is disheartening, to say the least. I wonder how much of that is a result of the story's tone.
On the other hand, project zero publishes kiddies-ready exploits for their vulnerabilities, which is a very questionable practice for vulnerabilities which are still in the wild. Even if patches were available, it would be far better to wait for most devices to be patched before releasing a full exploit. They did this with iOS and now with Windows. We are now waiting for such useful ready-to-use exploits for major Android versions as well.
The problem with not doing this is you're just leaving the hole open, and when vendors haven't bothered to respond before the deadline there's very little chance that they will do anything at all if it passes and there's no consequence. If details of the vulnerability are published, the vendor will have to patch it or openly admit they don't care about a significant risk to their business (note that the risk was there all along.)
Sorry, but this is on the vendors. Saying Google shouldn't release details is like saying the public shouldn't be informed of a dangerous flaw in a car model's brake system until the manufacturer has decided whether to launch a new model and what the marketing plan for it should be.
> Even if patches were available, it would be far better to wait for most devices to be patched before releasing a full exploit.
The practice of a firm 90-day release schedule increases the probability that vendors will fix patches and take steps to assure that they are deployed to most devices within that period. But that only works if the practice is firm.
This is a great point. The article bemoaned Project Zero's rigid deadline as unreasonable, but I think you have it right - a known and standard deadline doesn't leave anyone surprised.
Yes, that is exactly what I am asking. I want ready-to-use exploit for vulnerabilities in major Android versions after 90 days from disclosure to Google from Project Zero.
AFAICT, the project zero team is about hunting down bugs and disclosing them responsibly.[1] They occasionally do write-ups on the project zero blog, after the vuln has gone public, but without actually giving out "kiddies-ready expoits", i.e. exploit source.
But even if they did, that still isn't a "questionable practice" - if the full details of the exploit are public, you'd barely need a writeup to connect the dots.
> Even if patches were available, it would be far better to wait for most devices to be patched before releasing a full exploit.
So, for router exploits (say), that would be Infinity? If the manufacturer doesn't care, or the update ecosystem is broken (or nonexistent), nobody is more secure because someone did a writeup about a vuln that everyone (..interested) knows about.
Most exploits, however complex their discovery process may have been, end up as "send these bytes in this order" - they are usually very simple to duplicate once you know where the bodies are buried.
[1] As the GP says, 90 days is responsible disclosure.
I disagree that releasing an exploit is, per-se, not interesting. There are many kind of vulnerabilities, and some exploits are very complicated to write.
But really, that is not the point. I'm not debating disclosure vs non-disclosure. I'm debating having a "research team" employed by Google that publishes vulnerabilities and ready-to-use exploits for competing operating systems, irrespective of this probably being illegal because of their non-independent position. If Google wants to confirm that this is not a project to weaken competitions but to do true research for the sake of research itself and protection of end-users no matter what, they should (sooner or later) focus also on the major mobile operating system, Android, and give it equal treatment, including releasing ready-to-use exploits after 90 days. I'm sure Google will try an fix those vulns within 90 days as they are very good at it, but we also now that the great majority of Android devices will be fully vulnerable after 90 days. At that point, having a ready-to-use exploit circulating will be an interesting exercise of the ecosystem.
> I disagree that releasing an exploit is, per-se, not interesting.
That isn't what I said, I believe my original point stands on its own. Please don't put words in my mouth, you don't know me that well :)
> There are many kind of vulnerabilities, and some exploits are very complicated to write.
The most complicated exploit that I can think of would require you to put the target system in "some state" before sending the triggering payload. In the most-most complicated situations, where you can't "just replay bytes" to get it into the state (dynamic handshake - think heartbleed) you just use a library to do the initialization (or whatever) for you and then use the raw socket from the lib to send the payload.
That isn't very complicated, but perhaps I'm limited by my imagination.
> ready-to-use exploits
I invited you to show a ready to use exploit on the Project Zero blog. Is there one, and I missed it?
> probably being illegal because of their non-independent position
Now you're just being silly. The burden of proof is on you for this.
> If Google wants to confirm that this is not a project to weaken competitions
Is this a popular enough opinion that Google should even know that it needs to confirm or prove anything?
The team does research, and the blog hosts writeups about public vulns. Some are even guest posts for crying out loud. The recent ntpd exploit could be applied to Linux as well. If you search for "Linux", plenty of stuff comes up. There may even be a corporate policy about not doing Android vuln writeups, but that still isn't malicious unless they're actually finding Android bugs and not patching them. If they do patch them, they'll get out. Them not having done a write-up on their blog isn't malicious.
The burden of proof for malice is on you. I'm all for tinfoil hat talk, but there has to be some substance, or it's just talk.
Metasploit does the same thing, and we've managed to not have the internet implode yet.
Yours is the standard argument against any form of disclosure. I'm not discounting it, because no disclosure has its merits, but responsible disclosure satisfies both an ethical imperative (you can't let people believe they're secure if you know otherwise) and provides pressure on vendors to fix their software, when the vendor might otherwise deem it not worth the time or money to fix the issue, which leaves their customers vulnerable.
The basic idea behind disclosure is "we might not be the first people to find this, and we definitely won't be the last, so let's remove all doubt and rob the bad guys of the element of surprise". Responsible disclosure is intended to permit responsible vendors to fix the issue before wide publication, but an uncooperative vendor doesn't mitigate the reality that the bug exists and will eventually be found by someone less benevolent.
Disappointing. Microsoft has no real argument here, other than perhaps allowing the NSA to use the bug for longer [1]. This is why the NSA has no need for real Windows backdoors. There are plenty of vulnerabilities such as these in Windows that allow privilege escalation or remote execution that are being discovered all the time. All Microsoft has to do is sit back for a few months on them, wait until another one appears, so NSA can start using that one and then fix the old one. "Everyone" wins.
Google gave everyone (only a few big companies actually - everyone else got the "full disclosure" deal) only a week after discovering Heartbleed, and Microsoft is whining about 3 months being too little? Give me a break.
> It is important to note that for a would-be attacker to potentially exploit a system, they would first need to have valid logon credentials and be able to log on locally to a targeted machine.
Are Microsoft downplaying or is this genuinely quite minor? The article discusses a disgruntled employee and since all their money comes from Enterprise presumably disgruntled employee can cause major damage is a pretty huge problem?
It means that every user effectively has root privileges. Which means that every user can eavesdrop on other users, view their saved data and files (unless encrypted on disk), intercept their network communications, impersonate them, steal their passwords (system, application, external web sites).
How bad that is depends on your particular use case. But for pretty much any setup where security is a concern or there's any sensitive data at stake, this is a very serious issue.
This is pretty much how I was interpreting it. For context I did an internship at a bank, I had access to a computer and login credentials, but not admin access. I get the feeling that this would be a hair on fire problem there if like you said it'd mean me effectively having root.
However, in the case of Windows, this issue isn't that much severe as it would be on a unix-like, for example.
With the set up of Windows servers I've seen, only the admin logs in anyway. It's not really used as a "multi-user" system per-se, where you get different users logging in at the same time. It does happen, but it's not common.
Hahah, I figured Windows might be slightly better about this, hence the self-admitted uninformed take.
Could you clarify, though: do you mean to say Windows isn't as vulnerable because of cultural reasons (i.e. Windows systems aren't multi-user usually) or because of technical ones (they support something like SELinux out of the box)?
This is a big issue in enterprise deployments. Consider, for example, the Sony hack - this is the kind of issue that allows a savvy low-level employee to wreak havoc on their employer, because once you can get root on a machine inside a corporate network, all kinds of doors open.
This isn't a remote root code execution bug, but it shouldn't be taken lightly, either. The exact environments where this bug would be applicable (locked-down) are the environments that could suffer severe damage because of an escalation issue.
The thing is, though, local privilege escalation isn't new, and it isn't novel. This is one in a long string of many, many similar bugs across most every major platform. It's completely unremarkable except for the reluctance on MS's part to patch it in a reasonable timeframe.
You can combine such a privilege escalation with an USB virus, social engineering, etc. to get remote root access to a machine and eventually all machines of a network.
Windows 7 has security support through January 2020 [1]. What's ending this month is "mainstream support", which seems to mean new features, phone support, etc. [2]
It's more nuanced than article or commenters on HN want it to be. If there's a constant communication channel between companies and there's a reason to believe that patch can't be created in 90 days, sticking to deadlines seems to prioritize the wrong things.
On the other hand if MS wasn't responsive enough and upfront about the time it'd take to patch and reasons for that, then sure, 90 days seems more than needed leeway for Microsoft. But I don't know how things worked and I've seen enough to assume that both scenarios are possible.
I think the initial principle of the disclosure policy is good, it is intended to put a bit of pressure on bad vendors to fix their bugs. That said I don't think we can classify MS as a bad vendor. They fix lot of critical issues every years, they certainly have their own internal teams working on security issues, they're responsibles.
Vendors with a quite good track record should be allowed to have some slip ups. You cannot compare a vendor who doesn't fix anything on time with one that usually fix issues promptly but occasionally shows a delay on a report. The process should take that into account. I think the binary handling by Google on this one is not very well thought-out.
31 comments
[ 3.4 ms ] story [ 45.3 ms ] threadNot talking about the bug doesn't mean it's not there, but talking about it sure makes people aware that they should perhaps take extra precautions until Microsoft patches the bug. The attitude that "you're giving info to the evil hackers and now we're all unsafe!11" is the very essence of the fallacy of security by obscurity - your ignorance of a bug is not guarantee of others' ignorance of it. Pinning blame on Google for putting us all at risk is the exact wrong response; Microsoft is at blame for taking more than three months to fix a critical security bug, which has been there for even longer.
This sentiment is very visible in the comment section - the story's suggestion that Google did something wrong here, and the torrent of clueless commenters raging about how evil Google is being is disheartening, to say the least. I wonder how much of that is a result of the story's tone.
Sorry, but this is on the vendors. Saying Google shouldn't release details is like saying the public shouldn't be informed of a dangerous flaw in a car model's brake system until the manufacturer has decided whether to launch a new model and what the marketing plan for it should be.
The practice of a firm 90-day release schedule increases the probability that vendors will fix patches and take steps to assure that they are deployed to most devices within that period. But that only works if the practice is firm.
But even if they did, that still isn't a "questionable practice" - if the full details of the exploit are public, you'd barely need a writeup to connect the dots.
> Even if patches were available, it would be far better to wait for most devices to be patched before releasing a full exploit.
So, for router exploits (say), that would be Infinity? If the manufacturer doesn't care, or the update ecosystem is broken (or nonexistent), nobody is more secure because someone did a writeup about a vuln that everyone (..interested) knows about.
Most exploits, however complex their discovery process may have been, end up as "send these bytes in this order" - they are usually very simple to duplicate once you know where the bodies are buried.
[1] As the GP says, 90 days is responsible disclosure.
But really, that is not the point. I'm not debating disclosure vs non-disclosure. I'm debating having a "research team" employed by Google that publishes vulnerabilities and ready-to-use exploits for competing operating systems, irrespective of this probably being illegal because of their non-independent position. If Google wants to confirm that this is not a project to weaken competitions but to do true research for the sake of research itself and protection of end-users no matter what, they should (sooner or later) focus also on the major mobile operating system, Android, and give it equal treatment, including releasing ready-to-use exploits after 90 days. I'm sure Google will try an fix those vulns within 90 days as they are very good at it, but we also now that the great majority of Android devices will be fully vulnerable after 90 days. At that point, having a ready-to-use exploit circulating will be an interesting exercise of the ecosystem.
That isn't what I said, I believe my original point stands on its own. Please don't put words in my mouth, you don't know me that well :)
> There are many kind of vulnerabilities, and some exploits are very complicated to write.
The most complicated exploit that I can think of would require you to put the target system in "some state" before sending the triggering payload. In the most-most complicated situations, where you can't "just replay bytes" to get it into the state (dynamic handshake - think heartbleed) you just use a library to do the initialization (or whatever) for you and then use the raw socket from the lib to send the payload.
That isn't very complicated, but perhaps I'm limited by my imagination.
> ready-to-use exploits
I invited you to show a ready to use exploit on the Project Zero blog. Is there one, and I missed it?
> probably being illegal because of their non-independent position
Now you're just being silly. The burden of proof is on you for this.
> If Google wants to confirm that this is not a project to weaken competitions
Is this a popular enough opinion that Google should even know that it needs to confirm or prove anything?
The team does research, and the blog hosts writeups about public vulns. Some are even guest posts for crying out loud. The recent ntpd exploit could be applied to Linux as well. If you search for "Linux", plenty of stuff comes up. There may even be a corporate policy about not doing Android vuln writeups, but that still isn't malicious unless they're actually finding Android bugs and not patching them. If they do patch them, they'll get out. Them not having done a write-up on their blog isn't malicious.
The burden of proof for malice is on you. I'm all for tinfoil hat talk, but there has to be some substance, or it's just talk.
Yours is the standard argument against any form of disclosure. I'm not discounting it, because no disclosure has its merits, but responsible disclosure satisfies both an ethical imperative (you can't let people believe they're secure if you know otherwise) and provides pressure on vendors to fix their software, when the vendor might otherwise deem it not worth the time or money to fix the issue, which leaves their customers vulnerable.
The basic idea behind disclosure is "we might not be the first people to find this, and we definitely won't be the last, so let's remove all doubt and rob the bad guys of the element of surprise". Responsible disclosure is intended to permit responsible vendors to fix the issue before wide publication, but an uncooperative vendor doesn't mitigate the reality that the bug exists and will eventually be found by someone less benevolent.
I suppose that you will provide sources for that, don't you?
http://www.theverge.com/2015/1/2/7481069/google-publishes-wi...
Disappointing. Microsoft has no real argument here, other than perhaps allowing the NSA to use the bug for longer [1]. This is why the NSA has no need for real Windows backdoors. There are plenty of vulnerabilities such as these in Windows that allow privilege escalation or remote execution that are being discovered all the time. All Microsoft has to do is sit back for a few months on them, wait until another one appears, so NSA can start using that one and then fix the old one. "Everyone" wins.
Google gave everyone (only a few big companies actually - everyone else got the "full disclosure" deal) only a week after discovering Heartbleed, and Microsoft is whining about 3 months being too little? Give me a break.
[1] http://www.bloomberg.com/news/2013-06-14/u-s-agencies-said-t...
Just being practical.
Are Microsoft downplaying or is this genuinely quite minor? The article discusses a disgruntled employee and since all their money comes from Enterprise presumably disgruntled employee can cause major damage is a pretty huge problem?
It means that every user effectively has root privileges. Which means that every user can eavesdrop on other users, view their saved data and files (unless encrypted on disk), intercept their network communications, impersonate them, steal their passwords (system, application, external web sites).
How bad that is depends on your particular use case. But for pretty much any setup where security is a concern or there's any sensitive data at stake, this is a very serious issue.
With the set up of Windows servers I've seen, only the admin logs in anyway. It's not really used as a "multi-user" system per-se, where you get different users logging in at the same time. It does happen, but it's not common.
Could you clarify, though: do you mean to say Windows isn't as vulnerable because of cultural reasons (i.e. Windows systems aren't multi-user usually) or because of technical ones (they support something like SELinux out of the box)?
This isn't a remote root code execution bug, but it shouldn't be taken lightly, either. The exact environments where this bug would be applicable (locked-down) are the environments that could suffer severe damage because of an escalation issue.
The thing is, though, local privilege escalation isn't new, and it isn't novel. This is one in a long string of many, many similar bugs across most every major platform. It's completely unremarkable except for the reluctance on MS's part to patch it in a reasonable timeframe.
http://windows.microsoft.com/en-us/windows/lifecycle
[1] http://windows.microsoft.com/en-us/windows/lifecycle
[2] See point 6 at http://support2.microsoft.com/gp/lifepolicy
On the other hand if MS wasn't responsive enough and upfront about the time it'd take to patch and reasons for that, then sure, 90 days seems more than needed leeway for Microsoft. But I don't know how things worked and I've seen enough to assume that both scenarios are possible.
Vendors with a quite good track record should be allowed to have some slip ups. You cannot compare a vendor who doesn't fix anything on time with one that usually fix issues promptly but occasionally shows a delay on a report. The process should take that into account. I think the binary handling by Google on this one is not very well thought-out.