Google Researcher Publishes Windows 10 Zero-Day Security Vulnerability

https://www.forbes.com/sites/daveywinder/2019/06/12/warning-windows-10-crypto-vulnerability-outed-by-google-researcher-before-microsoft-can-fix-it/

by jaden • 7 years ago

197 107 7 years ago

forbes.com

michaelt• 7 years ago

  "Personally I think it's a bit harsh,"
  Wright says, "every fix is different
  and they should allow for some
  flexibility in their deadline."

As far as I can tell, (1) this is a denial-of-service bug, not a privilege escalation or remote root exploit, i.e. a low-severity bug; (2) it is unlikely any code depends on the infinite loop triggering, meaning this fix doesn't call for great architectural upheval; and (3) the deadline was already extended to 91 days, rather than the usual 90.

If you'd give out deadline extensions for this bug you'd give them out for almost any bug, so you may as well not have deadlines at all.

nocturnial• 7 years ago

For anyone wondering why the one (1) day extra, microsoft has a fixed patching schedule. The patches were released on june 11 patch tuesday. They needed the extra day to check if it was included in the june 11 patches.

Operyl6• 7 years ago

Yep. If a patch is scheduled to go out within 14 days of the 90 days, they will work with you a bit. But that's the absolute max.

gpm• 7 years ago

Does anyone else think that microsoft's policy here is ridiculous?

"We know your stuff is broken to the point of being insecure and a risk to your business because we screwed up when making it. We know how to fix it. We've done the work to fix it. No we won't actually fix it until a few days from now.

hibbelig• 7 years ago

The _intent_ was to release this patch on June 11, but Microsoft didn't make it.

adrianmonk• 7 years ago

It's just game theory. You have to have follow through, or people will learn that they can ignore you.

Although the ethics are very different, think of a loan shark. What do they get out of breaking the kneecaps of a person who failed to pay their debt? It doesn't bring back the lost money.

But it does show you are committed to following through with consequences. And that changes the behavior of people who might face those consequences.

MattSteelblade• 7 years ago

The bug report https://bugs.chromium.org/p/project-zero/issues/detail?id=18...

altmind• 7 years ago

Seems to be a DoS against the application using cryptoapi. certutil <cer> seems to hang but can be killed without negative effects on the system. Ant timeouts in cryptoapi ops will prevent this. According to the report: Severity-low

I'm really dont think forbes is a good media for publishing the digest like this - the public there is very broad and dont have the expertise to evaluate what've been presented.

olliej3• 7 years ago

It's not a zero day, it's a 91 day. Some bugs can be complex to do root cause, fix, and verify a bug. But 3 months for what appears to be a validation failure seems more than sufficient.

Obviously we'll need to wait until the actual fix comes out to see if the fix was more substantial.

_wmd• 7 years ago

I've been around infosec for 21 years and this is still a 0day. That term has no strong definition, certainly not one that would allow precise interpretation as above, but in this case even a vague sense of what it means covers the situation easily: _users_ have had no time to patch

olliej3• 7 years ago

Zero day is almost always used in the context of “the bug was unknown and first seen during an attacks”.

The alternative definition (that zero day means purely day of publicizing) would mean that if you had two bugs in a product and you notified the vendor of one. Then three months later published both, they would both be zero days, and should be treated as such.

A 0day means publicizing a bug without the vendor themselves having the potential to have a fix.

Very simply: if a virus comes out attacking a known but unfixed bug in MS software no one would call it a zero day. Every article would say it was a bug that Microsoft knew about but hadn’t fixed.

all_blue_chucks2• 7 years ago

Can confirm. "Zero day" means you've had zero days to patch. The term has been used this way since, IIRC, the late 1990s. See Phrack 53 for an example:

http://www.textfiles.com/magazines/PHRACK/PHRACK53

hermitdev2• 7 years ago

Some bugs are just really hard to find, diagnose, verify, fix and then verify the fix.

At a previous employer, I was responsible for a very long running service that usually had an uptime of about 9-10 months. At one point we noticed we had a memory leak that was directly related to the number of requests the service processed. The kicker: it leaked less than a single byte per request in an x64 C++ service. It took us about a year to find the cause. Turned out to be a bug in an in house logging lib that failed to create a rolled log file in case of a filesystem full or disk usage quota exceeded condition, which we rarely ever encountered in development because we wiped logs every week in dev, but on a more relaxed schedule in prod.

olliej3• 7 years ago

Agreed, like I said it will be interesting see what the final patch set will be.

Diagnosing some bugs can take a huge amount of time, work, and luck (I had a bug one time where the repro steps required a specific google reader account and a stapler resting on the space bar for an hour or so).

