What happens when a vendor doesn’t patch its software?

Microsoft engineers won’t be happy this month, thanks to the community-minded actions of a Github user named Zeffy. Not content with the way that Redmond was updating its software, he decided to patch Microsoft’s patch.

Zeffy is irritated with Microsoft’s decision to stop updating Windows 7 and 8.1 on newer CPUs. The company, which worked hard to push users to upgrade to Windows 10, announced in January last year that it would not update versions of these older operating systems running on seventh-generation processors (that’s Kaby Lake silicon from Intel, and Bristol Ridge silicon from AMD). A select set of products using sixth-generation Skylake processors would continue to get support until the middle of this year, it said.

On April’s patch Tuesday, the policy finally took effect. Microsoft’s update messages told users of older operating systems using seventh-gen chips that their combinations of Windows version and CPU were not supported. Windows 7 and 8.1 users running Intel seventh-generation Core processors, along with AMD “Bristol Ridge/Ryzen/Zen,” and Qualcomm 8996 chips are being locked out of updates, according to Bleeping Computer.

“A giant middle finger”

In the Readme.md file on his Github repo, Zeffy calls this “a giant middle finger to anyone who dare not ‘upgrade’ to the steaming pile of garbage known as Windows 10”.

He took matters into his own hands, expanding the Microsoft update file so that he could see all the update files it contained. Then, he excluded all the binaries that were related to Windows Update, leaving him with 14 files. He compared those with the ones already on his system, and found one file containing two functions: IsDeviceServiceable and IsCPUSupported. He patched the file to bypass those functions, preventing Windows Update from checking to see whether it liked the host CPU or not.

This isn’t the first time that one person has patched another’s software. Naked Security has already written about Operation Rosehub, a volunteer effort by 50 engineers patching open source projects that used a flawed version of the Apache Common Collections library. Many projects used this code, including WebLogic, WebSphere, JBoss, and Jenkins. No one came to patch many open-source projects relying on the Apache library, so Google stepped up.

Another example of guerrilla patching is 0patch, a project from Slovenian consulting firm Acros Security. This approach uses what the firm calls “micro-patching“, in which the binary isn’t modified at all. Instead, the patches are in-memory changes, typically shorter than a tweet, that block malware trying to exploit a particular vulnerability.

The idea is to quickly patch binaries against specific exploits before the vendor can. In many cases, it can be easier to install a targeted in-memory patch than to try and test a bundle of different patches that will affect binaries directly, explained Acros co-founder Mitja Kolsek.

Working around inadequate patching policies

These different approaches to guerrilla patching highlight existing problems with software updates.

0patch has appeal because it’s an easier way for enterprise admins to protect their software without relying on binary patches that may break the systems. The project has now issued more than 300 patches for various products, many of which were not zero-days.

Like 0patch, Operation Rosehub has appeal because in some cases, vendors simply don’t patch vulnerabilities quickly enough. In Google’s case, the problem lay with open-source projects for which no single person has responsibility. This highlights one of the key problems with open source: many eyes may eventually start a problem, but no one may step up to fix it.

Zeffy’s case highlights something different altogether: selective patching, designed to support a vendor’s own agenda at the expense of its users. Microsoft’s decision to stop updating Windows 7 and 8.1 on current-generation processors furthers its own agenda, which has always been to force as many Windows users to upgrade to Windows 10 as possible.

Microsoft explains this by arguing that developers would have to work too hard to support “Windows 7’s expectations” when running on newer silicon. Nevertheless, it in effect holds users of older versions to ransom, which is what irked Zeffy so much.

This is unfortunate, because fighting the security battle is already hard enough. We should be able to rely on software vendors to support their products on all platforms until their official end of life. Microsoft has vowed to offer extended support for Windows 7 – which includes security updates at no extra charge – until January 2020. Windows 8 gets extended support until January 2023.

If patches themselves become a battleground, and users who don’t want to upgrade their OS must begin hunting around for tools that let them patch vendors’s own patches, then system protection – already a complicated and uncertain process – becomes even more daunting for that vast majority of users that simply wants to feel safe when using their operating system. Zeffy’s irascible fix might not be the last.