Mateusz Jerczyk of Google Project Zero calls out Microsoft for implementing some security patches in Windows 10, but not Windows 7 and 8.1.
The aim of this blog post was to illustrate that security-relevant differences in concurrently supported branches of a single product may be used by malicious actors to pinpoint significant weaknesses or just regular bugs in the more dated versions of said software. Not only does it leave some customers exposed to attacks, but it also visibly reveals what the attack vectors are, which works directly against user security. This is especially true for bug classes with obvious fixes, such as kernel memory disclosure and the added memset calls. The “binary diffing” process discussed in this post was in fact pseudocode-level diffing that didn’t require much low-level expertise or knowledge of the operating system internals. It could have been easily used by non-advanced attackers to identify the three mentioned vulnerabilities (CVE-2017-8680, CVE-2017-8684, CVE-2017-8685) with very little effort. We hope that these were some of the very few instances of such “low hanging fruit” being accessible to researchers through diffing, and we encourage software vendors to make sure of it by applying security improvements consistently across all supported versions of their software.
On the one hand, he’s correct. Microsoft is leaving users of Windows 7/8.1 exposed to potential security risks by not patching those OSes, and they should be “encourage[d] . . .to make sure of it by applying security improvements across all supported versions of their software.”
On the other hand, it’s a bit rich of Google to be lecturing Microsoft for not patching older OSes. Take Windows 7. That OS was released on July 22, 2009 and mainstream support for it ended on January 13, 2015. Microsoft is committed to providing extended support, however, through January 14, 2020.
So Google is unhappy that 8 years after releasing Windows 7 that Microsoft failed to implement a security patch for a known vulnerability. Fair enough.
On July 9, 2012, Google released Android 4.1 Jelly Bean. A major vulnerability in Android 4.1 was discovered in early 2015. In January 2015, Google publicly announced that it would not develop a security patch for this bug for Android 4.1. It did graciously allow that if someone else wanted to develop a security patch for the 2-and-a-half year old OS that it might be willing to incorporate those into Android 4.1.
Unlike Microsoft, Google can’t even be bothered to publish formal end-of-life dates for its software. The only policy it has in place is related to its own Nexus and Pixel devices, and states that such devices will receive “security patches for at least 3 years from when the device first became available on the Google Store, or at least 18 months from when the Google Store last sold the device.”
Compared to Google, Microsoft is a paragon of virtue when it comes to supporting its customers on aging OSes.