Wietse Venema started out as a physicist, but became interested in the security of the programs he wrote to control his physics experiments. He went on to create several well-known network and security tools, including the Security Administrator's Tool for Analyzing Networks (SATAN) and The Coroner's Toolkit with Dan Farmer. He is also the creator of the popular MTA Postfix and TCP Wrapper.
SecurityFocus contributor Federico Biancuzzi chatted up Venema to talk about software security, how to improve the code quality, what solutions we might have to fight spam successfully, the principle of least privilege, and the philosophy behind the design of Postfix. Venema is currently a researcher at IBM's T.J. Watson Research Center.
SecurityFocus: Could you introduce yourself?
Wietse Venema: I had the good fortune to get my hands on the Internet when computer security was slowly becoming a concern, and I was able to make a few contributions with TCP Wrapper, Satan, Postfix, and The Coroner's Toolkit. Two of these, Satan and TCT, were done with Dan Farmer.
My background is physics, not computers. I learned to program defensively when writing the software that controlled my physics experiments. I was motivated to program very carefully, because these experiments ran round the clock for several weeks and I didn't want to live in the lab day and night. Once I acquired this programming skill, it was like riding a bicycle: you never forget how to do it.
When you released SATAN in 1995 it was marked as a controversial program, and even led SGI to fire your co-author Dan Farmer. Do you think the general point of view on security tools is changed since then?
It has certainly changed. Network scanning has become a standard tool, just like firewalls, intrusion detection, antivirus. Nowadays you can be considered negligent for not using these technologies.
In a perfect world, we would not need such tools because all systems would be completely free from errors, but we haven't reached that point yet. Modern Windows and Linux systems are already up to 50 to 100 million lines of code. Even good programmers have an error rate of one in 1000 lines, and with millions of lines of code being written each year, we're creating vulnerabilities faster than they can be eliminated.
There was a time when you were, as you said, "logging every network packet to disk. It's good insurance." Do you think such a public announcement might discourage some attackers nowadays?
Yes, but doing so deters only attackers who want to break into a specific site. Nowadays, most attacks are non-targeted. They don't care what machine they break into, and their packets are being logged all the time by honeypots and other sensors that collect data about attackers and malware. Full packet logging is also done by some network administrators -- with management approval of course -- but this requires a lot of storage resources.
On my own network, the resources are too limited for unselective packet logging. I am less concerned about non-targeted attacks anyway, and rely on a combination of measures to keep the place safe, including logging, least privilege, one-time passwords, network access control, and more.
Do you have a favorite method to reduce the number of vulnerabilities in software?
The earlier a defect is found, the better. I rely primarily on careful design and review, and secondarily on source code and run-time analysis tools. The best that program analysis tools can do in my experience is to transform programmers into better programmers, meaning you still have one error per 1000 lines of code.
I've mentioned in the past that programming should be a million times more difficult, so that fewer people would be able to write code. This is, however, not the direction where things are evolving. Instead, more and more people, with less and less experience, will be programming computer systems, and their programs will of course be connected to the Internet.
The challenge is to provide environments that allow non-experts to program computer systems without introducing gaping holes. Today, we're better at the first part than the second. For example, writing applications with PHP is comparatively easy, but it's harder to write PHP code without gaping security holes. I have done some work to improve this situation, but I don't expect miracles.