Taint checking? This isn’t a trap, I promise. It sounds vulgar, but its etymology is perfectly reasonable, stemming from the notion that data that has been “tainted” by a malicious user (and could be used to breach your system) is a dangerous vulnerability in code and needs to be found and eliminated.
Wikipedia actually has a pretty clear definition of taint checking:
“Taint checks highlight specific security risks primarily associated with web sites which are attacked using techniques such as SQL injection or buffer overflow attack approaches.”
I’m assuming that those in the security auditing world of the 2016 cyber-security landscape have likely moved past and become immune to the chuckles of this unfortunately-named technical term. But for the rest of us, I thought I might provide a clear overview, so you can start addressing this extremely-important concept with confidence in the boardroom. Ready?
Taint Sources and a Program’s Attack Surface
So let’s go back to that definition from wikipedia. It’s not bad, although its focus on websites is a little misleading, given that most embedded devices are now connected to the internet, so the security risks are much broader in scope.
When security analysts determine the safety of a given system, they look at a program’s attack surface, which is defined by the places in the program that are exposed to an attacker. When we look at tainted data, this is essentially what we’re talking about — sources of taint correspond closely to the program’s attack surface. Taint sources are locations in the program where data is being read from a potentially risky source, and include things like environment variables, data, files, file metadata (such as a file’s permissions or data stamps), the network or information bus, the system clock, or network services (such as the results of a DNS query).
An attacker can use these unverified channels to trigger security vulnerabilities or cause programs to crash. Many different types of issues can be triggered by tainted data. In addition to the few that Wikipedia mentioned above, these issues include command injections, cross-site scripting, arithmetic overflow, or path traversal.
So how does this relate back to static analysis and CodeSonar, our commercially available SAST tool?
Taint Analysis in CodeSonar
It comes back to taint analysis, which is an extremely useful technique to help anyone performing a security audit better understand a program’s attack surface(s). Taint analysis is performed automatically by CodeSonar as part of its regular set of analyses, and presented visually within the CodeSonar interface to demonstrate how risky data can flow from one part of a program to another.
Since taint can flow through the program in unexpected ways, it’s important to understand these channels fully. In CodeSonar, the flow of tainted data can be visualized and program elements involved in flows can be overlaid on top of the regular code view. This visualization helps developers understand the risks of their code and aids them in deciding how best to change the code to shut down the vulnerability. It helps security auditors understand at a high level how taint is flowing through the code, in order to understand the attack surface.Reducing Risk
The bottom line is that taint analysis is an effective method to reduce risk, by helping you eliminate exploitable attack surfaces. So it’s imperative that we get comfortable talking about it, even if it has a less-than-ideal name. To learn more about taint analysis in detail, explore the links below.
