0 Replies Latest reply: Apr 6, 2012 10:12 AM by Mike Kietzman RSS

Function model example for Tainted Scalar

Currently Being Moderated
When certain units of data such as scalars (integers etc) are passed to a function as an argument or used in an array/pointer index; it may be necessary to check the scalar bounds (upper or lower) of that scalar to make sure that the value is not undesired or “tainted”. Such tainted values may cause buffer overflows and other problems related to security.


While Coverity static analysis has a very low false positive rate, incomplete information and certain analysis properties may cause a defect to be reported incorrectly. This can happen if certain functions are encountered that have no implementation or were not analyzed by static analysis, global data dependencies etc. Below is an example of such a false positive for TAINTED_SCALAR where the bounds were checked in a function that was not analyzed by static analysis. Here on line 3235 moduleHandle is assigned a value that is ultimately used in CodeModuleManager_getModuleSize() on line 3241. The variable ‘moduleHandle’ was checked in CodeModuleManager_isValidHandle() on line 3237 however this was not analyzed by static analysis which resulted in TAINTED_SCALAR inaccurately reporting the defect.


3232    VMReturn VMASMCALL
( VMThread *env )
3233    {
3234        int parm = 0;


Event tainted_data_return: Function "VMgetParm_uint(VMThread *, long)"
returns TAINTED data [model]
Event var_assign: Variable "moduleHandle" TAINTED from assignment to
tainted return value of "VMgetParm_uint(VMThread *, long)"
Also see events: [var_assign][tainted_data]


3235        int moduleHandle = get_int();


At conditional (1): "CodeModuleManager_isValidHandle(int, bool) == 0"
taking false path


3237        if( !CodeModuleManager_isValidHandle( moduleHandle, false )
) {
3238            return VM_ILLEGAL_ARGUMENT;
3239        }


Event tainted_data: TAINTED variable "moduleHandle" was passed to a
tainted sink. [model]
Also see events: [tainted_data_return][var_assign]


3241        return_int( CodeModuleManager_getModuleSize( moduleHandle )
3242        return VM_OK;
3243    }


The best way to overcome this defect is to model CodeModuleManager_isValidHandle() so that static analysis can be aware in the next analysis run that the value returning from this function is sanitized and can be properly used in CodeModuleManager_getModuleSize() (line 3241).


The following is an example of how CodeModuleManager_getModuleSize() can be modeled. In a future analysis run, this model will override the function in the actual source thereby static analysising the defect from being reported.


bool CodeModuleManager_isValidHandle(int handle, bool b) {
  int valid_handle;
  if (valid_handle) {
    return true;
  } else {
    return false;


Above, the uninitialized variable ‘valid_handle’ is used to indicate the unknown as this its value is determined during the analysis. Here when the analysis is run, it will explore both conditions and determines that if there is a tainted value (handle) passed to CodeModuleManager_isValidHandle, that value can be sanitized by an upper/lower bounds check (simulated in the analysis using the __coverity_tainted_data_sanitize__() primitive function) and there will be no defect reported since the check is in place. More information on primitive functions can be found in the Checker Reference pdf accompanied with the static analysis installation.


It is necessary that when a function model is written, that it be placed in a file that has the extension of the type of source that reported the defect. In this case, the source is C and not C++ so therefore it will need to be placed in a file with an extension .c. This is necessary as the cov-make-library utility that is used to compile the function model recognizes the model file as being C or C++ by its extension.
When the function model is compiled, its model is kept in a file called user_models.xmldb in the config directory of the static analysis installation. This can be changed however by providing a destination output modelfile using the –of option to cov-make-library. When the analysis is run,  the destination modelfile is specified to the cov-analyze command using the –user-model-file option. If the model was exported to the default user_models.xmldb file, no special option need be provided to cov-analyze as the default user_models.xmldb will be read during the analysis.


More Like This

  • Retrieving data ...