Why system administrators hate security researchers every so often

October 15, 2014

So in the wake of the Bash vulnerability I was reading this Errata Security entry on Bash's code (via due to an @0xabad1dea retweet) and I came across this:

So now that we know what's wrong, how do we fix it? The answer is to clean up the technical debt, to go through the code and make systematic changes to bring it up to 2014 standards.

This will fix a lot of bugs, but it will break existing shell-scripts that depend upon those bugs. That's not a problem -- that's what upping the major version number is for. [...]

I cannot put this gently, so here it goes: FAIL.

The likely effect of any significant amount of observable Bash behavior changes (for behavior that is not itself a security bug) will be to leave security people feeling smug and the problem completely unsolved. Sure, the resulting Bash will be more secure. A powered off computer in a vault is more secure too. What it is not is useful, and the exact same thing is true of cavalierly breaking things in the name of security.

Bash's current behavior is relied on by a great many scripts written by a great many people. If you change any significant observable part of that behavior, so that scripts start breaking, you have broken the overall system that Bash is a part of. Your change is not useful. It doesn't matter if you change Bash's version number because changing the version number does nothing to magically fix those broken scripts.

Fortunately (for sysadmins), the Bash maintainers are extremely unlikely to take changes that will cause significant breakage in scripts. Even if the Bash maintainers take them, many distribution maintainers will not take them. In fact the distributions who are most likely to not take the fixes are the distributions that most need them, ie the distributions that have Bash as /bin/sh and thus where the breakage will cause the most pain (and Bashisms in such scripts are not necessarily bugs). Hence such a version of Bash, if one is ever developed by someone, is highly likely to leave security researchers feeling smug about having fixed the problem even if people are too obstinate to pick up their fix and to leave systems no more secure than before.

But then, this is no surprise. Security researchers have been ignoring the human side of their nominal field for a long time.

(As always, social problems are the real problems. If your proposed technical solution to a security issue is not feasible in practice, you have not actually fixed the problem. As a corollary, calling for such fixes is much the same as hoping magical elves will fix the problem.)


Comments on this page:

By Ewen McNeill at 2014-10-15 01:34:51:

As an observation (mostly by way of agreement) this is basically the "We'll fix everything we've been meaning to fix for ages in Python3" situation. Yes, you can build a "some changes to your code required" new version, and bump the major version number to let everyone know (better than not doing so!), but... adoption will be slower than you hoped. Even if you take this warning into account.

Personally I'm glad that Ubuntu/Debian went through the process of removing their bashisms, and made /bin/sh something else (dash). But it was definitely a non-trivial amount of work. Debian took quite a few years longer than Ubuntu to get there. (And inevitably the work required gets larger the longer /bin/sh has been bash and things have "just worked" -- and not been ported anywhere else.)

Ewen

By Pete at 2014-10-15 10:57:49:

How do you square this stance with the embrace of SystemD? Took The Hypocritic Oath?

By cks at 2014-10-15 16:44:50:

My experience with systemd has actually been that it's very backwards compatible in my environments. I have two Fedora machines that I upgraded from the pre-systemd era to the systemd era and neither had any issues (and they did have customized boot stuff and so on). My migration to using systemd directly has been mostly because I wanted to and not very much because I had to.

Written on 15 October 2014.
« Bashisms in #!/bin/sh scripts are not necessarily bugs
Don't use dd as a quick version of disk mirroring »

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

Last modified: Wed Oct 15 01:12:55 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.