STR34-C. Cast characters to unsigned types before converting to larger integer sizes

Signed character data stored must be converted to an unsigned type before being assigned or converted to a larger signed type. Because compilers have the latitude to define char to have the same range, representation, and behavior as either signed char or unsigned char, this rule should be applied to both signed char and (plain) char characters.

This rule is only applicable in cases where the character data may contain values that can be interpreted as negative values. For example, if the char type is represented by a two-bits complement 8-bit value, any character value greater than +127 would be interpreted as a negative value.

Non-Compliant Code Example

This non-compliant code example is taken from an actual vulnerability in bash versions 1.14.6 and earlier that resulted in the release of CERT Advisory CA-1996-22. This vulnerability resulted from the sign extension of character data referenced by the string pointer in the yy_string_get() function in the parse.y module of the bash source code:

static int yy_string_get() {
  register char *string;
  register int c;

  string = bash_input.location.string;
  c = EOF;

  /* If the string doesn't exist, or is empty, EOF found. */
  if (string && *string) {
      c = *string++;
      bash_input.location.string = string;
    }
  return (c);
}

The string variable is used to traverse the character string containing the command line to be parsed. As characters are retrieved from this pointer, they are stored in a variable of type int. For compilers in which the char type defaults to signed char, this value is sign-extended when assigned to the int variable. For character code 255 decimal (-1 in two's complement form), this sign extension results in the value -1 being assigned to the integer, which is indistinguishable from the EOF integer constant expression.

This problem was repaired by explicitly declaring the string variable as unsigned char.

static int yy_string_get() {
  register unsigned char *string;
  register int c;

  string = bash_input.location.string;
  c = EOF;

  /* If the string doesn't exist, or is empty, EOF found. */
  if (string && *string) {
      c = *string++;
      bash_input.location.string = string;
    }
  return (c);
}

This solution, however, is in violation of STR07-A. Use plain char for character data.

Compliant Solution

In this compliant solution, the result of the expression *string++ is cast to (unsigned char) before assigning it to the int variable c.

static int yy_string_get() {
  register char *string;
  register int c;

  string = bash_input.location.string;
  c = EOF;

  /* If the string doesn't exist, or is empty, EOF found. */
  if (string && *string) {
      c = (unsigned char)*string++;  /* cast to unsigned type */
      bash_input.location.string = string;
    }
  return (c);
}

Risk Assessment

This is a subtle error that results in a disturbingly broad range of potentially severe vulnerabilities.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[ISO/IEC 9899-1999]] Section 6.2.5, "Types"
[[MISRA 04]] Rule 6.1, "The plain char type shall be used only for the storage and use of character values."