Start here

Home
About Klocwork
What's new
Fixed issues
Release notes
Installation

Reference

C/C++ checkers
Java checkers
C# checkers
MISRA C 2004 checkers
MISRA C++ 2008 checkers
MISRA C 2012 checkers
MISRA C 2012 checkers with Amendment 1
Commands
Metrics
Troubleshooting
Reference

Product components

C/C++ Integration build analysis
Java Integration build analysis
Desktop analysis
Refactoring
Klocwork Static Code Analysis
Klocwork Code Review
Structure101
Tuning
Custom checkers

Coding environments

Visual Studio
Eclipse for C/C++
Eclipse for Java
IntelliJ IDEA
Other

Administration

Project configuration
Build configuration
Administration
Analysis performance
Server performance
Security/permissions
Licensing
Klocwork Static Code Analysis Web API
Klocwork Code Review Web API

Community

View help online
Visit RogueWave.com
Klocwork Support
Rogue Wave Videos

Legal

Legal information

SV.TAINTED.SECURITY_DECISION

Reliance on Untrusted Inputs in a Security Decision

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.

When security decisions such as authentication and authorization are made based on the values of tainted data, attackers can bypass the security of the software. Without sufficient encryption, integrity checking, or other mechanism, any input that originates from an outsider cannot be trusted.

SV.TAINTED.SECURITY_DECISION checker flags situations in which untrusted data is used inside a security decision. In the context of this checker, a security decision is defined as comparison with hard-coded strings.

Vulnerability and risk

Attackers can bypass the security decision to access whatever is being protected. The consequences will depend on the associated functionality, but they can range from granting additional privileges to untrusted users to bypassing important security checks. Ultimately, this weakness may lead to exposure or modification of sensitive data, system crash, or execution of arbitrary code.

Vulnerable code example

1  #include <sys/socket.h>
2  #include <netdb.h>
3  #include <stdbool.h>
4  #include <string.h>
5  #include <arpa/inet.h>
6 
7  void f(const char *ip_addr_string){
8     struct hostent *hp;struct in_addr myaddr;
9     char* tHost = "trustme.example.com";
10    myaddr.s_addr=inet_addr(ip_addr_string);
11    bool trusted = false;
12    hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET);
13     if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) { 
14         trusted = true;
15     } else {
16         trusted = false;
17     }
18 }

The following code samples use a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.

Klocwork produces an issue report at line 13 indicating that Unvalidated string hp->h_name is received from an external function through a call to gethostbyaddr at line 12 and can be used in a potential security decision through call to strncmp at line 13.

Extension

This checker can be extended through the Klocwork knowledge base. See Tuning C/C++ analysis for more information.