SV.TAINTED.CALL.INDEX_ACCESS
Unvalidated input used in array indexing by function call
Whenever input is accepted from the user or the outside environment, it should be validated for type, length, format, and range before it is used. Until properly validated, the data is said to be tainted. The SV.TAINTED family of checkers looks for the use of tainted data in code.
The SV.TAINTED.CALL.INDEX_ACCESS checker flags code that passes tainted data to functions that will use it to access an array.
Vulnerability and risk
When input to code isn't validated properly, an attacker can craft the input in a form that isn't expected by the application. The receipt of unintended input can result in altered control flow, arbitrary resource control, and arbitrary code execution. With this sort of opportunity, an attacker could
- provide unexpected values and cause a program crash
- cause excessive resource consumption
- read confidential data
- use malicious input to modify data or alter control flow
- execute arbitrary commands
Using values supplied by the user as an array index can lead to index out-of-bounds vulnerabilities. If the vulnerable function allows for the reading from or writing to arbitrary memory, it could lead to application instability or, with a carefully constructed attack, data disclosure vulnerabilities or code injection.
Mitigation and prevention
To avoid tainted input errors:
- understand all the potential areas in which untrusted inputs could enter your software: parameters or arguments, cookies, input read from the network, environment variables, reverse DNS lookups, query results, filenames, databases, and any external systems
- use a whitelist or 'known good' policy for inputs, rather than relying only on a blacklist or 'known bad' strategy
- make sure all relevant properties of the input are validated, including length, type of input, ranges, missing or extra inputs, syntax, and consistency
- if there are security checks on the client side of an applications, make sure they're duplicated on the server side
- if the application combines inputs from multiple sources, perform the validation after the sources have been combined
Vulnerable code example
void setSize(int index, int size) {
sizes[index] = size;
}
void getSize() {
unsigned num, size;
int i;
scanf("%u %u", &num, &size);
setSize(num, size);
}
Klocwork produces an issue report at line 9 indicating that unvalidated integer 'num' received through a call to 'scanf' at line 8 can be used to access an array through a call to 'setSize' at line 9. In this case, the SV.TAINTED.CALL.INDEX_ACCESS checker has found code that passes potentially tainted data to a function that will use it as an array index.
Fixed code example
void setSize(int index, int size) {
sizes[index] = size;
}
void getSize() {
unsigned num, size;
int i;
scanf("%u %u", &num, &size); // validate that num is a valid index for sizes
if (num < num_sizes)
{
setSize(num, size);
}
}
The Klocwork checker no longer produces an issue report because the integer value 'num' is validated before it's passed to the 'setSize' function and used as an array index.
Related checkers
External guidance
- CERT ARR00-C: Understand how arrays work
- CERT CTR50-CPP: Guarantee that container indices and iterators are within the valid range
- CERT INT04-C: Enforce limits on integer values originating from tainted sources
- CWE-20: Improper Input Validation
- CWE-129: Improper Validation of Array Index
- CWE-788: Access of Memory Location After End of Buffer
- CWE-805: Buffer Access with Incorrect Length Value
- CWE-896: None
- OWASP A3:2021 Injection
- STIG-ID: APP3510 Insufficient input validation
Security training
Application security training materials provided by Secure Code Warrior.