Common Weakness Enumeration

CWE Glossary Definition

Name of Your Organization:

David A. Wheeler

Web Site:

http://www.dwheeler.com/flawfinder

Compatible Capability:

Flawfinder

Capability home page:

http://www.dwheeler.com/flawfinder
http://sourceforge.net/projects/flawfinder/

Product Accessibility <CR_2.4>

Provide a short description of how and where your capability is made available to your customers and the public (required):

Downloadable at http://www.dwheeler.com/flawfinder or http://sourceforge.net/projects/flawfinder/. Older versions of Flawfinder are packaged for Cygwin, various Linux distributions, MacOS X, and *BSDs; it is expected that they will update their packages to version 1.28 or later.

Map Currency Indication <CR_6.1>

Describe how and where your capability indicates the most recent CWE content used to create or update its mappings (required):

Manual ("man") page, section "Common Weakness Enumeration" indicates the CWE content used to create the mappings. Currently it documents that CWE Version 2.7 (released June 23, 2014) was used for the mapping.

Map Currency Update Approach <CR_6.2>

Indicate how often you plan on updating the mappings to reflect the current CWE content and describe your approach to keeping reasonably current with the CWE content when mapping them to your repository (recommended):

The Flawfinder tool maps to mature CWE entries, so I expect that those parts of CWE will not change or will change very infrequently.

The current CWE mappings embedded in the tool select the most specific CWE the tool can determine. In theory, most reports could theoretically be mapped to CWE-676 (Use of Potentially Dangerous Function), but such a mapping would not be useful. Thus, more specific mappings were preferred where one could be found. Flawfinder is a lexical analysis tool, so it is typically not possible for it to map to extremely specific CWEs. As a result, it is unlikely to need much updating to maintain currency in CWE mappings. It simply doesn’t have enough information to refine to a detailed CWE level that CWE changes might affect.

If there are recommended mapping refinements, please let me know. Errors, refinements, or changes due to CWE content updates would be treated as bugs, and would be tracked and resolved that way. Bugs are normally tracked through the Flawfinder issue tracker, while broader-ranging issues are discussed on its mailing list, both of which can be found via http://sourceforge.net/projects/flawfinder.

CWE AND COMPATIBILITY DOCUMENTATION <CR_5.1>

Provide a copy, or directions to its location, of where your documentation describes CWE and CWE compatibility for your customers (required):

The manual ("man page") section "Common Weakness Enumeration (CWE)" provides information on Flawfinder CWE support. See http://www.dwheeler.com/flawfinder/flawfinder.pdf.

DOCUMENTATION OF FINDING ELEMENTS USING CWE IDENTIFIERS <CR_5.2>

Provide a copy, or directions to its location, of where your documentation describes the specific details of how your customers can use CWE identifiers to find the individual security elements within your capability’s repository (required):

The manual ("man page") section "Common Weakness Enumeration (CWE)" provides information on flawfinder CWE support. See http://www.dwheeler.com/flawfinder/flawfinder.pdf. It lists the CWE identifiers that can be reported by the tool. If the tool detects a potential security vulnerability (a "hit") with a CWE mapping it reports the CWE identifier as "CWE-number". To see a specific mapping of all conditions to the CWE identifiers, search for "CWE-" in its Python 2 source code, included in the download and also available at http://www.dwheeler.com/flawfinder/flawfinder.

DOCUMENTATION OF FINDING CWE IDENTIFIERS USING ELEMENTS <CR_5.3>

Provide a copy, or directions to its location, of where your documentation describes the process a user would follow to find the CWE identifiers associated with individual security elements within your capability’s repository (required):

The manual ("man page") section "Common Weakness Enumeration (CWE)" provides information on flawfinder CWE support. See http://www.dwheeler.com/flawfinder/flawfinder.pdf. If you only want to see a list of CWE security elements (tokens which are typically function names), and possibly the default CWE reported by that element, use the "--listrules" option as described under "options". To see a specific mapping of a function name to the CWE identifiers, search for the name of that function in its Python 2 source code, available at http://www.dwheeler.com/flawfinder/flawfinder; this shows the default mapping of function name to CWE, and the name of the refining function. The refining function may select a better CWE match in some cases than the default result, so you need to check there to determine all possible matches for a given pattern (function name).

DOCUMENTATION INDEXING OF CWE-RELATED MATERIAL <CR_5.4>

If your documentation includes an index, provide a copy of the items and resources that you have listed under "CWE" in your index. Alternately, provide directions to where these "CWE" items are posted on your web site (recommended):

The manual ("man page") section "Common Weakness Enumeration (CWE)" provides information on Flawfinder CWE support. See http://www.dwheeler.com/flawfinder/flawfinder.pdf. Much of the information below is a summary or extract of this material.

