A different measure of buggyness
It is extremely difficult to create trustworthy software.
The difficulty and slow production leads to much higher price.
That means that most software produced will be fairly insecure,
because security is a fairly low priority for most producers
and consumers of technology.
As an example of the difficulty,
the NSA asked Praxis High Integrity Systems
to develop part of Tokeneer, a secure system.
The key statistics were:
9939 lines of code were produced, in
260 days of work, for a production rate of
38 lines of code per day, and with
1 defect discovered since delivery.
A lot of the difficulty goes back to the fundamental differences in secure design. Ross Anderson's book "Security Engineering: A Guide to Building Dependable Distributed Systems" is an excellent explanation of the issues of designing trustworthy systems.
I think a lot of the problem is philosophical. A typical system design is based on what features you want to include. The most important question for most designers is of the form, "Does this do what I want it to?" Unfortunately, they overlook the important question "Does this refuse to do what I want it to not do?" Could there be some way to get the system to do something helpful to the attacker and overlooked by the designer?
Put another way: A design should specify that the system should have only a narrowly defined set of functions: precisely that and no more. That means that the design analysis and implementation testing need to address failure modes and the handling of unexpected input.
This is an area where Microsoft seems to do an especially poor job. Microsoft products tend to be very good as long as you do exactly what they expected you to do with them. The problem is when error or misunderstanding or bad luck or malice presents inputs or situations not of interest to and therefore not considered by the designers.
David Wheeler's Secure Programming for Linux and Unix HOWTO is a great reference for security software development. Much of it applies to programming in general. My biggest complaint is that its title gives the false impression of a narrow scope. It's nicely written, both broad and detailed, and a free download. Many other things at his web site are very helpful, see: http://www.dwheeler.com/
Cross-Site Scripting (XSS) and similar attacks have become the largest category of threat, surpassing buffer overflow attacks. Wikipedia and others have good descriptions of these programming errors and pointers to further resources:
A group of industry experts has defined a list of the 25 most dangerous programming errors, see the lists at the SANS Institute and MITRE:
Also see the work of SAFECode, the Software Assurance Forum for Excellence in Code. From their mission statement, "SAFECode is dedicated to increasing trust in information and communications technology products and services through the advancement of proven software assurance methods."
Robert Seacord's Secure Coding in C and C++ addresses a vital topic, as most applications and pretty much all operating systems are written in those languages. C and C++ are used to create pretty much everything, but at the same time they are rather insecure languages. This goes back to the original design philosophy — Kernighan and Ritchie made it the programmer's job to very carefully use arrays. "Nevertheless, C retains the basic philosophy that programmers know what they are doing; it only requires that they state their intentions explicitly."
Bjarne Stroustrup has said, "C makes it easy to shoot yourself in the foot." C permits undesirable operations, and many simple and common programming errors are not detected by the compiler and may remain subtle at runtime.
The following are from David Wheeler's paper, and they are all free software except as noted.
See the web security page for this list.
PyChecker checks for common Python bugs: http://pychecker.sourceforge.net/
A different measure of buggyness
Microsoft's ActiveX is fundamentally insecure and you should disable it. That is, if you are so daring as to use Explorer. Really you should be using any other browser.
Some people complain that their organization has foolishly built business practices around pages that only function using ActiveX. What's next, requiring all personnel to smoke at least one pack of cigarettes each day?
Some interesting comments about the leaked Windows source code: http://www.kuro5hin.org/story/2004/2/15/71552/7795
The Metasploit Project is an open-source code library for developing and running exploits: http://www.metasploit.com/
|
|
|
|||||||||
|
|||||||||
|
| © Bob Cromwell Sep 2010. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache. Root password available here, privacy policy here. |
