Software Security Tools

How to develop software that is more secure

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
2 defects 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:

• Wikipedia on Cross-Site Scripting (XSS)
• Whitehat Security's XSS paper
• Wikipedia on SQL Injection
• Wikipedia on Code Injection
• Wikipedia on Format String Attacks
• Wikipedia on Buffer Overflow Attacks in general
  • Wikipedia on Stack Overflow
  • Wikipedia on Heap Overflow
• Aleph One's "Smashing the Stack for Fun and Profit"
• A description and detailed example of Buffer Overflow
• And many more: http://en.wikipedia.org/wiki/Category:Security_exploits

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:

• http://www.sans.org/top25errors/
• http://cwe.mitre.org/top25/

SAFECode, the Software Assurance Forum for Excellence in Code

SAFECode, the Software Assurance Forum for Excellence in Code, has this mission statement: "SAFECode is dedicated to increasing trust in information and communications technology products and services through the advancement of proven software assurance methods."

Safecode has released a very good document, Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today. To summarize it:

• Secure Design Principles
  • Design using threat modeling, also known as threat analysis or risk analysis..
  • Use Least Privilege.
  • Implement sandboxing.
• Secure Coding Practices
  • Minimize use of unsafe string and buffer functions.
  • Validate input and output to mitigate common vulnerabilities.
  • Use robust integer operations for dynamic memory allocations and array offsets.
  • Use anti-Cross Site Scripting (anti-XSS) libraries.
  • Use canonical data formats.
  • Avoid string concatination for dynamic SQL statements.
  • Eliminate weak cryptography.
  • Use logging and tracing.
• Testing Recommendations
  • Determine attack surface.
  • Use appropriate testing tools.
  • Perform fuzz / robustness testing.
  • Perform penetration testing.
• Technology recommendations
  • Use a current compiler toolset.
  • Use static analysis tools.

C/C++ Security

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.

• Flawfinder scans C/C++ code for common problems.
• RATS (Rough Auditing Tool for Security) scans C/C++, Perl, PHP, and Python code for common problems.
• Splint is Secure Programming Lint. It scans C/C++ somewhat as lint does.
• cqual looks for C bugs and applies stricter typing.
• Valgrind "supervises" the execution of a program, monitoring all memory management and access. See the overall Valgrind project and the specific Valgrind tool.
• ITS4 scans C/C++ code. It's not strictly open-source.
• Also see the Linux section of the OS-specific page for some modifications to the standard C library to mitigate problems caused by bad code.

PHP Security

See the web security page for this list.

Python Security

PyChecker checks for common Python bugs.

RATS (Rough Auditing Tool for Security) scans C/C++, Perl, PHP, and Python code for common problems.

Java Security

• Sun's Java security docs.
• Several Java security papers by L. Gong.
• "Blocking Java Applets at the Firewall" is a good technical paper.
• Details on Java exploits, language issues, and how to write better Java.

ActiveX Must Be Disabled

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?

Windows Source Code

The Kuro5hin site had some interesting comments about the leaked Windows source code.

Writing Your Own Exploit Code

The Metasploit Project is an open-source code library for developing and running exploits.

Back to the main Security Page

Home Unix/Linux Networking Cybersecurity Travel Technical Radio Site Map Contact

Tweet