Insecurity blues: What I learned from my buggy code
It hasn't been a good month for my code. Samba, the project I'm responsible for, has had to announce several security flaws. Unfortunately some of them were in code I wrote. I always do a large amount of soul-searching whenever that happens. There's nothing worse than finding out something you were responsible for is the cause of many thousands of people having to waste their time rolling out patches. It always makes me wonder if the time has come to give up this programming lark and end my days peacefully in management, messing up other people's code instead of creating my own.
It's very educational however to look at the causes of the flaws, and try and learn what we can from the bugs and also our reactions to them. Samba is an old program. The initial code was originally written 15 years ago. At that time, modern security problems such as integer wrap (where adding two numbers together can end up with a number smaller than both of them, due to the fixed sizes of integers that processors deal with), or heap overflow vulnerabilities (where overwriting unallocated memory on the program heap can allow a clever attacker to seize control of a program) were unheard of. We knew about buffer overruns (where reading more data into a buffer than was originally allocated for it can cause a security breach) and denial of service attacks, but 1992 was a simpler, less hostile time for network software development. Most initial deployments of Samba were on networks isolated from the main Internet, by technically advanced administrators who knew how to download the source code from the Internet.