Security is Job One at Microsoft
Just Kidding. Nothing has changed.
Do no Evil! Well some evil, but not so much as to make the entire world angry. Security is job one at Google too, or not.
Google's Project Zero has again revealed a Windows bug before Microsoft fixed it. Project Zero operates under a “once we tell you about a bug you have 90 days to fix it or the kitten gets it or we reveal it to the world” policy. On this occasion, the bug allows attackers to access memory using EMF metafiles, a tool …
"don't be evil". Which was still a pretty stupid motto.
There's a rule of thumb for judging things said by companies or politicians, which is to see whether anyone would sensibly say the opposite. If not, the original saying is a worthless platitude. No company would say 'our motto is "be evil"' (even if it was their intent :-), ergo "don't be evil" is meaningless.
See also: the NHS/education/the economy is safe in our hands, we care about our customers, etc.
"... giving criminals a helping hand by revealing a bug..."
Given MS approach to security, I can only say two words: "Hard" and "neck".
I think that G is -for once- doing the right thing. If MS hasn't patched that shit in ninety days it's provable* they don't give a flying fuck about security.
*note: please notice the letter 'V'! ;-)
"Depending where in the codebase it is..."
They actually were told where exactly the problem was, as per the article. A search in the Windows codebase to find calls to gdi32.dll would be trivial for them to perform, and once that's done making a fix and testing it would be -relatively- easy.
Ninety days is a lot of time for fixing the issue, if the company bothers to put some competent coders to the task.
"Depending where in the codebase it is means that sometimes it takes more time than 90 days to find, test and fix an issue - do you want a rushed/broken fix in 90 days or a proper fix in 100 ?
But surely Microsoft could then tell Google as much? From what I read Microsoft didn't respond at all, not even with a thank you. That sheds some different light onto this.
I can't be sure, but I sincerely doubt that Google wouldn't be open to requests if Microsoft would have responded with a statement that they needed a little more time to fix this (and not one near/on the deadline). Surely even Microsoft should realize that if you don't give any reaction at all it's not unreasonable for the others to assume that you're ignoring them. I mean, they have done so in the past (remember the story about the 4 year old bug a few years back?).
"do you want a rushed/broken fix in 90 days or a proper fix in 100 ?"
How about ENCOURAGING MICRO-SHAFT to "get it right" in the FIRST place, and/or PRIORITIZE fixing security problems? I think Google realizes that security problems in ANY OS has a somewhat negative impact on THEM, even indirectly so. And it is a public service to put some pressure on M$, who won't fix it until they have NO OTHER CHOICE. They're too busy re-re-re-re-inventing the wheel (i.e. Vista, Ape, Ape-point-one, Win-10-nic) instead of producing a QUALITY product without SERIOUS security flaws. They're internal culture of "change the customer to take over the world" is NOT helping. By providing an appropriate DIS-incentive for Micro-shaft's anti-customer ARROGANCE, Google is helping everyone who uses their products [because, locked-in etc.].
Thanks, Google! You've been a BIG help. Again. Seriously!
I'm pretty sure Microshaft COULD have fixed it in a short period of time if they had put enough resources on it. Even a fundamental architectural flaw could've been patched, marshalling device drivers (and other system code) as needed.
And not surprisingly it took quickly advantage of the missed Tuesday patch - ensuring there's a month until the next. Google is weaponizing vulnerability disclosure, and that's dangerous. The draconian approach is stupid, and has clearly aims which are not protecting the users.
Google is weaponizing vulnerability disclosure…
I think I'll add this to my fake news filter…
Go and read the original bug report from March 2016 and see if you still think that.
"original bug report from march 2016"
nice link. thanks for pointing that out.
from the link: "The EMF format essentially works as a proxy for GDI calls"
and as such, SHOULD be subjected to parameter validation, which is PROBABLY the best possible fix for this. DIBs can only be one of a limited set of formats. Compatibility problems are therefore minimized.
In this case, it looks like MS had problems with the patch generation infrastructure that was causing problems with the quality of the builds, so they delayed the patching until they can clean up the build system and generate patches.
If that really is the case, then Google should have given them the benefit of the doubt. If MS had released a bunch of patches this month and ignored the Google bug, then I would say, fair game, Google should let users know.
If however there is no known zero-day and MS are really having problems (which the complete absence of patches would seem to illustrate, then I think it would have been better to sit on it for a further month, or until a zero-day appears.
If however there is no known zero-day…
Think of this again in terms of strict liability and a possible case for negligence. Remember, Google initially notified Microsoft in March 2016 and most of the forensics tools they're using are freely available.
Unknownzero-day exploits are obviously worth more so there is an incentive to keep them from being disclosed.
It was reported on Nov. 16, after November's patch Tuesday. I don't know what their internal testing cycles look like, but assuming they have an internal patch Tuesday "dogfood" cycle a month ahead of public release, it would have to be found/fixed VERY quickly to make the patch set being tested in December and released in January. If there's any complexity at all, it falls to testing in January and release in February. If testing uncovers problems, then it slips beyond the 90 day window.
Not that I like to defend Microsoft, but I think 90 days is pretty short for making a bug public. Of course Google doesn't care, Android's patching system is so broken it doesn't make any difference if someone finding an Android bug released details the same day or waited a year, most of their userbase won't ever see a patch, and even among those who do a minority actually apply them.
While 90 days may be a bit arbitrary, it is more important to hold the vendor (Slurp in this case) accountable. If the vendor wants to navel gaze they earned the abuse they will get when the clock runs out. It is a matter of how willing the vendor is to fix problems than anything else. Also Slurp has a history of ignoring reports and then complaining when the clock runs out and they get called out.
but I think 90 days is pretty short for making a bug public
I think the limit is fairly arbitrary. If the team at Google can find the bug then who's to say others with less "honourable" intent can't? I guess you have to balance any potential risk posed by Google's disclosure with that by Microsoft's inability to close it properly.
In any case the original bug was reported in March 2016: it's only the follow up that's from November. That seems like more than long enough to me.
MS did release a patch for the March bug but, shockingly, they didn't get it right. The November follow up was more an "oh by the way, you didn't fix the problem properly". While I do think it's more on MS for issuing a patch and brushing it off the follow up did come just before the raft of winter holidays that would have left MS short as many folks tend to either leave for the week or lollygag in the office prior to sacrificing a Turkey at the altar of an NFL triple header and then a month later do the same thing in a christmas coma that flows through the new year haze. All of which means that one would expect the December and January patch dates to be lighter than normal or filled out with longer running updates.
Of course with the schedule being set to a fixed day of the month it means that there will be either 13 or 14 weeks for three such successive days which would total 91 or 98 days which puts it beyond Google's self imposed 90 day deadline if it can't get done in the triple patch time frame. Meh, it's two companies trying to throw shade on each other and I feel I'm best off if I avoid them both as much as I can.
Of course with the schedule being set to a fixed day of the month it means that there will be either 13 or 14 weeks for three such
They've been releasing out of cycle patches increasingly often. But it really doesn't matter: if there is injury as a result of this then I can't see any jury sympathising with them. Maybe they just need a massive fine to take these things seriously enough.
The software industry repeatedly manages to worm itself out of strict liability by promising to release updates. But there are many, though obviously no criminal attempt to cover things up, with VW's recent software manipulation, which while settled by the regulators, is still open for civil suits.
Pardon me, is this where I can order one of them Microsoft Continuous Lifecycle London? See, me cousin is interested, like. She's interested and I'd like to give it to 'er as a berfday present. So stay shtum and here's me credit card, like. Start it soon, cause 'er ticker's a bit scratchy. Yeh. She'll be wantin the ticker upgrade program, har! No, I'm not from London, she's from London. Right. Apology accepted. It's why I don't sound like I'm from London. But I can do impressions. Want to hear one? It's from Penzance: "Why you laugh at me? Eeet ees breeleeant for man in open to conveence everybody zat roof need freequent main ten ance."
That is the Graphics Device Interface library for 32 bit applications. You know, responsible for minor things like drawing lines and shapes, painting bitmaps on your screen (actually even a printer is considered a canvas) and rendering text. Basically the 2D stuff.
Whilst it has its quirks, even the modern frameworks will at the end of the day be interacting with it at the bottom of the object rabbit hole. They could abandon it I guess, but that would just break backwards compatibility with all the win32 applications or there, and well win RT never really took off. Btw, on 64 bit machines it really is just a shim to translate calls into the equivalent 64 bit instructions. I can understand why they may be cautious about changes. At low levels, medicines can easily be much worse than illnesses.
You don't mean 32-bit applications, you mean legacy stuff using MFC, including from the bug report Office 2013. GDI has been known for years to have security problems, which is one of the reasons it was supposed to have been thrown out in Vista
Anyway, backwards compatibility should be available through emulation or thunking: the application shouldn't care whether it's talking to the hardware or something that looks like the hardware. It's just another corner that was cut.
No I don't mean legacy stuff using MFC. Of course that uses it, but not all things that use it are MFC. If I look at the processes on this system that have a handle open to gds32, I can see 148 of them, including things like Firefox, Chrome, cmd, devenv (VS 2015), Notepad++, powershell, Process Explorer (ironically), sqlservr, w3wp (IIS worker), and of course the various office applications, updaters, svchosts etc. I literally just created a new otherwise empty WPF application, and even it loads gdi32 when you double click it.
Nitpick, but it's still GDI32 in 64 bit Windows.
For the same reason that the whole Win32 API is still called ... Win32.
The reasons for this are historical. Win32 was more or less a redesign inspired by Win16 rather than a simple "bittiness" extension. It was done on the NT branch, not (what was then) the Win 3.x branch.
Win16 uses a segmented memory model, while Win32 uses a flat memory model. Having the latter work with 64 bit instead was simply a matter of growing the pointers and didn't touch the actual API in any other way, while going from Win16 to Win32 essentially meant rewriting the APIs and applications.
(And sigh, as to rewrites, I'll just give up on trying to kill the myth that MS has ever claimed Win7 or 8 or 10 or 11 or whatever was a complete rewrite...)
Seriously, that's not a surprise. Most people who have tried to use a file saved in .EMF format gave up and went back to saving the file in .WMF format instead because that at least worked. .EMF support was/is so useless that exporting something as .EMF in one Microsoft application and then importing it into another and it would be flipped, missing components or otherwise corrupted. In short, Microsoft don't seem to understand their own format.