Type-Specific Capability Questions

FINDING TASKS USING CWE IDENTIFIERS <CR_A.2.1>

Give detailed examples and explanations of how a user can locate tasks in the tool by looking for their associated CWE identifier (required):

The tool only supports one task, examining source code to report "hits" of possible vulnerabilities. It can re-load previous results, but even then, it is simply picking up where it left off in support of this one task. The tool always reports CWE Identifiers where there is a known match. Thus, it vacuously meets this requirement; for any CWE Identifier, there is only task to select. A user could select a subset of CWE Identifiers to report, as described below.

FINDING CWE IDENTIFIERS USING ELEMENTS IN REPORTS <CR_A.2.2>

Give detailed examples and explanations of how, for reports that identify individual security elements, the tool allows the user to determine the associated CWE identifier for the individual security elements in the report (required):

Flawfinder reports "hits", a match between the evaluated source code and a pattern (signature) that suggests a potential vulnerability. Each hit report includes one or more CWE identifiers within parentheses when there is a known mapping to a CWE. These patterns are typically the name of a function, but can also take other information into account (e.g., the text in the parameters of a function). These patterns of potential vulnerabilities are the "elements" as referred to in this document. Here are just a few examples, extracted from a sample Flawfinder result:

test.c:32: [5] (buffer) gets: Does not check for buffer overflows (CWE-
120). Use fgets() instead.

 gets(f);

test.c:56: [5] (buffer) strncat: Easily used incorrectly (e.g.,
incorrectly computing the correct maximum size to add) (CWE-120).
Consider strcat_s, strlcat, or automatically resizing strings. Risk is
high; the length parameter appears to be a constant, instead of
computing the number of characters left.

  strncat(d,s,sizeof(d)); /* Misuse - this should be flagged as
riskier. */

test.c:60: [5] (buffer) MultiByteToWideChar: Requires maximum length in CHARACTERS, not bytes (CWE-120). Risk is high, it appears that the size
is given as bytes, but the function requires size as characters.

  MultiByteToWideChar(CP_ACP,0,szName,-
1,wszUserName,sizeof(wszUserName));

test.c:73: [5] (misc) SetSecurityDescriptorDacl: Never create NULL
ACLs; an attacker can set it to Everyone (Deny All Access), which would
even forbid administrator access (CWE-732).

  SetSecurityDescriptorDacl(&sd,TRUE,NULL,FALSE);

test.c:38: [4] (format) syslog: If syslog's format strings can be
influenced by an attacker, they can be exploited (CWE-134). Use a
constant format string for syslog.

  syslog(LOG_ERR, attacker_string);

GETTING A LIST OF CLAIMED CWE IDENTIFIER COVERAGE <CR_A.2.3>

Give detailed examples and explanations of how a user can obtain a listing of all of the CWE identifiers that the owner claims the tool is effective at locating in software (required):

The manual ("man page") section "Common Weakness Enumeration (CWE)" lists all CWEs that the tool can report; see: http://www.dwheeler.com/flawfinder/flawfinder.pdf. There is high confidence that this list is correct, because this list was created by running the program "cwe.l" (it was created automatically, not by hand evaluation). As with nearly all tools, the author does NOT claim that the Flawfinder tool finds ALL cases of specific CWEs, merely that it is effective at finding the specific patterns (signatures) it uses and matching those patterns to CWEs.

GETTING A LIST OF CWE IDENTIFIERS ASSOCIATED WITH TASKS <CR_A.2.6>

Give detailed examples and explanations of how a user can obtain a listing of all of the CWE identifiers that are associated with the tool’s tasks (recommended):

The tool only supports one task. The manual ("man page") section "Common Weakness Enumeration (CWE)" lists all CWEs that the tool can report. Since there is only one task, any of those identifiers are associated with the one task. If the goal is to only report a subset of CWEs, that can be achieved using the "--regex" aka "-e" option, e.g., "flawfinder –e CWE-120" would report only hits with CWE-120.

SELECTING TASKS WITH A LIST OF CWE IDENTIFIERS <CR_A.2.7>

Describe the steps and format that a user would use to select a set of tasks by providing a file with a list of CWE identifiers (recommended):

The tool only supports one task. The manual ("man page") section "Common Weakness Enumeration (CWE)" lists all CWEs that the tool can report. Since there is only one task, any of those identifiers are associated with the one task.

If the goal is to only report a subset of CWEs listed in a file, that can be achieved on a Unix-like system using the "--regex" aka "-e" option. The file must be in regular expression format. For example, "flawfinder –e $(cat file1)" would report only hits that matched the pattern in "file1"; if file1 contained "CWE-120|CWE-126" it would only report hits matching those CWEs.

