ERR03-A. Use runtime-constraint handlers when calling functions defined by TR24731-1

TR24731-1 provides a consistent mechanism to handle constraints violations that are discerned at runtime. Most functions defined by TR24731-1 include as part of their specification a list of runtime-constraints. Library implementations must verify that the runtime-constraints for a function are not violated by the program. If a runtime-constraint is violated, the currently registered runtime-constraint handler is called.

When the handler is called, it is passed the following arguments in the following order:

1. A pointer to a character string describing the runtime-constraint violation.
2. A null pointer or a pointer to an implementation defined object.
3. If the function calling the handler has a return type declared as errno_t, the return value of the function is passed. Otherwise, a positive value of type
   errno_t is passed.

A runtime-constraint handler is registered by calling the set_constraint_handler_s() function.

The implementation has a default constraint handler that is used if no calls to the set_constraint_handler_s() function have been made. The behavior of the
default handler is implementation-defined, and it may cause the program to exit or abort.

If the handler argument to set_constraint_handler_s() is a null pointer, the implementation default handler becomes the current constraint handler.

Section 6.1.4 states:

These runtime-constraints are requirements on the program using the library.

and

The runtime-constraint handler might not return. If the handler does return, the library function whose runtime-constraint was violated shall return some indication of failure as given by the returns section in the function's specification.

These runtime constraint handlers mitigate some of the potential insecurity caused by in-band error indicators. See ERR02-A. Avoid in-band error indicators

Non-Compliant Code Example

In this non-compliant example no set_constraint_handler_s() has been called so the implementation defined default handler will be called on a run-time error. This will result in inconsistent behavior across implementations and possible termination of the program instead of a graceful exit.

errno_t function(char* dst1){
  char src1[100] = "hello";

  if (strcpy_s( dst1, sizeof(dst1), src1) != 0) {
    return -1;
  }
  /* ... */
  return 0;
}

Compliant Code Example (TR24731-1)

constraint_handler_t handle_errors() {
  /* define what to do when error occurs */
}

/*...*/

set_constraint_handler(handle_errors);

/*...*/

/* Returns zero on success */
errno_t function(char* dst1){
  char src1[100] = "hello";

  if (strcpy_s( dst1, sizeof(dst1), src1) != 0) {
    return -1;
  }
  /* ... */
  return 0;
}

Compliant Code Example (Visual Studio2008/.NET Framework 3.5)

_invalid_parameter_handler handle_errors(const wchar_t* expression,
   const wchar_t* function, 
   const wchar_t* file, 
   unsigned int line, 
   uintptr_t pReserved)
{
/*define what to do when error occurs*/
}

/*...*/

_set_invalid_parameter_handler(handle_errors)

/*...*/

errno_t function(char *dst1){
  char src1[100] = "hello";

  if (strcpy_s( dst1, sizeof(dst1), src1) != 0) {
    return -1;
  }
  /* ...  */
  return 0;
}

Risk Analysis

The TR24731-1 standard indicates that if no constraint handler is set, a default one executes when errors arise. The default handler is implementation-defined and "may cause the program to exit or abort". Therefore using constraint handlers prevents a program from immediately crashing.

Related Vulnerabilities

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

References

[[ISO/IEC TR 24731-1-2007]]
[[MSDN]] "Parameter Validation"

ERR02-A. Avoid in-band error indicators      13. Error Handling (ERR)       ERR04-A. Understand the differences between exit(), _exit(), and abort()