Writing Secure Code
Rodney Jao has an article in Inq7.net about “Writing Secure Code” which probably should be renamed to “Microsoft Helps Developers Write Secure Code”. Anyway in the article, he describes the current scenario were developers are faced with writing code quickly at the expense of writing it securely. He also describes Microsoft’s solution to help write secure code in MS Visual Studio.
One of the challenges in writing code is making it secure. It takes skill, discipline and some patience. To some developers, it is not even a priority to write secure code due the amount of work required and just present patches or upgrades in the future as problems are detected. Good thing, Microsoft’s latest developer product, Visual Studio 2005, introduces tools (buffer overflow detection and flags to run as low privilege users) to help developers write secure code and makes writing secure code easier and faster.
As a basic principle, write secure code is a matter of checking all the cruft that comes into your program and all the cruft that goes out of your program. Majority of software security vulnerabilities can be traced to bad input or output (such as buffer overflows, injections and others). There are many schools of thought when writing secure code. What Rodney mentions is only one of them. The schools of thought roughly fall under:
- School of Thought 1. It’s the Developer’s Responsibility So Let the Developer Fix the Problem. This is a common school of thought amongst some of the open source movement’s mainstream developers. This assumes that the developers are competent enough to actually know there is a problem. In most of the major free software projects, the pecking order is sometimes defined by coding prowess and thus this school of thought previals in those circles.
- School of Thought 2. It’s the Development Tools‘ Responsibility So Let the Development Tool Maker Fix the Problem. This is slowly emerging as the dominant school of thought these days. The assumption here is that most developer’s can not tell if there is a problem. Therefore, it is the responsbility of the tools during development time to detect these. However, the actually environment upon execution will definitely contain other potential issues that will not be clear during build time.
- School of Thought 3. It’s the Execution Environment’s Responsibility So Let Them Fix It. The execution environment is either the operating system, virtual machine, application server and many others (or a combination thereof). For example, Java tries to solve some security issues by managing all memory by using the virtual machine concept. This way Java, the execution environment, prevents some of these memory-related security problems. PHP, in later versions, also does the same by always checking $_POST or $_GET entries. This potentially eliminates a good number of potential injection issues. An operating system can also help by restricting the execution of certain areas of code. This is currently implemented in Linux and prevents illegally inserted code to executed.
Rodney’s article focuses on the Development Tools’ Responsbility (School of Thought 2). The solution is in the development environment such as Microsoft Visual Studio. Not mentioned in the article is that security in the dotNET framework is also checked in the Virtual Machine (School of Thought 3). But, this is certainly not enough. Even with the best tools and other preventive measures, it is still important to ensure that developers think security from the start.
PS. I used to give a lecture on secure programming as part of CS 159.3 (Special Topics in Systems: Systems Programming). The lecture is based on a really good material by David Wheeler. Although it focuses on Linux and Unix, the general concepts can be applied to MS Windows. I recommend that programming instructors devote a lecture for this in their classes.