SELECTING TASKS USING INDIVIDUAL CWE IDENTIFIERS <CR_A.2.8>

Describe the steps that a user would follow to browse, select, and deselect a set of tasks for the tool by using individual CWE identifiers (recommended):

The tool only supports one task. The manual ("man page") section "Common Weakness Enumeration (CWE)" lists all CWEs that the tool can report. Since there is only one task, any of those identifiers are associated with the one task.

If the goal is to only report a subset of CWEs listed in a file, that can be achieved on a Unix-like system using the "--regex" aka "-e" option. The file must be in regular expression format. For example, "flawfinder –e $(cat file1)" would report only hits that matched the pattern in "file1"; if file1 contained "CWE-120|CWE-126" it would only report hits matching those CWEs.

NON-SUPPORT NOTIFICATION FOR A REQUESTED CWE IDENTIFIER <CR_A.2.9>

Provide a description of how the tool notifies the user that a task associated with a selected CWE Identifier cannot be performed (recommended):

The tool only supports one task, so there is no mechanism for highlighting the difference between one task and another. In addition, the tool has no mechanism for automatically reporting that there is no pattern (signature) for a given CWE identifier. However, the manual ("man page") section "Common Weakness Enumeration (CWE)" lists all CWEs that the tool can report, so a user who wants to see if a CWE can be found can quickly consult that. The list is not long, and it is sorted, so it’s trivial to consult. Note that this is only recommended, not required.

ELECTRONIC DOCUMENT FORMAT INFO <B.3.1>

Provide details about the different electronic document formats that you provide and describe how they can be searched for specific CWE-related text (required):

The primary documentation is a "man page", a text format document which can be searched by looking for "CWE-number". The section "Common Weakness Enumeration" in the main page (which is easier to read in pdf format) lists the full set of CWEs that can be reported.

The tool fundamentally supports two formats when reporting, "text" and "html"; various options provide finer control over their formats. In both cases, you can search for the regular expression pattern "CWE-number" after-the-fact to find a particular-related text. The text format, in particular, can be passed through “grep” to search for particular CWE Identifiers (just match on "CWE-number"). In addition, the "--regex" or "-e" options allow users to select which CWEs to report; the tool is fairly fast, so in many cases users would be more likely to simply re-run the tool instead of searching or filtering specific CWE Identifiers.

ELECTRONIC DOCUMENT LISTING OF CWE IDENTIFIERS <CR_B.3.2>

If one of the capability’s standard electronic documents only lists security elements by their short names or titles provide example documents that demonstrate how the associated CWE identifiers are listed for each individual security element (required):

In the reports every "hit" that has a CWE mapping directly reports the CWE Identifier as "CWE-number", as well as general explanation of the issue. Users who do not recognize a specific CWE Identifier could consult the man page section "Common Weakness Enumeration (CWE)", which gives the full name of each CWE Identifier. Since the user is immediately presented with the CWE Identifier, without having to go through some other mapping, they could immediately go to cwe.mitre.org or other sources to learn more about that CWE.

ELECTRONIC DOCUMENT ELEMENT TO CWE IDENTIFIER <CR_B.3.3>

Provide example documents that demonstrate the mapping from the capability’s individual elements to the respective CWE identifier(s) (recommended):

Users normally use Flawfinder to examine source code to generate electronic reports, and Flawfinder directly reports the CWE mapping (where available) in these reports. Thus, users don’t have to consult a separate mapping from a report to a CWE Identifier; it is directly provided to them. In addition, if users request a report in HTML format, the CWE Identifiers have a hypertext link to their definitions at MITRE.

The Flawfinder source code, included in the distribution, fully documents the mapping from the search elements to the respective CWE Identifiers. It is a single Python file. The "c_rules" dataset defines most rules, with reference to a function that may make further refinements. Here are a few examples:

 "gets|_getts":
(normal, 5, "Does not check for buffer overflows (CWE-120)",
 "Use fgets() instead", "buffer", "", {'input' : 1}),
  ...
 # OpenSSL EVP calls to use DES.
 "EVP_des_ecb|EVP_des_cbc|EVP_des_cfb|EVP_des_ofb|EVP_desx_cbc":
(normal, 4,
 "DES only supports a 56-bit keysize, which is too small given today's
computers (CWE-327)",
 "Use a different patent-free encryption algorithm with a larger"
keysize, " +
 "such as 3DES or AES",
 "crypto", "", {}),

FINDING ELEMENTS USING CWE IDENTIFIERS THROUGH THE GUI <CR_B.4.1>

