In the C Rules Repository I find rules for Vulnerability Detection. What I don’t understand is how they work. Some examples:
How does the rule ‘“memset” should not be used to delete sensitive data’, decide if information is sensitive? Do I need to flag it somehow or does it fire just on every memset or on keywords like password and token? The latter one would mean I need a naming convention that disallows naming a password variable pwd for example.
“XML parsers should not be vulnerable to XXE attacks” needs to know the specifics of the used library. Does the library detection just work by detecting the includes? What libraries are supported and under which circumstances?
“Server hostnames should be verified during SSL/TLS connections” and “Server certificates should be verified during SSL/TLS connections” produce the same questions. Are the supported libraries OpenSSL, botan and libcurl and nothing else?
How do the vulnerability rules work?
What do I have to do in order to support them detecting possible issues?
What should I avoid to keep the rules working?
Thanks for your questions. We are happy to help and to give some context.
The CFamily analyzer uses multiple techniques to validate our rules and also detect potential vulnerabilities. While some issues can only be detected using precise, path-sensitive analysis, others can be detected using some smart analysis conducted on the abstract syntax tree (AST).
For the rule on memset (S5798), for instance, the analysis aims at checking if the call can be potentially optimized away. In that case, it will flag the call to memset as potentially dangerous if the goal is to scrub out sensitive memory. The rule does not and to some extent cannot decide whether the data that a user wishes to zero out is sensitive. Please mark findings in SonarQube or SonarCloud for which it is safe to use memset as Resolve as fixed, or use memset_s if it is not. Keep in mind that static program analysis is an undecidable problem in general.
Some rules like the one on XXE attacks (S2755) use a precise analysis that inspects the program path by path. This particular analysis models the Xerces library (or to be more precise the parts that are relevant to detect potential issues) in order to adequately detect potential issues on the given target code. Similarly for the rule(s) on SSL/TLS connections. These libraries are also modeled to the extent that is required to detect corresponding issues.
Does that answer your questions? Let me know, if not.
If we are doing a good job, you do not need to apply special measures to make your code particularly analyzable. However, writing clean code (cf. What is Clean Code?) and idiomatic C or C++ definitely helps fellow developers and may avoid tricky corner cases that our analyzer would have difficulties detecting, due to decidability. Other than that, we highly appreciate it if you report false positive (or negative) findings using the community forum, such that we can continuously improve our analyzers.