Baseline for Ed 2 of tr 24772



Yüklə 0,54 Mb.
səhifə14/54
tarix16.08.2018
ölçüsü0,54 Mb.
#63136
1   ...   10   11   12   13   14   15   16   17   ...   54

6.18 Dead Store [WXQ]

6.18.1 Description of application vulnerability


A variable's value is assigned but never subsequently used, either because the variable is not referenced again, or because a second value is assigned before the first is used. This may suggest that the design has been incompletely or inaccurately implemented, for example, a value has been created and then ‘forgotten about’.

This vulnerability is very similar to 6.19 Unused Variable [YZS].


6. 18.2 Cross reference


CWE:

563. Unused Variable

MISRA C++ 2008: 0-1-4 and 0-1-6

CERT C guidelines: MSC13-C

See also 6.19 Unused Variable [YZS]

6. 18.3 Mechanism of failure


A variable is assigned a value but this is never subsequently used. Such an assignment is then generally referred to as a dead store.

A dead store may be indicative of careless programming or of a design or coding error; as either the use of the value was forgotten (almost certainly an error) or the assignment was performed even though it was not needed (at best inefficient). Dead stores may also arise as the result of mistyping the name of a variable, if the mistyped name matches the name of a variable in an enclosing scope.

There are legitimate uses for apparent dead stores. For example, the value of the variable might be intended to be read by another execution thread or an external device. In such cases, though, the variable should be marked as volatile. Common compiler optimization techniques will remove apparent dead stores if the variables are not marked as volatile, hence causing incorrect execution.

A dead store is justifiable if, for example:



  • The code has been automatically generated, where it is commonplace to find dead stores introduced to keep the generation process simple and uniform.

  • The code is initializing a sparse data set, where all members are cleared, and then selected values assigned a value.

6.18.4 Applicable language characteristics


This vulnerability description is intended to be applicable to languages with the following characteristics:

  • Any programming language that provides assignment.

6.18.5 Avoiding the vulnerability or mitigating its effects


Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

  • Use static analysis to identify any dead stores in the program, and ensure that there is a justification for them.

  • If variables are intended to be accessed by other execution threads or external devices, mark them as volatile.

  • Avoid declaring variables of compatible types in nested scopes with similar names.

  • For security, assign zero (or some other information free value) after the last intended read.

6.18.6 Implications for standardization


In future standardization activities, the following items should be considered:

  • Languages should consider providing optional warning messages for dead store.

6.19 Unused Variable [YZS]

6.19.1 Description of application vulnerability


An unused variable is one that is declared but neither read nor written in the program. This type of error suggests that the design has been incompletely or inaccurately implemented.

Unused variables by themselves are innocuous, but they may provide memory space that attackers could use in combination with other techniques.

This vulnerability is similar to 6.18 Dead Store [WXQ] if the variable is initialized but never used.

6.19.2 Cross reference


CWE:

563. Unused Variable

MISRA C++ 2008: 0-1-3

CERT C guidelines: MSC13-C

See also 6.18 Dead Store [WXQ]

6.19.3 Mechanism of failure


A variable is declared, but never used. The existence of an unused variable may indicate a design or coding error.

Because compilers routinely diagnose unused local variables, their presence may be an indication that compiler warnings are either suppressed or are being ignored.

While unused variables are innocuous, they may provide available memory space to be used by attackers to exploit other vulnerabilities.

6.19.4 Applicable language characteristics


This vulnerability description is intended to be applicable to languages with the following characteristics:

  • Languages that provide variable declarations.

6.19.5 Avoiding the vulnerability or mitigating its effects


Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

  • Enable detection of unused variables in the compiler.

  • Use static analysis to identify any unused variables in the program, and ensure that there is a justification for them.

6.19.6 Implications for standardization


In future standardization activities, the following items should be considered:

  • Languages should consider requiring mandatory diagnostics for unused variables.

6.20 Identifier Name Reuse [YOW]

6.20.1 Description of application vulnerability


When distinct entities are defined in nested scopes using the same name it is possible that program logic will operate on an entity other than the one intended.