Give detailed examples and explanations of how the GUI provides a "find" or "search" function for the user to identify your capability’s elements by looking for their associated CWE identifier(s) (required):

Flawfinder does not have a "graphical user interface" (GUI) as the term is typically used; it has a command line interface (CLI). Presumably this question is really about the user interface, so the following answers apply to the user interface.

The tool only supports one task, so there is no need to "search" for different tasks that the tool does. The report always includes CWE Identifiers (where available) with the relevant documentation elements, so CWE Identifiers are automatically available and require no separate step to find them. A user can generate a report that only reports matches to specific CWEs (instead of all CWEs) by using "--regex" or "-e" on the CWE identifier, e.g., "flawfinder --regex CWE-120". These would be the subset of relevant documentation elements, which I believe is what is meant by this question.

If a user actually wanted to find the tool elements using CWEs, instead of documentation elements, he could search for the CWE in the source code (just search for "CWE-number"). However, I do not think that was the intent of this question.

GUI ELEMENT TO CWE IDENTIFIER MAPPING <CR_B.4.2>

Briefly describe how the associated CWE identifiers are listed for the individual security elements or discuss how the user can use the mapping between CWE identifiers and the capability’s elements, also describe the format of the mapping (required):

The tool only supports one task, so there is no need to map a user interface element to a CWE Identifier for different tasks that the tool does. The report always includes CWE Identifiers (where available) with the relevant documentation elements, so CWE Identifiers are automatically available and require no separate step to find them. Thus, the mappings are vacuous; it always does the same one task, and it reports CWE Identifiers at all times.

GUI EXPORT ELECTRONIC DOCUMENT FORMAT INFO <CR_B.4.3>

Provide details about the different electronic document formats that you provide for exporting or accessing CWE-related data and describe how they can be searched for specific CWE-related text (recommended):

The tool fundamentally supports two formats when reporting, "text" and "html"; various options provide finer control over their formats. In both cases, you can search for the pattern "CWE-number" after-the-fact to find a particular-related text. The text format, in particular, can be passed through "grep" to search for particular CWE identifiers (just match on "CWE-number"). In addition, the "--regex" or "-e" options allow users to select which CWEs to report; the tool is fairly fast, so in many cases users would be more likely to simply re-run the tool instead of searching or filtering specific CWE Identifiers.

STATEMENT OF COMPATIBILITY <CR_2.11>

Have an authorized individual sign and date the following Compatibility Statement (required):

"As an authorized representative of my organization I agree that we will abide by all of the mandatory CWE Compatibility Requirements as well as all of the additional mandatory CWE Compatibility Requirements that are appropriate for our specific type of capability."

Addendum: I am representing myself in these statements, and not my employer. I cannot promise to meet any changed set of requirements that I have not seen, so this agreement only applies to the current requirements as I understand them. I expect to retain CWE compatibility as described in this document (CWE Searchable, CWE Output, Mapping, CWE Documentation, and CWE Coverage), but anything can happen. Therefore, I retain the right to drop CWE compatibility in this tool in the future, but if I choose to do so, I promise to attempt to alert MITRE of this decision and remove any relevant CWE compatibility claims from the website.

Name: David A. Wheeler

Title: Author

STATEMENT OF ACCURACY <CR_3.4>

Have an authorized individual sign and date the following accuracy Statement (recommended):

"As an authorized representative of my organization I agree that we will abide by all of the mandatory CWE Compatibility Requirements as well as all of the additional mandatory CWE Compatibility Requirements that are appropriate for our specific type of capability."

Addendum: If you believe there are errors, please contact me.

Name: David A. Wheeler

Title: Author

STATEMENT ON FALSE-POSITIVES AND FALSE-NEGATIVES <CR_B.2.10> and/or <CR_B.3.7>

FOR TOOLS AND SERVICES ONLY — Have an authorized individual sign and date the following statement about your tools efficiency in identification of security elements (required):

"As an authorized representative of my organization I agree that we will abide by all of the mandatory CWE Compatibility Requirements as well as all of the additional mandatory CWE Compatibility Requirements that are appropriate for our specific type of capability."

Note: In this context, a security element is a signature (aka pattern). In Flawfinder a signature is a predefined lexical token (typically the name of a function), possibly refined by additional information such as its parameters. An "event" occurs when Flawfinder detects a signature match in the source code being analyzed. When Flawfinder detects a signature match, it also warns of possible vulnerabilities that the signature may indicate. Like most tools, a signature match is not a guarantee that there is vulnerability. Indeed, since Flawfinder is a simple lexical tool, it is more subject to false positives than more sophisticated (and more complex) tools. However, Flawfinder generally correctly reports the detection of security elements as defined here.

Name: David A. Wheeler

Title: Author