But for a bug that has a trivial test case, especially in the context of parsing/validating bugs generally, isolating the bug should not be hugely challenging (a few days).

Much more likely in my experience is that the nature of the specific flaw indicates that there is a pattern in your code base that is potentially unsafe - at that point you want to fix all instances of the pattern, because when you release the patch you’re documenting the flawed pattern.

Operyl6• 7 years ago

His Twitter thread about it, complete with the usual complaining about the 90 day policy from the gallery: https://twitter.com/taviso/status/1138469651799728128

(I think the policy is fine, personally).

ClassyJacket• 7 years ago

"As already mentioned, Project Zero has a 90 day disclosure deadline and this was applied to this vulnerability. It was first reported by Ormandy on March 13, then on March 26 Microsoft confirmed it would issue a security bulletin and fix for this in the June 11 Patch Tuesday run."

How is that a zero day? Isn't it a 91-day? What is the meaning of zero day in this context if there were actually 91 days between reporting to Microsoft and public release?

anaisbetts• 7 years ago

Users / IT Admins got zero-day'd, Microsoft didn't

masklinn• 7 years ago

So not a zero-day.

boringuser1• 7 years ago

Lots of people pretending Google has Microsoft's best interests at heart.

CydeWeys• 7 years ago

Where is this happening?

brynet3• 7 years ago

Lately OpenBSD has been consistently pushing out new security errata, with as quick as a ~3 day turnaround from finding/reporting to released fix, even for difficult issues; like Intel MDS.

If OpenBSD can do that, why can't Microsoft.

xyzzyz2• 7 years ago

Because if OpenBSD pushes out broken patch, nobody will care, as this is business in usual in free software world, shit breaks, WITHOUT ANY WARRANTY and all that. On the other hand, if Microsoft does that, customers paying millions of dollars will get pissed.

That said, 100+ days to push out a patch is indeed ridiculous.

brynet3• 7 years ago

Except OpenBSD isn't shipping broken patches.. so I'm struggling to see your point.

There's a pretty substantial difference between 3 days and 90 days (or 100). And one could argue that any amount of days after the embargo ends, is plenty opportunity for their paying customers to remain vulnerable without having provided any fixes, regardless of whether it is broken or not.

wbl2• 7 years ago

Microsoft also doesn't have a warranty.

SmellyGeekBoy4• 7 years ago

this is business in usual in free software world, shit breaks, WITHOUT ANY WARRANTY and all that.

I'm struggling to understand how this can be true when the vast majority of the world's internet infrastructure runs on free software.

hermitdev2• 7 years ago

Not all bugs are equal, especially when it comes to security bugs. They may range from "oops, I forgot to check an array bounds" versus "the entire implementation is fucked due to a bad architecture and we have to rewrite from scratch to fix this".

I'm stating this with no judgment on either OpenBSD or MS. Ive used OpenBSD in the past, and I've a lot of respect for them. I also work in a heavy Windows shop, and I appreciate MS's desire to fix issues while maintaining backwards compatibility. Doing so for MS often involves horrible hacks when 3rd party software relies upon either undocumented internal APIs or broken APIs. Prime example is the current battle with Win10 and anti cheat software causing green screens.

noname120• 7 years ago

Can we change the link to the original source[1]? The current article[2] is sensationalized and contains inaccuracies.

[1] https://twitter.com/taviso/status/1138469651799728128

[2] https://www.forbes.com/sites/daveywinder/2019/06/12/warning-...

helper• 7 years ago

Tavis didn't write the bug he just found it (through a lot of hard work). This was free security research given to Microsoft. He gave them a very reasonable amount of time before disclosing the bug (if the disclosure window was 180 days and MS missed it people would be complaining just the same as 90 days).

There's no reason why someone else couldn't discover this bug and exploit it. I would rather know that I am vulnerable then be ignorant and assume my software was safe when it in fact was not.

Thanks taviso for all the great security work you do. (Also 2004 me would like to thank you for your cool fvwm configs).

oblio• 7 years ago

(Also 2004 me would like to thank you for your cool fvwm configs).

So much time wasted^W invested in those FVWM configs... I could never get it working quite as magically as Tavis Ormandy or Thomas Adam made it look like.

Aissen• 7 years ago

To anyone who still thinks a 90-days deadline (with up to 14 additional days for patch release alignment) isn't fair enough, I invite you to look at the timeline for this report:

https://blog.quarkslab.com/reverse-engineering-broadcom-wire...

This is is remote code exec on any device. Yet without hard deadlines, vendors stall, lie, etc. This isn't the first example of this. There has been many throughout the past. Project Zero's policy is actually very well thought, and state of the art IMHO.

