Common Weakness Enumeration

CWE Glossary Definition

LANGSPEC: Language-Specific Issues and Examples
LANGSPEC: Language-Specific Issues and Examples

There are entries in CWE that describe a weakness specific only to a certain language or even function within a language. There are two different types of these problems:

1) Violation of a language-specific standard. This includes entries such as CWE #245, J2EE Bad Practices: getConnection() or CWE #383, J2EE Bad Practices: Threads.

These entries aren't necessarily weaknesses, but they might be indicative of error prone locations in the code or areas where vulnerabilities are likely to be introduced. Currently, these entries appear sporadically throughout CWE under various parents, but there is no easy way to corral and review all of these issues.

2) Language specific examples of language independent weaknesses. For Example, CWE #481, Assigning Instead of Comparing and CWE #597,Erroneous String Compare.

The latter was written up specific to Java, however it is relevant to other languages and the consequences can vary. The former was written up with C in mind, however its consequences and detectability vary across languages as well.

Possible Solutions / Questions to Discuss

• Leave CWE as it is.
• Enumerate each individual function-specific variation as its own CWE entry.
• Include all function-specific issues as examples in a more general CWE entry.
• Create a new type of entry which will allow for capturing each type of function-specific issue as an individual sub-entry within the more general weakness CWE entry.
• Create a function-independent entry identifying the more abstract weakness and include each related function-specific CWE entry as a child. For example, consider CWE #573, Failure to Follow Specification.
• Create a function-independent entry identifying the more abstract weakness and exclude all current function-specific entries from CWE.
• Leave them as one entry, with the attributes specific to each language detailed in the entries.
• Other ideas?

Relevant Use-Cases

Assessment Vendors: Search for different issues based upon the language used.

Assessment Customers: Pick out the weaknesses that apply to languages used in their code base.

Academic Researchers: Aid in identifying language-specific issues for improvements to the language and its constructs.

Applied Vulnerability Researchers: Tailor testing and research to the specific issues of the languages being explored.

Refined Vulnerability Information (RVI) Providers: identify likely problems in specific languages and search for trends.

Educators: Helpful to find and teach language-specific issues.

Software Customers: Not applicable.

Software Developers: Identify language-specific issues they may have to be aware of. Help to choose the "more secure" language.

Recommendation

The CWE Researcher Community is strongly encouraged to provide feedback to the CWE team or the researchers list regarding this recommendation.

No final decision should be made without first consulting the ISO/IEC Project 22.24772: "Guidance for Avoiding Vulnerabilities through Language Selection and Use". This project focuses on language-specific constructs that have security implications. See http://aitc.aitcnet.org/isai/.

Depending on the coverage scope of CWE, the enumeration and upkeep of all of the function- and language-specific entries (or "sub-nodes") would improve specificity and completeness. This level of granularity might not be useful for many CWE consumers, although properly constructed views might be able to address the concern that there would be "too many" nodes in CWE. Additionally, some of the issues here may overlap context-specific issues or be significantly vague that most CWEs could be included as children.

Therefore, at this time, the MITRE CWE team recommends pursuing an approach in which function- and language-specific entries are MERGED into a more abstract entry that is more function- or language- independent, while clearly capturing the specific variants. Note: the mechanisms for node restructuring are still being defined; see the node restructuring page for possible approaches.

This would mean that all relevant CWEs, including CWE-111, CWE-245, CWE-382, etc., are MERGED into a more abstract CWE and their content would be added as supplementary examples, or "sub-nodes." However, the level of abstraction for the merged node should not be too high.

Notes

Below is preliminary work done in order to more clearly identify problems present in CWE. Any issues not addressed above should be brought to the attention of the whole list, especially if the CWE ID is missing from the notes below.

Types of Language-Specific Issues:

• Unsafe use of a Func/Lang specification or standard *111, 245, 382, 491, 579, 581, 586, 383
• Potentially legitimate functionality or non-security related problem that might indicate a mistake on the programmers part, possibly context specific or indicative of quality. Specific to a particular language or function. *467, 481, 482, 484, 558, 560, 572, 580, 584, 587, 597
• Failed protection mechanism / violation of universal policies specific to a language or function *473, 582, 583, 616, 621, 98

Alternative way to view the entries:

• Specific Functions with security implications
• Specific Functions without security implications
• Language-Specific Constructs
• Language-Independent Constructs

Another alternative:

• PHP
• Java
• C/C++
• ...etc.
• Language Independent Constructs, Implications vary by language

Complete List of Examples

All CWE nodes that are affected by this discussion point are listed on a separate page.

Document version: 0.1    Date: September 13, 2007

This is a draft document. It is intended to support maintenance of CWE, and to educate and solicit feedback from a specific technical audience. This document does not reflect any official position of the MITRE Corporation or its sponsors. Copyright © 2007, The MITRE Corporation. All rights reserved. Permission is granted to redistribute this document if this paragraph is not removed. This document is subject to change without notice.