When it is not clear which identifier is used, the program could behave in ways that were not predicted by reading the source code. This can be found by testing, but circumstances can arise (such as the values of the same-named objects being mostly the same) where harmful consequences occur. This weakness can also lead to vulnerabilities such as hidden channels where humans believe that important objects are being rewritten or overwritten when in fact other objects are being manipulated.

For example, the innermost definition is deleted from the source, the program will continue to compile without a diagnostic being issued (but execution can produce unexpected results).

6.20.2 Cross reference


JSF AV Rules: 120, 135, 136 and 137,

MISRA C 2012: 5.3, 5.8, 5.9, 21.1, 21.2

MISRA C++ 2008: 2-10-2, 2-10-3, 2-10-4, 2-10-5, 2-10-6, 17-0-1, 17-0-2, and 17-0-3

CERT C guidelines: DCL01-C and DCL32-C

Ada Quality and Style Guide: 5.6.1 and 5.7.1

6.20.3 Mechanism of failure


Many languages support the concept of scope. One of the ideas behind the concept of scope is to provide a mechanism for the independent definition of identifiers that may share the same name.

For instance, in the following code fragment:


int some_var;

{

int t_var;



int some_var; /* definition in nested scope */
t_var = 3;

some_var = 2;

}
an identifier called some_var has been defined in different scopes.

If either the definition of some_var or t_var that occurs in the nested scope is deleted (for example, when the source is modified) it is necessary to delete all other references to the identifier’s scope. If a developer deletes the definition of t_var but fails to delete the statement that references it, then most languages require a diagnostic to be issued (such as reference to undefined variable). However, if the nested definition of some_var is deleted but the reference to it in the nested scope is not deleted, then no diagnostic will be issued (because the reference resolves to the definition in the outer scope).

In some cases non-unique identifiers in the same scope can also be introduced through the use of identifiers whose common substring exceeds the length of characters the implementation considers to be distinct. For example, in the following code fragment:

extern int global_symbol_definition_lookup_table_a[100];

extern int global_symbol_definition_lookup_table_b[100];

the external identifiers are not unique on implementations where only the first 31 characters are significant. This situation only occurs in languages that allow multiple declarations of the same identifier (other languages require a diagnostic message to be issued).

A related problem exists in languages that allow overloading or overriding of keywords or standard library function identifiers. Such overloading can lead to confusion about which entity is intended to be referenced.

Definitions for new identifiers should not use a name that is already visible within the scope containing the new definition. Alternately, utilize language-specific facilities that check for and prevent inadvertent overloading of names should be used.


6.20.4 Applicable language characteristics


This vulnerability is intended to be applicable to languages with the following characteristics:

  • Languages that allow the same name to be used for identifiers defined in nested scopes.

  • Languages where unique names can be transformed into non-unique names as part of the normal tool chain.

6.20.5 Avoiding the vulnerability or mitigating its effects


Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

  • Ensure that a definition of an entity does not occur in a scope where a different entity with the same name is accessible and can be used in the same context. A language-specific project coding convention can be used to ensure that such errors are detectable with static analysis.

  • Ensure that a definition of an entity does not occur in a scope where a different entity with the same name is accessible and has a type that permits it to occur in at least one context where the first entity can occur.

  • Use language features, if any, which explicitly mark definitions of entities that are intended to hide other definitions.

  • Develop or use tools that identify name collisions or reuse when truncated versions of names cause conflicts.

  • Ensure that all identifiers differ within the number of characters considered to be significant by the implementations that are likely to be used, and document all assumptions.

6.20.6 Implications for standardization


In future standardization activities, the following items should be considered:

  • Languages should require mandatory diagnostics for variables with the same name in nested scopes.

  • Languages should require mandatory diagnostics for variable names that exceed the length that the implementation considers unique.

  • Languages should consider requiring mandatory diagnostics for overloading or overriding of keywords or standard library function identifiers.

Yüklə 0,54 Mb.

Dostları ilə paylaş:
1   ...   10   11   12   13   14   15   16   17   ...   54




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə