Error correcting software from the beginning

A coalition of government, academic and private-sector security organizations have announced a list of the top 25 programming errors that are responsible for the majority of security vulnerabilities plaguing applications.

The list, which is available online, represents a consensus of the most significant errors on which the IT community should concentrate to improve the security and reliability of software. Developers hope the list will be used by universities in programming curriculum, by vendors and developers as a standard for proper coding, and as a specification when acquiring software.

The initiative was managed by the Sans Institute and Mitre Corp., with support from the National Security Agency and the Homeland Security Department’s National Cyber Security Division.

Konrad Vesey of NSA’s Information Assurance Directorate said the list will help shift software security away from a reactive posture by system administrators, and make it more proactive by putting more responsibility with software developers.

"When consumers see that most vulnerabilities are caused by a mere twenty-five weaknesses, a new standard for due diligence in product development is likely to emerge,” Vesey said. “The vocabulary of software security is expanded from what the vendor tested against to what the vendor built in."

Contributors to the program include major software and security companies, along with universities, independent organizations and individuals, as well as U.S. and foreign government agencies.

The errors included in the list are not newly discovered; they are drawn from the Common Weakness Enumeration database, a standardized listing of more than 700 recognized programming weaknesses that is maintained by Mitre with support from DHS.

A weakness is an error or condition in software code that, under certain circumstances, can create a vulnerability that can be exploited maliciously. Automated tools exist to look for many of these weaknesses, but finding and eliminating them is not a simple task.

“No tool can correctly determine in every conceivable case whether or not a piece of code has a vulnerability,” the National Institute of Standards and Technology wrote in Special Publication 500-268 when it developed specifications for source code analysis tools. “A weakness may result in a vulnerability in one environment, but not in another.” There also are mathematical and practical limits to the ability of algorithms to detect weaknesses in software, and not all weaknesses result in vulnerabilities.

NIST specified a list of 21 source-code weaknesses from the CWE database that source code analysis tools should be able to identify. There is little overlap between that list and the top 25 list released today by Sans and Mitre. Only three weaknesses appear on both lists.

Developers of the list, which will be updated regularly, expect that it will be used as a standard for evaluating coding and software development. Customers could use it as a specification in acquiring software from vendors, requiring that the software be certified free of the errors; testing and analysis tools used by programmers and customers could be designed to focus on the errors; colleges could teach against them in programming courses, and employers could require an understanding of them by their programmers and application developers.

The top 25 errors fall into three categories: Insecure interaction between components, with nine errors; risky resource management, also with nine errors; and porous defenses, with seven errors. Full details of the weaknesses are available online from Sans and Mitre. Those included in the list, along with their CWE identification, are:

Insecure Interaction Between Components:

• Improper Input Validation (CWE-20)
• Improper Encoding or Escaping of Output (CWE-116)
• Failure to Preserve SQL Query Structure, or SQL Injection (CWE-89)
• Failure to Preserve Web Page Structure, or Cross-site Scripting (CWE-79)
• Failure to Preserve OS Command Structure, or OS Command Injection (CWE-78)
• Cleartext Transmission of Sensitive Information (CWE-319)
• Cross-site Request Forgery (CWE-352)
• Race Condition (CWE-362)
•  Error Message Information Leak (CWE-209)

Risky Resource Management:

• Failure to Constrain Operations Within the Bounds of a Memory Buffer (CWE-119)
• External Control of Critical State Data (CWE-642)
• External Control of File Name or Path (CWE-73)
• Untrusted Search Path (CWE-426)
• Failure to Control Generation of Code, or Code Injection (CWE-94)
• Download of Code Without Integrity Check (CWE-494)
• Improper Resource Shutdown or Release (CWE-404)
• Improper Initialization (CWE-665)
• Incorrect Calculation (CWE-682)

Porous Defenses:

• Improper Access Control (CWE-285)
• Use of a Broken or Risky Cryptographic Algorithm (CWE-327)
• Hard-coded Password (CWE-259)
• Insecure Permission Assignment for Critical Resource (CWE-732)
• Use of Insufficiently Random Values (CWE-330)
• Execution with Unnecessary Privileges (CWE-250)
• Client-side Enforcement of Server-Side Security (CWE-602)