Non-M$ Patch Management

First off, very few people in the unix world call it patch management. It is usually called package management. There is a difference between the terms patch and package management. Package management is a subset of patch management that specifically focuses on deployment, patch notification, handling dependencies and the like. Patch management usually includes broader activities like network inventorys and vulnerability scanning as well as package management. Thus in the context of this discussion we are actually talking about package management tools.

The open-source nature of unix made it obvious from the start that there were going to be lots of patches to things. The nature of collaboration meant that most changes were initially distributed as patches. And when I say patches I mean diffs, the kind of things that Larry Wall's patch utility takes as input, and he wrote that in 1985. Thus, patches were inherent to applications, not a special problem that manifested itself later. Additionaly, the unix philosophy involves making small functionally targeted applications "Do one thing and do it well", which means lots of bits got bundled together to make an application. This meant that the average Operating System would need tons of applications. With this in mind, people started creating tools to help manage lots of these packages of applications and their constant updates.

If we zoom forward to present day we see that this paid off. Debian has apt, FreeBSD has ports, RedHat has RPM, Gentoo has portage etc. All the 'derivatives' like OpenBSD and Ubuntu have them too. These tools all allow you to manage keeping your system up to date, and they do it well. I could replicate Microsoft's current WSUS infrastructure several years ago by setting up a central repository which usually just requires some default networking protocol like http or ftp, and pointing the 'agents' installed by default on every one of these distributions for the last couple of years at it. If you want to start getting fancy, like say adding internal organisational signatures, well slap your own GPG signature on the patches and use scp with a for loop in a bash script to update the GPG signature on every agent in your organisation. I don't need to pay Shavlik $1million for that. All of the other difficult stuff like dependency checking, binary diffs and efficient deployment is done already and doesn't require any modification of the base system.

In contract, Microsoft only realised that security patches are a special case later on and has rushed to try and provide the same level of efficiency as the unix world. Also, Microsoft applications are more often bulky behemoths that try and do everything. They haven't been subject to an evolution which made available a high quality set of building blocks. Even where applications with a lot of functionality are relevant (like OpenOffice or Evolution) they still build nicely on other libraries and toolkits, preventing the kind of situation we saw in Microsoft GDI+ JPEG vulnerability where nearly every application bundled its own version of gdiplus.dll. Microsoft's avisory on Microsoft products only, mentioned over 50 products and included links to 30 seperate updates. Not to mention the seperate patches required for third party applications. Even worse, you needed a third party tool to try and figure out which applications included the vulnerable library, because Microsoft's software inventory just records installed software, not dependencies. An equivalent query on my Debian machine would take a few seconds by running apt-cache showpkg <pkgname> and not requiring any third-part tools, because there is no such thing, the entire OS is made of of third-part tools.

But the technical aspects are the easy bits. They take up precious little space (unfortunately) in my MSc thesis on this subject. The hard parts are the processes around how all of this should work. There is a whole bunch an organisation can do, you can read about that when I finish my thesis, but that is common to all vendors. The difference is in what the vendor does. Now try and imagine this world. A critical vulnerability is announced in the latest version of Adobe Acrobat reader, and since everyone has that installed you want to patch it quickly. The problem is Adobe only released the patch for the latest version and your organisation's standard image has the previous version installed. So Microsoft kindly takes the fix from the latest version and backports it to the older versions and within a couple of hours is distributing it for 36 architectures. Now your organisation only has to go through minimal regression testing on the patch because there is no new functionality, only a small security fix. Better still, because it was distributed by the vendor you can use the standard deployment tools instead of figuring out how to fit Adobe's own deployment tool behind the corporate firewall. Now imagine this was true, not just for Acrobat Reader, but for *every* patch released by a *huge* number of vendors.

Well, that would be nice, but would literally be impossible in a Microsoft world. The code sharing agreements, the extra work required by Microsoft techies it would be a nightmare. But not in our happy unix open source world. This is exactly what happens in the case of FreeBSD and Debian (and possibly others, I am just not that familiar with them). Better still, this is free! You don't have to pay Patchlink a newborn every month, now you can put that company daycare centre to good use. This isn't only available to big corporates who employ Linus Torvals himself, but is available to any end user. Ubuntu linux for example follows the exact same model. Now you can provide the kind of patch management quality many Microsoft based corporates are still trying to figure out who they can pay to get to your mother and grandad.

The thing that scares me is that the average Windows administrator seems to be absolutely clueless about any of this. Microsoft has managed to sell them a world where nobody else innovates, or if they do they innovate for hairy geeks and not serious business people. So instead of any serious debate about the various methods of patching we are presented with, you get people posting news stories like this.

Aaah, rants do provide for a nice break from academic writing.