Baseline for Ed 2 of tr 24772

7.25 Unspecified Functionality [BVQ]

7.25.1 Description of application vulnerability

Unspecified functionality is code that may be executed, but whose behaviour does not contribute to the requirements of the application. While this may be no more than an amusing ‘Easter Egg’, like the flight simulator in a spreadsheet, it does raise questions about the level of control of the development process.

In a security-critical environment particularly, the developer of an application could include a ‘trap-door’ to allow illegitimate access to the system on which it is eventually executed, irrespective of whether the application has obvious security requirements.

7.25.2 Cross reference

JSF AV Rule: 127

MISRA C 2012: 1.2, 2.1, 3.1, and 4.4

XYQ: Dead and Deactivated code.

7.25.3 Mechanism of failure

Unspecified functionality is not a software vulnerability per se, but more a development issue. In some cases, unspecified functionality may be added by a developer without the knowledge of the development organization. In other cases, typically Easter Eggs, the functionality is unspecified as far as the user is concerned (nobody buys a spreadsheet expecting to find it includes a flight simulator), but is specified by the development organization. In effect they only reveal a subset of the program’s behaviour to the users.

In the first case, one would expect a well-managed development environment to discover the additional functionality during validation and verification. In the second case, the user is relying on the supplier not to release harmful code.

In effect, a program’s requirements are ‘the program should behave in the following manner and do nothing else’. The ‘and do nothing else’ clause is often not explicitly stated, and can be difficult to demonstrate.

7.25.4 Avoiding the vulnerability or mitigating its effects

End users can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Ensure that programs and development tools that are to be used in critical applications come from a developer or organization that uses a recognized and audited development process for the development of those programs and tools.
  

Ensure that the development process generates documentation showing traceability from source code to requirements, in effect answering ‘why is this unit of code in this program?’. Where unspecified functionality is there for a legitimate reason (such as diagnostics required for developer maintenance or enhancement), the documentation should also record this. It is not unreasonable for customers of bespoke critical code to ask to see such traceability as part of their acceptance of the application.

7.26 Distinguished Values in Data Types [KLK]

7.26.1 Description of application vulnerability

Sometimes, in a type representation, certain values are distinguished as not being members of the type, but rather as providing auxiliary information. Examples include special characters used as string terminators, distinguished values used to indicate out of type entries in SQL (Structured Query Language) database fields, and sentinels used to indicate the bounds of queues or other data structures. When the usage pattern of code containing distinguished values is changed, it may happen that the distinguished value happens to coincide with a legitimate in-type value. In such a case, the value is no longer distinguishable from an in-type value and the software will no longer produce the intended results.

7.26.2 Cross reference

CWE:

20. Improper input validation

137. Representation errors

JSF AV Rule: 151

7.26.3 Mechanism of failure

A “distinguished value” or a "magic number" in the representation of a data type might be used to represent out-of-type information. Some examples include the following:

• 
  The use of a special code, such as “00”, to indicate the termination of a coded character string.
  
• 
  The use of a special value, such as “999…9”, as the indication that the actual value is either not known or is invalid.
  

If the use of the software is later generalized, the once-special value can become indistinguishable from valid data. Note that the problem may occur simply if the pattern of usage of the software is changed from that anticipated by the software’s designers. It may also occur if the software is reused in other circumstances.

An example of a change in the pattern of usage is this: An organization logs visitors to its buildings by recording their names and national identity numbers or social security numbers in a database. Of course, some visitors legitimately don’t have or don’t know their social security number, so the receptionists enter numbers to “make the computer happy.” Receptionists at one building have adopted the convention of using the code “555-55-5555” to designate children of employees. Receptionists at another building have used the same code to designate foreign nationals. When the databases are merged, the children are reclassified as foreign nationals or vice-versa depending on which set of receptionists are using the newly merged database.

An example of an unanticipated change due to reuse is this: Suppose a software component analyzes radar data, recording data every degree of azimuth from 0 to 359. Packets of data are sent to other components for processing, updating displays, recording, and so on. Since all degree values are non-negative, a distinguished value of -1 is used as a signal to stop processing, compute summary data, close files, and so on. Many of the components are to be reused in a new system with a new radar analysis component. However the new component represents direction by numbers in the range -180 degrees to 179 degrees. When an azimuth value of -1 is provided, the downstream components will interpret that as the indication to stop processing. If the magic value is changed to, say, -999, the software is still at risk of failing when future enhancements (say, counting accumulated degrees on complete revolutions) bring -999 into the range of valid data.

Distinguished values should be avoided. Instead, the software should be designed to use distinct variables to encode the desired out-of-type information. For example, the length of a character string might be encoded in a dope vector and validity of data entries might be encoded in distinct Boolean values.

This vulnerability extends to numbers placed in the code, such as 7, hex F00F. such numbers are almost universally used in multiple places. The first issue is that there is rarely a full explanation given for the value in all places where it is defined, and under maintenance maintainers are left guessing at its meaning. A second issue is that, under maintenance (or before), the value changes, but not all occurrences get updated, causing erroneous algorithms. A third issue is that such “magic values” are almost always placed in the data section of the file that contains the executable program, and simple searches with data dumping tools reveals such values (say for example a password) to a possible attacker to use in attempting to break the application

7.26.4 Avoiding the vulnerability or mitigating its effects

End users can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Use auxiliary variables (perhaps enclosed in variant records) to encode out-of-type information.
  
• 
  Use enumeration types to convey category information. Do not rely upon large ranges of integers, with distinguished values having special meanings.
  
• 
  Use named constants to make it easier to change distinguished values.
  
•