Welcome to Volume 5, Issue 2 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. Our newsletter, Insight, is our way of sharing clue. We promise to provide something useful each issue. If we don't, flame me. If you like the issue, let us know!
Enjoy, and be safe,
Dave
I've spent a fair amount of my recent time considering how little we've accomplished in the fields of operating system and Internet security. Stephen Kent and I participated in a panel entitled "The Sad and Increasingly Deplorable State of Internet Security" at the Next Generation Networks conference in October 2002, and we'll be publishing a column in Business Communications Review next month on this same topic.
Turns out that the number of folks now ranting about the problem is rather large. Today's column is one such rant, by Mike Bacarella. Mike takes an even harsher stance on the issue of "shoddy software" than Stephen and I have.
Happy reading...
Considering that most good programmers are bad at writing secure code, bad programmers with important project roles are a security incident waiting to happen. Simply lecturing programmers to check their memcpy() calls isn't enough. Bad programming should carry a stigma, and bad programmers should be publicly shamed.
Software development practices are getting worse. The operating system and application vulnerabilities that slip by shoddy code review and shoddier quality assurance programs are being unleashed on large populations of defenseless users. Consider email viruses; even by the low standards practiced today, virus source code is pathetic, clearly written by aimless, unprofessional oafs. But viruses still wreak havoc on naive PC users on a global scale because professional programmers aren't making the effort to protect their programs against attacks. And let's be honest: to date, we've been pretty lucky. What happens when these viruses are no longer benign, but are instead written by someone with a mission (doomsday cultist, rogue government, or cyber-terrorist) or a motive (a disgruntled, skilled programmer or hired gun).
As IT professionals, we should encourage our colleagues, particularly those responsible for software development, to meet a higher standard. Follow the guidelines listed below, and encourage your peers and software developers to do so as well. Enjoy!
If you do not subscribe to BUGTRAQ (subscribe, FAQ) and the relevant announcement lists for the products you use, you are part of the problem. BUGTRAQ will send you between five and twenty-five emails a day on a variety of topics across the security spectrum, including vulnerabilities discovered, successful exploits, patch and hot fix announcements. The fact that BUGTRAQ and similar lists post vulnerabilities so frequently is a sad indictment of the state of the art in the industry today. You never want the products and services you develop and use to be discussed on this list.
As a software consumer, don't pick products that are bloated and hopelessly complicated to use in your solutions. Consider Oracle, a company that proclaimed it's Oracle 9i Enterprise Database "Unbreakable", and still insists the claim is true, even after one individual found nine serious security vulnerabilities a week later (see http://slashdot.org/developers/02/01/16/1928237.shtml and http://online.securityfocus.com/news/309).
Have you ever downloaded Oracle 9i Enterprise Database? It's a 1.2GB compressed archive download. How many lines of source, man-years of development, and programmers does this effort represent? Is there a single human being alive today (or still with the company) that understands the Oracle code base in its entirety? The worst thing you can do when designing for security is to make your system complicated, because complexity defies understanding. When a developer, or team of developers, does not thoroughly understand software source, he cannot be absolutely certain change will not introduce logic flaws with security consequences.
The message to send your vendors is clear: Eliminate the bloat.
When someone asks "security", don't assume "cryptography" is the answer. But this knee-jerk reaction is amazingly common, even in the circles that should know better. Example: when asked about the failing security of the BIND DNS, a prominent DNS/IP infrastructure software company noted that BINDv9 now supports the full DNSSEC standard. Unfortunately, the interviewer was asking about the recent spat of BIND buffer overflow vulnerabilities. There's more to security than cryptography. In fact, cryptography, in the form of increasingly popular VPN "tunnel" technology, can compound the security problems network operators face today. When flaws in application and OS software give attackers administrative privileges ("root"), encrypted tunnels often hamper incident response and forensic analysis because they encrypt the attack itself!
Used properly, firewalls really do add a significant barrier in the fight against evil. Firewalls, however, promote a false sense of security. Too often, however, organizations are convinced that systems protected by firewalls are secure, so are lax in securing operating systems and applications residing on "protected systems". Did your firewall stop the Melissa virus, or Code Red, or Nimda? All of these attacks represent total system compromises, and they bypassed firewalls entirely. This is not the fault of the firewall: it wasn't designed to prevent these attacks. It's faulty logic and marketing over-hype, leading to poor security implementation. Design security from the application and operating system first, and then add layers or additional barriers against attack. Firewalls are a complementary technology and not a substitute for application and OS security.
In my opinion, if you chose Windows, you should give up now. Windows is a massive, complex, and closed source. Because it is so common, it has become a very highly targeted piece of software. It's notoriously bad at telling you what's going on. Eliminating Windows won't make you invulnerable, but keeping a Windows system goes a long way toward putting you at risk. Even insurance companies are catching on. Hacker insurance premiums are higher if you run Windows.
Hope lies in open source software. By their definition, open source systems encourage public review and comment, broaden the talent pool involved in review, facilitate understanding, and foster customization. While open source software is also rife with security problems, your chances of securing open source are better because you are using components that have been massively peer reviewed.
If you look at your favorite OS and cannot understand every component running on it, and replace that component if need be, you are operating with your hands tied. Systems that can be fitted to naturally solve a problem are an asset, and proprietary software is a liability.
Don't take on a liability just because it's good for some software vendor.
Bad developers are content to build a custom system using proprietary components that by their economic nature discourage understanding, control and cooperation. Bad developers are sometimes bad because of things outside of their control, but I do not believe that is an excuse. I hold the developers responsible, and they should be ashamed. Once they start caring about their work they'll stop taking directions from managers who direct them to do stupid things.
It should be a crime to teach most people C/C++. The problem isn't so much with the language, simply that it's the wrong language to put in the hands of the entire programming community proper.
Based on the quality of software we see today, programmers or their employers do not take their work seriously; more precisely, they don't invest the time to understand programming language constructs, data structures, and operating system calls thoroughly enough to appreciate the implications of each line of source they write. Programming apathy of this sort is bad, but coupling it with C/C++ is a dangerous security liability. If the task doesn't merit expert programmers, at least do the world a favor and take C/C++ out of the hands of the programmers you do assign.
Commonly, serious security vulnerabilities as well as most software bugs are due to pointer manipulation errors in C/C++. Try Python, or Ruby, or even Java. These languages are safer because they don't allow direct pointer modification and perform runtime bounds checking. These higher- level languages are also more expressive, which helps lead to faster development time and smaller source code.
As always, any discussion of C/C++ versus a higher-level language comes down to an argument of runtime performance. This is a red herring. If you profile most applications, you find that a majority of their time is spent doing absolutely nothing: waiting for a disk operation to complete, a response packet to return over the network, or a user to provide input. When you can profile your application and find that a majority of time is wasted in your own code, then you have a case to say that you need more speed. Fortunately, almost every high level language provides you with some method of implementing these hot spots in C or C++!
The classic argument against using assembly language is that you can write your code faster in C/C++, and if there's a bottleneck, it can be rewritten in assembly. Today's argument should be to start with a high level language, and if you encounter a bottleneck, rewrite it in C/C++.
Good developers use high-level languages.
Recent computing trends have heavily targeted at pushing enormously complex web middleware. Vendors eat this stuff up because it's a new market for them to break into with lots of hooks to snag users with other premium services. Many developers justify the use middleware by saying that they need some cute feature that this middleware offers. Of course, what they don't realize is that there may be hundreds of other unnecessary features packaged into this middleware. (Refer back to the earlier, "bloated software", rant.)
Yes, conventional wisdom says ``DON'T REINVENT THE WHEEL''. In the case of software development, however, conventional wisdom is not invalid, just over-stressed. Yes, it generally pays to use someone else's code instead of writing the exact routine yet again. Fortunately, this has already been done for you. It's called an Operating System, and someone has further refined that interface by developing an applications library for it. Third party code can be a great boon, but reliance on an entire layer of it pushes the envelope too far. The market seems determined to heap more and more layers of obfuscation between the user and the data. Plenty of market forces are driving this blitz, but the technical ramifications are very clear: these come with serious, un-addressed security hazards. Imagine what we're going to find in all of these "web services" being pushed by vendors as the next standard middleware platform. They're promising to do more, with more complexity, interactivity, and by what we have seen thus far, even less attention paid to security than applications and OS development.
Be smart, keep the middleware to a minimum, and avoid third party code whenever possible. The wheel isn't reinvented often enough.
Even if you believe your software will never be ported to another system, write it as if it might be. Portable systems are commonly well-designed systems, because they encourage developers to very clearly modularize their code. Well-designed systems are easier to maintain, understand, and consequently more secure.
Bad developers believe creating abstraction layers for portability decreases performance. Bad developers don't know that performance comes from design, not from implementation hacks.
For the longest time, the whois utility would crash if you used the -h option but left out the hostname of the whois server; calling it as simply whois -h. Such a popular utility, one that has existed for so many years and used by all kinds of users falls victim to the most classic vulnerability of all: failing to check command line arguments.
No Big Deal? The whois utility doesn't run with elevated user privileges. The authors of that utility likely said the same thing. The end result is that still today, one can find domain availability lookup sites that fail with a server error when -h is entered without a domain name. What would have happened if this hole were exploitable?
It's amazing how often one time quick hacks suddenly evolve or become embedded into systems that are ultimately used by thousands of users. You've probably experienced it firsthand. There's no reason to leave software with holes in it, because some day someone else may come along and work it into something life threatening.
Sweat the details. Be disciplined in how you develop code. Insist that the folks who sell software to you become more disciplined as well.
It's discouraging to see that most program developments are conducted poorly. Technology is being absorbing into more aspects of our lives than ever, and it is our responsibility to make sure that it's safe and secure. This is not a rant about making bulletproof systems. No system is or will ever be invincible. But a few simple adjustments can go a very long way.
Security is not the ideal investment, but it shouldn't be treated as a bottomless money sink. Many of the benefits of following security practices also have other cost savings. Using safer higher-level languages speeds development time. Better software design facilitates both portability and performance.
We can do better, but we must begin by demanding better.
Michael Bacarella resides in New York City and pursues a technology idealism modus operandi through a business fiction called Netgraft Corporation. He is convinced that he can offer sophisticated technical solutions on-par with what the big two and three letter companies offer, but at a fraction of the price. Send email for Michael to mbac [at] netgraft [dot] com.