2009-11-02
Are security bugs always code bugs?
I'll be generous and ask the slightly broader question: are security 'bugs' always caused by code bugs? I believe that the answer clearly has to be no; while there's a decent argument that failure to properly escape input is a code bug, I think it stretches the term beyond all non-circular meaning to say that using the wrong cryptography is a code bug.
I think that there are at least the following sources of security bugs:
- outright code bugs, the traditional off by one errors and the like.
- undesigned or unimplemented features (failure to properly escape input,
bad input validation, missing security checks, etc).
- design mistakes, such as using the wrong cryptography.
- unforeseen interactions between existing features (as seen in quite a lot of Linux kernel security bugs, which often have the abstract form 'if you use X in a clever way, you can bypass apparently unrelated thing Y').
Now I go back to my argument about why security bugs aren't bugs.
From a suitable height, all four of these sources are defects in the code. If you consider 'bug' to be the same as 'defect in the code', then all four are bugs, but I think that this is stretching the term too far; by that definition, inadequate performance is a bug, along with pretty much anything you don't like about the code. In practice, programmers have a pragmatic definition of bugs, based on the general practices we follow to get rid of them, and at least two out of the four sources of security bugs are not 'bugs' under those practices; they are qualitatively different from even very hard code bugs.
(They are mistakes, they are defects, but they are not bugs; the program is working exactly as designed and the design is not bad or incomplete, it is just that it has subtle flaws.)
XHTML vs HTML5
Every so often these days, an XHTML fanatic goes off on a rant about how HTML5 is all a horrible mistake and a nightmare (this one is about typical for the breed, and is what set me off in turn). These people are committing a simple mistake: they misunderstand the nature of the world.
It's really simple; XHTML and HTML5 are entirely different sorts of standards. XHTML is an invented standard and has failed because it had very high costs of implementation and use and provided almost no functional difference from other standards (both formal and de facto) in a crowded and mature field (that field being web pages). This is pretty much what you'd expect.
(Some people will protest most strongly that XHTML has not failed. To them, I note that something like 70% of the web browsers currently in use can't display XHTML by default, even if content authors sometimes get fooled about it.)
By contrast, HTML5 is mostly taking a documentation and coordination approach; this makes it much less risky and much more likely to succeed. Since it is taking these approaches, it is in no position to throw away backwards compatibility with HTML4 and do things like venture into the grand world of completely well-formed XML.
(Never mind that the grand world of completely well-formed XML is not realistic.)
Complaining about HTML5 not inventing things is missing the point (and misunderstanding the world). It's not that sort of standard, and it's not that sort of standard precisely because invention standards have failed in the browser; manifestly, you cannot get browser vendors to pay much attention to them (especially the 70% gorilla of Microsoft IE). The people behind HTML5 learned from the failure of XHTML, even if the XHTML fanatics have not, and to be blunt, the result is that HTML5 might just get implemented in a useful way.
(See also Mark Pilgrim, where you can find out how to use HTML5 today on common browsers.)