oaiey2• 7 years ago

I think it is fair and necessary as an incentive to immediately start working on it. It is also right to publish them after 90 days. I just think it is not fair to blame or make fun of companies for failing on delivery within 90 days what happens here regularly (see: upvotes for the article).

When developing a low risk application with a fancy DevOps infrastructure everyone expect bug fix delivery in hours or maximum the 2 weeks sprint.

90 days is not much time when patching operating systems or mission critical software. Windows is used in literally all regulated environments, from aircrafts to medical devices. The amount of necessary paper work and the amount testing to reduce risk is beyond what anyone not in that business can imagine.

SmellyGeekBoy4• 7 years ago

I just think it is not fair to blame or make fun of companies for failing on delivery within 90 days what happens here regularly (see: upvotes for the article).

Are people upvoting just to "make fun" of Microsoft? I assumed it was for visibility or to share an interesting insight into the inner workings of the security industry.

kriro• 7 years ago

Quite frankly, a multi billion dollar software company like Microsoft should be ashamed of themselves for not fixing a 0-day in 90 days. Even with all the non-coding involved and rolling it out properly they should probably be ashamed if they can't do it in a week.

wglb2• 7 years ago

How about not putting the flaw in in the first place?

dagaci• 7 years ago

Writing code and especially bug fixing issues with complicated code is not as deterministic, as most people imagine. And any developer knows that they should definitely expect the unexpected! but few seriously wonder whats going on when we agree to estimate for them.

So getting up-tight and blaming engineers for having delays is just as random as having a 90 day deadline.

leereeves5• 7 years ago

The majority of users won't see this notice. They'll be more vulnerable because it was published and they still won't know it.

Disclosing the details like this hurts innocent bystanders.

Dylan168075• 7 years ago

Leaving bugs unpatched hurts innocent bystanders.

Disclosure schedules reduce time-to-patch by a lot. But only if they have teeth.

leereeves5• 7 years ago

Project Zero just told everyone how to exploit a bug that won't be fixed for a month.

Even if that is (arguably) better than "having no teeth", that doesn't make it a good idea. Perhaps they can find better teeth, a response that doesn't involve helping bad actors when vendors fail to patch quickly.

protomyth2• 7 years ago

It is curious that Google is perfectly fine keeping an Intel embargo for a long while when it affects them, but is very strict about disclosure when the exploit affects others.

MaupitiBlue• 7 years ago

Just more anticompetitive behavior from Google.

auiya• 7 years ago

Why do you assume Google wouldn't be affected by a Windows bug? Have you forgotten about the compromise of their corp networks by a Chinese APT in 2008/9 which leveraged Windows as the attack surface? The reason for disclosures like this to expedite bug fixes is because they have skin in the game.

protomyth2• 7 years ago

There is a rather large difference between Google’s own OSes, software, and services; and the stuff Google uses. Google has the resources to mitigate problems with what they use from others much faster than most customers of the their competitors.

cyberbase• 7 years ago

Notices, pressure or teeth, should be effective and reduce harm... 1. Notify Manufacture w Details, Start 90 Day Clock. 2. 90 Days, Notify public of discovery and notice date, NO public details. Notify Reputable Security Vendors of details to prep defense of un-patched bug. 3. 180 days release limited details publicly and date of notices to MFG and Sec Vendors. THIS will build public pressure on whole ecosystem and limit impact.

Operyl6• 7 years ago

At step 2: any release of any information is enough to get people looking in the right general direction.

syn0byte• 7 years ago

If you see a bridge or a building with cracks and signs of structural weakness, be sure not to tell anyone, you might start a panic. Instead directly contact the engineering firm and give them at least 90 days to rectify the issue before telling the public.

If you experience a defect in your automobile that causes your steering to cut out intermittently do not alert other users of the same make and model. Instead contact the manufacturer and give them 90 days to fix the issue internally and mail you a new part.

If a drug you are taking causes a serious reaction quietly contact the maker of the drug directly...

See how incredibly stupid "reasonable disclosure" sounds in other industries?

zelon88• 7 years ago

I really can't wait until Microsoft does this to Google and Google sues them into the sunset. Something tells me big G wouldn't like a taste of it's own medicine in this department.

Operyl6• 7 years ago

Except .. Project Zero has released stuff affecting other Google teams before. It’s universal.

jzzmnn• 7 years ago

June 12, 2019 Huge Cybersecurity Global Alert which proves Microsoft patches won't fix 2006-2019 front and backdoor vulnerabilities created by FVEY, Nine, Fourteen Spying Eyes Google belongs too.

Google Researcher Publishes Windows 10 Zero-Day Security Vulnerability

Related Stories