Windows 10 0day exploit goes wild, and so do Microsoft marketers(arstechnica.com)
arstechnica.com
Windows 10 0day exploit goes wild, and so do Microsoft marketers
https://arstechnica.com/security/2017/02/op-ed-when-marketers-drive-microsofts-0day-exploit-communications-we-all-lose/
77 comments
Does anybody know how many days it would take from when a critical security bug is discovered in Windows and assuming that the fix is just a few lines of code and not a component rewrite and marketing is not in the way, I am wondering how many steps are from when a fix is created until is released.(I imagine that there may some QA and some managers that need to approve it but I have no idea)
It depends. Some bugs can be fixed easily and some might be too complicate to fix even though it looks simple. Usually all critical bugs are attended as soon as they are created (few hours delay). But the actual fix depends on the bug and there is no general formula for that
>assuming that the fix is just a few lines of code
Even assuming that, there could be a massive testing load to ensure that those few lines of code don't mess up something tangentially related, or cause new security issues of their own.
Assuming you just need to add a check for null pointer and that this bug is very critical like hackers are exploiting it, assume engineers create a fix and are 100% it is safe, hopefully there was no other component that was depending on the broken code , how much it will take to fix it,
maybe there is somewhere a history of critical bugs , with the date of when it was found and when it was fixed then we can find the time interval.
The Windows kernel is one of the most mission critical pieces of software in the world. And is easily the most important piece of IP for MS. I'd argue there's no such thing as a "simple fix". I have no doubt even the most trivial of changes has to be very thoroughly vetted.
I've worked on software where without fail every new release would go through more than a week of soak testing.
Microsoft fired it's QA department so that doesn't seem to be a reasonable explanation either.
http://www.computerworld.com/article/2878026/microsoft-to-bu...
http://www.computerworld.com/article/2878026/microsoft-to-bu...
They could have a solution out the door in less than 24h but it may be a mitigation (ie, disable the service) rather than a proper fix. But that's pretty easy. In fact, it's usually the first thing an engineer does when verifying a bug report - "Ok I've reproduced it, now let's shut off the service and make sure the problem goes away."
Release a patch that disables the vulnerable service and give people a way to bypass that and turn it back on once they've taken proper internal measures. (Read the CVE, block ports, etc...)
Release a patch that disables the vulnerable service and give people a way to bypass that and turn it back on once they've taken proper internal measures. (Read the CVE, block ports, etc...)
There is an interesting (and very amusing) article about the general concept:
https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb
URLs auto link as long as you don't indent them.
Disclosure: I work at MS but not on the kernel or anything related to this security bug. Opinions are my own.
I've seen one-line bug fixes introduce many other bugs.
Adding a null check is always suspicious. Is the system in an invalid state? Should it fail fast instead of swallowing the error?
Maybe the code wasn't touched in several years. Maybe the person that wrote it no longer works there. Maybe the code in question doesn't have good test coverage or documentation. There are so many variables to consider when assessing risk of code changes.
I've seen one-line bug fixes introduce many other bugs.
Adding a null check is always suspicious. Is the system in an invalid state? Should it fail fast instead of swallowing the error?
Maybe the code wasn't touched in several years. Maybe the person that wrote it no longer works there. Maybe the code in question doesn't have good test coverage or documentation. There are so many variables to consider when assessing risk of code changes.
Maybe the person that wrote it no longer works there. Maybe the code in question doesn't have good test coverage or documentation
These are not valid excuses for a company the size of Microsoft.
These are not valid excuses for a company the size of Microsoft.
tl;dr: a null deref in windows kernel when you connect to a malicious SMB share
tl;dr: a CVSS 7.8 Windows vulnerability in the SMB service can allow an attacker to DoS any machine with the filesharing service exposed; the possibility of RCE seems to have been discarded; exploits are freely available online. This article complains that Microsoft's communication is lacking details and transparency in times of war
That's not what this article is about though really
Sure, but the main question I had when reading the headline was if I should go into "Oh shit!" mode.
Yes, the vulnerability is client-side AFAIK.
PoC GIF: https://twitter.com/vvalien1/status/826935182456418304
PoC GIF: https://twitter.com/vvalien1/status/826935182456418304
Thanks
He asked a PR person, probably one with little security background (how many security people do you know who went into PR?) gave the stock answer which does happen to actually be good security advice: run the latest supported version with patches.
The reporter was just butthurt about not getting a scoop and decided to write an article complaining about PR practices in place of an actual story.
Really like the click bait title though, it's a nice touch. /s
The reporter was just butthurt about not getting a scoop and decided to write an article complaining about PR practices in place of an actual story.
Really like the click bait title though, it's a nice touch. /s
It's a rant about PR bullshit, specifically this:
>Windows is the only platform with a customer commitment to investigate reported security issues and proactively update impacted devices as soon as possible,
EDIT and this
>The time has come for Microsoft vulnerability disclosure communications to mute the marketers and let the security engineers do the talking instead.
I found it funny to be honest
>Windows is the only platform with a customer commitment to investigate reported security issues and proactively update impacted devices as soon as possible,
EDIT and this
>The time has come for Microsoft vulnerability disclosure communications to mute the marketers and let the security engineers do the talking instead.
I found it funny to be honest
In this case it seems to have been fully-fledged lying, not just bullshit: Microsoft (told the researcher they) delayed releasing this patch so they could release a number of SMB-related fixes at once.
They might have good reasons for doing that, but it isn't true to say they "proactively update impacted devices as soon as possible".
They might have good reasons for doing that, but it isn't true to say they "proactively update impacted devices as soon as possible".
Microsoft always seems to prefer going on offense rather than playing defense. They are one of the least self-aware companies I can think of. For example, this absolutely insane "funeral march" for iPhone and Blackberry they held in 2010 to celebrate the launch of Windows Phone 7 [1]. What other company would even consider this?
[1] https://www.engadget.com/2010/09/10/microsoft-celebrates-win...
[1] https://www.engadget.com/2010/09/10/microsoft-celebrates-win...
They are one of the least self-aware companies I can think of.
That was Uncle Fester's Microsoft. That behavior was an extension of Ballmer's pugilistic personality.
Today's Microsoft is just as tone-deaf, but in a different respect. For the life of me I can't understand why Nadella thinks that their recent behavior wrt. Win 10 is a good idea. E.g. rebooting user's machines during presentations, having spyware that it's not possible to disable, advertising in the OS, etc.
That was Uncle Fester's Microsoft. That behavior was an extension of Ballmer's pugilistic personality.
Today's Microsoft is just as tone-deaf, but in a different respect. For the life of me I can't understand why Nadella thinks that their recent behavior wrt. Win 10 is a good idea. E.g. rebooting user's machines during presentations, having spyware that it's not possible to disable, advertising in the OS, etc.
I am still shocked that Windows was recoverable from the fiasco of XP security problems. They have gotten exponentially better in security over the years.
The NT Kernel is a very secure and resilient design, it was just mucked up over the years with Win32 blurring the lines between the kernel and userland. MinWin was an internal project that started in Windows 7 where the tendrils of things like Win32 were extricated from the kernel. In addition to improving security, this also enabled things like multi-platform support and headless servers.
I understand what you're saying "in theory".
But in practice, here's what happened. In 2002 Chairman Bill said:
And yet, 15 years later, we're discussing yet another 0day. And Win 10's built in spyware is the absolute opposite of "privacy".
I'd rather judge Microsoft on their actual historical record, and not on whether Cutler's initial design for NT was secure and resilient.
But in practice, here's what happened. In 2002 Chairman Bill said:
An internal Microsoft e-mail tells the software
giant's employees that security and privacy are
the most important issues for the company's products.
And yet, 15 years later, we're discussing yet another 0day. And Win 10's built in spyware is the absolute opposite of "privacy".
I'd rather judge Microsoft on their actual historical record, and not on whether Cutler's initial design for NT was secure and resilient.
Truth be told, Microsoft has among the worst PR agencies/policies from the tech industry. Very bureaucratic, slow to get something out of them, and you usually end up with just canned answers and most questions dodged. It's hardly even worth the effort to contact Microsoft's PR about something.
Unless you know a higher-up exec, like Mary Jo Foley or Paul Thurrott does, for instance, you're unlikely to get a real answer for a security question. For a journalist, writing what you think happened, and then waiting for Microsoft to react, contact you, and tell you what really happened is likely a much more effective strategy to get something out of Microsoft.
Unless you know a higher-up exec, like Mary Jo Foley or Paul Thurrott does, for instance, you're unlikely to get a real answer for a security question. For a journalist, writing what you think happened, and then waiting for Microsoft to react, contact you, and tell you what really happened is likely a much more effective strategy to get something out of Microsoft.
The researcher disclosed the bug one week before Microsoft is scheduled to patch it. I'm sure MS isn't thrilled, but they did drag their feet:
"I decided to release this bug one week before the patch is released, because it is not the first time Microsoft sits on my bugs. I'm doing free work here with them (I'm not paid in anyways for that) with the goal of helping their users. When they sit on a bug like this one, they're not helping their users but doing marketing damage control, and opportunistic patch release."
"I decided to release this bug one week before the patch is released, because it is not the first time Microsoft sits on my bugs. I'm doing free work here with them (I'm not paid in anyways for that) with the goal of helping their users. When they sit on a bug like this one, they're not helping their users but doing marketing damage control, and opportunistic patch release."
The researcher sounds really petty. They're patching it, but not on this person's schedule so he's causing microsoft and USERS problems they didn't have before.
If they weren't patching, I'd understand, but this isn't the right way to get attention in my book.
If they weren't patching, I'd understand, but this isn't the right way to get attention in my book.
There are very competent people on this planet who make a very good buck out of zero-days (not to mention remotely control users' machines, and steal data). IMO the researcher didn't want that particular vulnerability to dwell on somebody's todo list for several years.
It definitely puts pressure on MS but I don't think that's bad. Corporations have demonstrated time and again that the only way to get them to move is a PR hype.
If they want researchers to stop doing preliminary public disclosures, they should prioritize security higher than PR damage control.
It definitely puts pressure on MS but I don't think that's bad. Corporations have demonstrated time and again that the only way to get them to move is a PR hype.
If they want researchers to stop doing preliminary public disclosures, they should prioritize security higher than PR damage control.
> IMO the researcher didn't want that particular vulnerability to dwell on somebody's todo list for several years.
Except the researcher themselves knew it was one more week, and not "several years." You cannot claim they were ignorant if their own statements shows that they were not.
Except the researcher themselves knew it was one more week, and not "several years." You cannot claim they were ignorant if their own statements shows that they were not.
You might be right. But they only claimed it, didn't they?
I personally like Windows 10 a lot and I applaud any effort to turn it into a long-term stable OS.
I personally like Windows 10 a lot and I applaud any effort to turn it into a long-term stable OS.
Well, if MS claims the patch is coming in one week, one approach might be to wait one week and then release the exploit. Works out regardless of the accuracy of the claim.
Patch Tuesday is the second Tuesday of each month. Unless something odd happens, you can count on the fix being out a week from tomorrow. There's also a justification for this — they sat on it because they were releasing other SMB-related patches on the February Patch Tuesday. I don't really think anybody can reasonably argue that MS would not release the fix next week. But that's not the point.
This bug was reported in December, and there's no reason to believe that they didn't have a patch in time for inclusion in the January Patch Tuesday. They chose to withhold that patch due to non-technical, apparently PR-related, reasons, and the researcher in question is complaining that this has happened before with other bugs reported by him. That's a pretty cavalier approach to security, and early disclosure is the only way the researcher can punish MS for it.
This bug was reported in December, and there's no reason to believe that they didn't have a patch in time for inclusion in the January Patch Tuesday. They chose to withhold that patch due to non-technical, apparently PR-related, reasons, and the researcher in question is complaining that this has happened before with other bugs reported by him. That's a pretty cavalier approach to security, and early disclosure is the only way the researcher can punish MS for it.
It's slightly worse than that: the bug was reported in September; December appears to be when they had the patch ready.
So there were two months of apparently unjustified delay.
So there were two months of apparently unjustified delay.
Sure, if MS promised to issue a patch in January, then go ahead and release info when they don't. But it's weird to wait for a February patch, and then release a week early.
Like I'm more or less ok with "full disclosure upon discovery" as a consistent release policy. Or "wait for a patch up to 90 days". Or several other models. "Wait until one week before patch" is an oddball policy which seems like it has all the cons and none of the pros of other models.
Like I'm more or less ok with "full disclosure upon discovery" as a consistent release policy. Or "wait for a patch up to 90 days". Or several other models. "Wait until one week before patch" is an oddball policy which seems like it has all the cons and none of the pros of other models.
Releasing a week early makes for a smallish window during which the exploit is unpatched and in the wild, while still being impactful enough that it forces Microsoft to react to it somehow. I'm not sure it's the Right Way of Doing Things, but it's defensible.
They chose to withhold that patch due to non-technical, apparently PR-related, reasons
Do you know that, it is it just speculation? I could speculate that there were technical reasons around having two smb patchsets to test in various combinations vs bundling into one.
Do you know that, it is it just speculation? I could speculate that there were technical reasons around having two smb patchsets to test in various combinations vs bundling into one.
The cynical answer would be: try harder Microsoft, and do not let your customers remain vulnerable simply because you can't test two patch-sets at the same time.
If 'trying harder' is not possible due to financial reasons, then the only recourse is disclosure.
This bug will be fixed now, but certainly could have been excluded again because of technical reasons---they're publishing a separate set of patches on SMB again soon, maybe those patches have higher priority to people on the Microsoft org-chart than the patches for this bug.
When companies aren't given hard deadlines for disclosure, they'll just delay forever because there is always a technical reason that you can't do enough testing to satisfy yourself, while doing X, Y, Z which are added to your schedule for political/financial reasons.
If 'trying harder' is not possible due to financial reasons, then the only recourse is disclosure.
This bug will be fixed now, but certainly could have been excluded again because of technical reasons---they're publishing a separate set of patches on SMB again soon, maybe those patches have higher priority to people on the Microsoft org-chart than the patches for this bug.
When companies aren't given hard deadlines for disclosure, they'll just delay forever because there is always a technical reason that you can't do enough testing to satisfy yourself, while doing X, Y, Z which are added to your schedule for political/financial reasons.
Why do they deserve the benefit of the doubt when their press release contains actual lies? When someone lies to me everything they say becomes suspect. It's the standard we expect individuals to live up to, why do you want to give more slack to a company?
Further, so what? There's always some problem. They should either suck it up and work harder or come clean and give users actual choice in how to respond.
Further, so what? There's always some problem. They should either suck it up and work harder or come clean and give users actual choice in how to respond.
Why do they deserve the benefit of the doubt when their press release contains actual lies?
I didn't say they do. I responding to the parent post on the bit I quoted ("They chose..."). If it's irrelevant under other precondition, take it up with the parent post.
I didn't say they do. I responding to the parent post on the bit I quoted ("They chose..."). If it's irrelevant under other precondition, take it up with the parent post.
«He told Ars that the software maker initially planned to patch the flaw in December but later decided to delay the release until February so it could be included with other planned SMB fixes.» «it is not the first time Microsoft sits on my bugs»
So they already reneged once on this bug which fits into a previous pattern. If that is right putting pressure on them sounds entirely justified and not at all petty.
So they already reneged once on this bug which fits into a previous pattern. If that is right putting pressure on them sounds entirely justified and not at all petty.
Just because there are other people who act totally unethically doesn't mean you get bonus points for doing kinda the right thing.
MS is acting 'totally unethically' by not patching this bug immediately and rewarding the researcher.
Meh. The bug requires you to connect Windows to a malicious SMB server.
Now that everybody knows that, if anybody is really concerned, they can stop SMB connections from LAN to WAN by blocking TCP 139, 445 and UDP 137, 138.
Now that everybody knows that, if anybody is really concerned, they can stop SMB connections from LAN to WAN by blocking TCP 139, 445 and UDP 137, 138.
> Now that everybody knows that
Wait, when did everyone become aware of that? I'm willing to bet the vast majority of windows users have no idea. _Some_ people only know _because_ he released the bug.
Wait, when did everyone become aware of that? I'm willing to bet the vast majority of windows users have no idea. _Some_ people only know _because_ he released the bug.
I'm now aware, and I was able to block connections in my organizations firewall that protects a few thousand users. Not every single user needs to be aware for it to be effective.
Yes, but the point is you wouldn't be aware unless he released the info. He gave individual users an option to protect themselves in the absence of a patch from MS.
You're absolutely right! The researcher acted in a questionably ethical manner here by waiting to disclose the vulnerability. The only ethical approach is full and immediate public disclosure.
Full and immediate public disclosure seems irresponsible and counterproductive IMO.
The last thing I'd want as a developer or a manager is to wake up in the morning with a PR shit storm and angry users on my hands because some inane script kiddie found it appropriate to disclose a zero day without reaching out to me or my team first. Sure, some other guy might know about or find the vulnerability and exploit it by the time a patch comes out; it's guaranteed that they will if you release a 0day.
We can discuss all we want on what a reasonable delay to release a patch might be, but absolutely not on the notion that immediate public disclosure is the right thing to do. It wastes everyone' time, disrupts workflows, puts fellow developers, their managers, and their users under intense pressure and stress, all so some kid can enjoy an ego trip. To me it just seems gross and childish.
The last thing I'd want as a developer or a manager is to wake up in the morning with a PR shit storm and angry users on my hands because some inane script kiddie found it appropriate to disclose a zero day without reaching out to me or my team first. Sure, some other guy might know about or find the vulnerability and exploit it by the time a patch comes out; it's guaranteed that they will if you release a 0day.
We can discuss all we want on what a reasonable delay to release a patch might be, but absolutely not on the notion that immediate public disclosure is the right thing to do. It wastes everyone' time, disrupts workflows, puts fellow developers, their managers, and their users under intense pressure and stress, all so some kid can enjoy an ego trip. To me it just seems gross and childish.
The last thing I'd want as a developer or manager is to wake up in the morning with a PR shitstorm and enraged users because I shipped some vuln.
What full disclosure does it put everyone on the same footing. Developers, users, and attackers all at once. It reduces the window for potential abuse as much as possible. As policy, it sharpens the incentives to be very careful in your development processes and improve security measures.
It's worth considering that this is actually a long-running historical debate. One of the commonly espoused positions is yours - contact devs privately, give them a reasonable amount of time to patch, then disclose after a patch. After all, it minimizes disruption to production planning and workflows and still protects users. Seems reasonable right? Everyone wins!
Catch is, it's historically been abused by companies more interested in their production schedules than the security of their users. Maybe that's not you! In which case, well done, you're completely awesome! However, this has historically turned out to be rather a lot of software companies.
Full disclosure, the policy I advocated for, seeks to short-circuit this. It offers maximum information to a maximum of people in a minimum of time. It pressures companies to fix their products rapidly and to ship better products in the first place. It also offers users the ability to be aware that they may be under attack and protect themselves in lieu of a patch which may or may not ever come into being.
At the end of the day, the question is this: who are you protecting with your disclosure policy? I would suggest that the policy you have advanced seeks to balance the interests of users and of developers/managers. It's perhaps worth considering that your users may prefer a policy that aligns your incentives more with theirs. Perhaps your customers might prefer policies that encourage a proactive stance.
What full disclosure does it put everyone on the same footing. Developers, users, and attackers all at once. It reduces the window for potential abuse as much as possible. As policy, it sharpens the incentives to be very careful in your development processes and improve security measures.
It's worth considering that this is actually a long-running historical debate. One of the commonly espoused positions is yours - contact devs privately, give them a reasonable amount of time to patch, then disclose after a patch. After all, it minimizes disruption to production planning and workflows and still protects users. Seems reasonable right? Everyone wins!
Catch is, it's historically been abused by companies more interested in their production schedules than the security of their users. Maybe that's not you! In which case, well done, you're completely awesome! However, this has historically turned out to be rather a lot of software companies.
Full disclosure, the policy I advocated for, seeks to short-circuit this. It offers maximum information to a maximum of people in a minimum of time. It pressures companies to fix their products rapidly and to ship better products in the first place. It also offers users the ability to be aware that they may be under attack and protect themselves in lieu of a patch which may or may not ever come into being.
At the end of the day, the question is this: who are you protecting with your disclosure policy? I would suggest that the policy you have advanced seeks to balance the interests of users and of developers/managers. It's perhaps worth considering that your users may prefer a policy that aligns your incentives more with theirs. Perhaps your customers might prefer policies that encourage a proactive stance.
> It reduces the window for potential abuse as much as possible.
Immediate public disclosure to everyone, including blackhats, reduces the window for potential abuse as much as possible? Cynical answer: You are technically correct … It reduces the window of potential abuse to 0. While at the same time it opens the window for actual (guaranteed) abuse.
Generally speaking, immediate public disclosure is harmful to the very people you want to protect with the disclosure because they are left defenseless to hordes of intruders that, before the disclosure, probably didn’t even know about the issue. By “put[ting] everyone on the same footing”, the developers scramble to release something, anything, that kind of works to mitigate the situation which causes the software quality to suffer.
Even high quality software with careful developers will occasionally suffer from security vulnerabilities. You put every company and individual under general suspicion of misusing responsible disclosure, and by immediate public disclosure you want to get back at them for having a security issue in their software. You don’t care about protecting anyone.
Immediate public disclosure to everyone, including blackhats, reduces the window for potential abuse as much as possible? Cynical answer: You are technically correct … It reduces the window of potential abuse to 0. While at the same time it opens the window for actual (guaranteed) abuse.
Generally speaking, immediate public disclosure is harmful to the very people you want to protect with the disclosure because they are left defenseless to hordes of intruders that, before the disclosure, probably didn’t even know about the issue. By “put[ting] everyone on the same footing”, the developers scramble to release something, anything, that kind of works to mitigate the situation which causes the software quality to suffer.
Even high quality software with careful developers will occasionally suffer from security vulnerabilities. You put every company and individual under general suspicion of misusing responsible disclosure, and by immediate public disclosure you want to get back at them for having a security issue in their software. You don’t care about protecting anyone.
The key difference between before and after disclosure is that people are vulnerable and ignorant before, with no chance whatsoever to defend themselves. After disclosure, people are vulnerable and warned, with the potential to defend themselves. In both scenarios, there is the very real threat of attackers.
I care about protecting people. I hold the idiosyncratic belief that keeping secrets from the vulnerable does not make them safer. I understand that many people do not agree with this.
I care about protecting people. I hold the idiosyncratic belief that keeping secrets from the vulnerable does not make them safer. I understand that many people do not agree with this.
> After disclosure, people are vulnerable and warned, with the potential to defend themselves.
Only in your wildest wet dreams are people able to defend themselves. You maybe, but certainly not random Joe down the street. And that's assuming Joe reads tech news to begin with.
The only people who this significantly affects in practice are a) the black hats who now have a window of opportunity to do mischief, and - much more importantly - b) the devs who end up needing to patch software under intense pressure.
But anyway, as you pointed out, it's been an ongoing debate for decades.
Only in your wildest wet dreams are people able to defend themselves. You maybe, but certainly not random Joe down the street. And that's assuming Joe reads tech news to begin with.
The only people who this significantly affects in practice are a) the black hats who now have a window of opportunity to do mischief, and - much more importantly - b) the devs who end up needing to patch software under intense pressure.
But anyway, as you pointed out, it's been an ongoing debate for decades.
It also affects professionals who read CVEs and posts to full-disclosures to learn that what mitigations are available. Those tend to be the people responsible for protecting whole networks, who are capable of deploying Snort signatures or roping off vulnerable boxes. Or just people who appreciate knowing that their servers might be vulnerable. I've been in a couple of those positions.
The standing assumption in security is that for any given vuln, the black hats already know. This is a defensive assumption, stemming both from the general unknowability of the subject and the frequent occurrences of it actually being demonstrably true. It's the devs who need to patch software under intense pressure, and the product organization that sets their priorities, and the growth hackers who just want things shipped now whose priorities could perhaps stand to gain from a little adjustment.
I've worked places where engineers would have welcomed that sort of outside pressure.
To put it another way, I do not believe that keeping people ignorant keeps them safe. I fully understand why some people might prefer to believe otherwise.
The standing assumption in security is that for any given vuln, the black hats already know. This is a defensive assumption, stemming both from the general unknowability of the subject and the frequent occurrences of it actually being demonstrably true. It's the devs who need to patch software under intense pressure, and the product organization that sets their priorities, and the growth hackers who just want things shipped now whose priorities could perhaps stand to gain from a little adjustment.
I've worked places where engineers would have welcomed that sort of outside pressure.
To put it another way, I do not believe that keeping people ignorant keeps them safe. I fully understand why some people might prefer to believe otherwise.
If we're gonna be brutally realistic about human nature: most people won't budge if they are comfortable and maintain an illusion that things are under control, unless there's external pressure. I have no links to scientific studies but IMO that's common sense and is widely observable.
I too find the actions of the researcher slightly questionable but he himself said this isn't the first time and he's sick of important fixes being delayed.
You know what? It worked. You might disagree with the approach, but what about the results? MS is absolutely gonna release a fix now, there's no denying that.
I too find the actions of the researcher slightly questionable but he himself said this isn't the first time and he's sick of important fixes being delayed.
You know what? It worked. You might disagree with the approach, but what about the results? MS is absolutely gonna release a fix now, there's no denying that.
EdHominem(1)
What would your solution be?
As a longtime windows user: No.
There's no excuse for them to delay patching it without explaining to him in detail why there's a delay, and even if he had been a dick about it, they should've had a very good explanation for the public.
They had neither and that is unacceptable.
Reason being: Even if he doesn't publicize it, someone else might know and be using it without MS knowledge. Anytime you become aware of an exploit one must act as if it already is being abused.
There's no excuse for them to delay patching it without explaining to him in detail why there's a delay, and even if he had been a dick about it, they should've had a very good explanation for the public.
They had neither and that is unacceptable.
Reason being: Even if he doesn't publicize it, someone else might know and be using it without MS knowledge. Anytime you become aware of an exploit one must act as if it already is being abused.
What is the thresshold where you do decide to release the bug description?
Microsoft has sat on bugs for years saying they were working on them. Do you disclose after a week? A Month? a Year?
If it were a company or team with a solid history of patching swiftly I could see trusting them. But this is Microsoft, they have the resources to fix bugs. They chose an OS design that sacrificed security for other things. Worst, they chose to betray trust in the past. Someday Microsoft might earn that trust back, but they are a long way off from earning mine.
If I informed them of the bug and it wasn't fixed in the next patch, then I would need solid evidence they are working on it or I release the exploit. If it were a group I trusted I would follow up several times until I lost faith in them.
Microsoft has sat on bugs for years saying they were working on them. Do you disclose after a week? A Month? a Year?
If it were a company or team with a solid history of patching swiftly I could see trusting them. But this is Microsoft, they have the resources to fix bugs. They chose an OS design that sacrificed security for other things. Worst, they chose to betray trust in the past. Someday Microsoft might earn that trust back, but they are a long way off from earning mine.
If I informed them of the bug and it wasn't fixed in the next patch, then I would need solid evidence they are working on it or I release the exploit. If it were a group I trusted I would follow up several times until I lost faith in them.
I don't know, I guess that really depends on the frequency and context of 'not the first time Microsoft sits on one of my bugs'. I'm not a security researcher but I suppose if I was and Microsoft was sitting on my bugs pretty frequently and they were really serious I might just give them a shot across the bows one fine day.
And when Microsoft do cut QA short people complain that Microsoft doesn't care about quality/is using retail as a beta test. It is really a no-win situation to be honest.
The correct way to do this is immediately release a bulletin to admins to block the affected service, then push a patch to disable it, then push a patch to fix and reenable it when they feel ready.
It's only unwinable because Microsoft refuses to take a PR/cash hit of telling people to stop using something while it's broken.
It's only unwinable because Microsoft refuses to take a PR/cash hit of telling people to stop using something while it's broken.
>The researcher sounds really petty.
We live in the age of security researcher marketing. No one wants to be the anonymous guy who submitted sometnhing. They want to be the star and have all these articles written about them and all this attention. The easiest, of course unethical, way to get this is to release something before its patched regardless of what the OEM is doing in regards to patch scheduling. To release one week before patch Tuesday is a pretty big middle-finger to a lot of people for no other reason than what looks like personal gain or spite.
I imagine this decision is going to bring him a lot of negative attention. I wouldn't hire someone who 0-day'd a security bug a week before its patch out of spite.
Thankfully, connecting to a random smb is a fairly edge case. I believe most firewalls block smb to/from the internet and most consumer ISPs block the protocol outright. This probably won't have much of a real world impact.
We live in the age of security researcher marketing. No one wants to be the anonymous guy who submitted sometnhing. They want to be the star and have all these articles written about them and all this attention. The easiest, of course unethical, way to get this is to release something before its patched regardless of what the OEM is doing in regards to patch scheduling. To release one week before patch Tuesday is a pretty big middle-finger to a lot of people for no other reason than what looks like personal gain or spite.
I imagine this decision is going to bring him a lot of negative attention. I wouldn't hire someone who 0-day'd a security bug a week before its patch out of spite.
Thankfully, connecting to a random smb is a fairly edge case. I believe most firewalls block smb to/from the internet and most consumer ISPs block the protocol outright. This probably won't have much of a real world impact.
Well, I'm not sure I agree in this case.
> He told Ars that the software maker initially planned to patch the flaw in December but later decided to delay the release until February so it could be included with other planned SMB fixes.
> He told Ars that the software maker initially planned to patch the flaw in December but later decided to delay the release until February so it could be included with other planned SMB fixes.
Presuming the USERS don't ALREADY have a problem is the inherent flaw in your logic.
A researcher who earns no money finding exploits is at an inherent disadvantage to black hats who DO get funding for selling the exploits they find.
A researcher who earns no money finding exploits is at an inherent disadvantage to black hats who DO get funding for selling the exploits they find.
They weren't patching, in this case the process has taken months. It's just marketing so they can say there's just a small number of bugs.
> so he's causing microsoft and USERS problems they didn't have before.
He's not causing problems, he's solving them.
He's not causing problems, he's solving them.
Gifting exploiters a 0day before the KNOWN patch release date, is causing problems.
No, it was only a 0day before he made it public. He is merely providing security-conscious persons information and a way to defend themselves from an exploit which MS has not fixed. He is turning a 0day into a known vuln.
You know who sounds really petty though? The whiners taking Microsoft's side despite them missing the bug in the first place and sleeping on the report, and now attacking the person who reported it.
> They're patching it, but not on this person's schedule so he's causing microsoft and USERS problems they didn't have before.
Not in the slightest. You do not understand how the internet works. The vulnerable systems were vulnerable yesterday, and are vulnerable today because MS didn't think it was worth hurrying to patch them. Users' harm was caused by Microsoft who gave them a broken product, and by any hypothetical hackers, not by a security researcher telling the public what the hackers probably already knew.
Microsoft had a chance to release an emergency bulletin as soon as they were informed of the vuln, with mitigation steps. (ie, block SMB, etc) They didn't, and in fact spent time recommending useless things (Win10, Edge) that only serve to slander competitors by implication, and pimp more of their products.
Microsoft needs the understand that the new timeframe for releasing mitigations, if not patches, is closer to 24h than 24 days. But even if they hit that metric, they don't deserve any fanfare until they do it without lying or misdirecting.
Downvoters: RTFA - The Microsoft reports are intentionally misleading wrt. steps customers need to follow to be safe, and they claim to be better that their competitors (Apple, etc) in this regard despite obvious and consistent proof to the contrary. Microsoft is responding to security concerns with marketing speak, and they're knowingly setting their customers up for catastrophic data loss or hacks by recommending useless fixes.
> They're patching it, but not on this person's schedule so he's causing microsoft and USERS problems they didn't have before.
Not in the slightest. You do not understand how the internet works. The vulnerable systems were vulnerable yesterday, and are vulnerable today because MS didn't think it was worth hurrying to patch them. Users' harm was caused by Microsoft who gave them a broken product, and by any hypothetical hackers, not by a security researcher telling the public what the hackers probably already knew.
Microsoft had a chance to release an emergency bulletin as soon as they were informed of the vuln, with mitigation steps. (ie, block SMB, etc) They didn't, and in fact spent time recommending useless things (Win10, Edge) that only serve to slander competitors by implication, and pimp more of their products.
Microsoft needs the understand that the new timeframe for releasing mitigations, if not patches, is closer to 24h than 24 days. But even if they hit that metric, they don't deserve any fanfare until they do it without lying or misdirecting.
Downvoters: RTFA - The Microsoft reports are intentionally misleading wrt. steps customers need to follow to be safe, and they claim to be better that their competitors (Apple, etc) in this regard despite obvious and consistent proof to the contrary. Microsoft is responding to security concerns with marketing speak, and they're knowingly setting their customers up for catastrophic data loss or hacks by recommending useless fixes.
> You do not understand how the internet works.
> Downvoters: RTFA
These things break the HN guidelines. Please (re-)read them and post civilly and substantively, or not at all:
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newswelcome.html
> Downvoters: RTFA
These things break the HN guidelines. Please (re-)read them and post civilly and substantively, or not at all:
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newswelcome.html
Absolute minimum: 1 month after patch.
Also: Leave 1 month, as an absolute minimum, to publish a patch.
Why that? Because it takes time to track a bug and fix it and test the fix and ship it to 1 billion consumers in 150 countries and languages.
Welcome to the world of real users where things take time to happen.
Of course, one may think that he's an idealistic enthusiast pressuring the evil big companies when giving them less time. But nope, the only thing one may truly accomplish is being an unrealistic asshole putting millions of computers and people at risk. Think twice before you disclose. There will also be your mom's computer on the other end of that 0-day ;)