How not to issue Linux kernel security update notices

March 26, 2011

This is a rant.

First, do not include useful information about how readily exploitable the bugs are. It is very well to tell people what subsystem the bug is in, but that's not enough. If there is a bug in the OSS code, can that be exploited from user level even on machines without any active sound hardware? If there is a bug in an obscure network protocol that the machine isn't using, is it still accessible to a user?

Relatedly, when you write that a bug is potentially exploitable to compromise the system, how strong is the potential? There is a not insignificant difference between 'this is likely exploitable but no one has bothered to write one yet' and 'in theoretical circumstances, with the right tailwind, you might be able to use this'.

This information is almost always available out there on the Internet (and your own security team should be using it to assess the urgency of the update), but feel free to make busy, harried sysadmins around the world redo all of this research. We love that.

Next, when you write your announcement and are describing what it fixes, include all of the security issues fixed since the beginning of time or at least the initial release of this version of your distribution, even if you first fixed them in a prior kernel update that you released months ago. On no account mark these old fixes in any particular way, so that sysadmins can tell which issues are new and which issues they are already not vulnerable to.

(Speaking from personal experience, sysadmins love being driven into alarm by an exploitable security issue that it turns out that they fixed months ago. Especially on a Friday afternoon. No, really!)

To make this more awesome, release a stream of separate kernel updates for specialized versions of your kernel (or different versions of your distribution) and make almost all of the text of the update message exactly the same as your normal message. Sysadmins will readily notice the differences between the following two Subject headers (and know what they mean and which ones matter):

Subject: [USN-1092-1] Linux Kernel vulnerabilities
Subject: [USN-1093-1] Linux Kernel vulnerabilities (Marvell Dove)

And they will certainly not waste their time reading very carefully through your list of fixed bugs trying to find any new important issues that it turns out wouldn't apply to them anyways because they don't use the specialized kernel package and besides, it doesn't even run on their architecture.

(For bonus fun you can still include security bugs that do not at all apply to the architecture that this version of the kernel runs on, like x86 specific bugs for an ARM kernel.)

Finally, be inconsistent in all of this. Force people to pay close attention to things like who wrote this particular kernel update message and guess what it means, in an attempt to pick out some pattern of how they need to read any particular update message.

If you're doing all of this, I'm really not sure why you're bothering to put details into your kernel security update messages in the first place. Just replace the entire body text with 'there is a new kernel security update that may apply to you. Type <appropriate package manager commands> and reboot your machine if prompted to'. The useful information content will be almost the same, you'll save time, and sysadmins will be marginally less annoyed with you because at least you're being straightforwardly useless.

(PS: yes, this is Ubuntu. And it's yet another entry in the 'why Ubuntu is not my favorite Linux distribution' category.)

Written on 26 March 2011.
« Sending email via a SMTP connection considered harmful
Some thinking on proliferating web standards »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Mar 26 01:05:07 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.