Discipline is one answer to the security question

Last week, I noted that integrating application technologies into an operating system without due regard for security — as Microsoft did with Internet Explorer and Windows — was a recipe for trouble. I left off on what some readers may consider to be an uneven note by appearing to take Microsoft off the hook.

Well, I have my reasons. Remember that operating systems and applications don’t simply appear. Someone has to write the code, line by line. A high percentage of that coding is done in the C language and its derivatives. For those who don’t know their history, C has been with us for what in computing terms amounts to eons.

DISCLAIMER: I am not a programmer, by inclination, trade, or training. I am going to grossly simplify or even omit some details in order to tell the story in my allotted space. Deal with it.

Thirty-five years ago, a team at what was then AT&T’s Bell Labs was developing what we now know as Unix. Ken Thompson created the “B” language in response to a need for a programming tool — it seems Fortran wasn’t cutting the mustard.

B had its problems as well; compiled programs ran so slowly that programming in assembly language was worth the headache. B also lacked a “typing” scheme that would handle characters, byte-addressing, and floating-point operations. Dennis Ritchie developed C between 1971 and 1973 to address these shortcomings.

Perhaps a more appropriate name would have been “kudzu,” because since 1973, C has taken over the computing world, with the help of its offspring, C++. An awful lot of applications are written in a C-derived language, as are most modern operating systems.

As languages go, the C family is not terribly difficult to work with — remember, someone who can’t program his way out of a wet paper bag writes this column — and its ubiquity means most programmers and many system administrators are familiar with it.

C and its derivatives are so powerful that it’s easy to write sloppy code that doesn’t manage system resources properly. But with a little discipline when it comes to checking data input and allocating memory, programs written in C-type languages are the next best thing to bulletproof. That’s the key to secure code: discipline.

The problem is that there’s a lot of code floating around — call it legacy or call it below-the-radar — that isn’t clean and secure. Whether it’s a one-off routine or a snippet buried in a code library that’s used by developers around the world, the process of completely fumigating C-based software may well be hopeless but that’s not going to stop people from trying to do so, and thank heaven for those folks.

(Props to Jeff Duntemann, whose recent SD Times column on software monoculture got me thinking at a level I usually ignore.)