PVS-Studio has always been able to detect a large number of various security defects (potential vulnerabilities) in the program code. However, historically, we positioned PVS-Studio as a tool to search for errors. We see a trend in the software development to look for vulnerabilities in the code, although it is just the same. It seems to us that it is high time to do the rebranding of our static analyzer PVS-Studio. We will start with Common Weakness Enumeration (CWE). This article provides a table that shows matches of PVS-Studio diagnostic warnings of with the classifier. The table will be gradually updated and changed, but we can already use the table to write articles about security defects detected in projects. We suppose it would attract more attention of the software security specialists.
Common Weakness Enumeration (CWE)
Let us make the terms clear first. To do this, I will quote a fragment of the FAQ from cwe.mitre.org.
A1. What is CWE? What is a "software weakness"?
Targeted at both the development community and the community of security practitioners, Common Weakness Enumeration (CWE) is a formal list or dictionary of common software weaknesses that can occur in software's architecture, design, code or implementation that can lead to exploitable security vulnerabilities. CWE was created to serve as a common language for describing software security weaknesses; serve as a standard measuring stick for software security tools targeting these weaknesses; and to provide a common baseline standard for weakness identification, mitigation, and prevention efforts.
Software weaknesses are flaws, faults, bugs, vulnerabilities, and other errors in software implementation, code, design, or architecture that if left unaddressed could result in systems and networks being vulnerable to attack. Example software weaknesses include: buffer overflows, format strings, etc.; structure and validity problems; common special element manipulations; channel and path errors; handler errors; user interface errors; pathname traversal and equivalence errors; authentication errors; resource management errors; insufficient verification of data; code evaluation and injection; and randomness and predictability.
A2. What is the difference between a software vulnerability and software weakness?
Software weaknesses are errors that can lead to software vulnerabilities. A software vulnerability, such as those enumerated on the Common Vulnerabilities and Exposures (CVE) List, is a mistake in software that can be directly used by a hacker to gain access to a system or network.
Correspondence between warnings of PVS-Studio and CWE
We want people to start seeing PVS-Studio not as just a tool to search for bugs, but as a tool that helps to eliminate vulnerabilities in the code. Of course, not every security defect listed in CWE is a vulnerability. It depends on a lot of factors if a certain flaw can be used to attack a program. That is why further on, we will write that PVS-Studio detects not just vulnerabilities, but potential vulnerabilities - it would be more correct.
So, here is the first variant of the correspondence table. As I have already said, the table will get updated in the future, but this variant already gives an overall impression of the analyzer abiliities.
| CWE | PVS-Studio | CWE Description |
| CWE-14 | V597 | Compiler Removal of Code to Clear Buffers |
| CWE-121 | V755 | Stack-based Buffer Overflow |
| CWE-122 | V755 | Heap-based Buffer Overflow |
| CWE-123 | V575 | Write-what-where Condition |
| CWE-129 | V557, V781, V3106 | Improper Validation of Array Index |
| CWE-131 | V514, V531, V568, V620, V627, V635, V641, V651, V687, V706, V727 | Incorrect Calculation of Buffer Size |
| CWE-134 | V576, V618, V3025 | Use of Externally-Controlled Format String |
| CWE-135 | V518, V635 | Incorrect Calculation of Multi-Byte String Length |
| CWE-188 | V557, V3106 | Reliance on Data/Memory Layout |
| CWE-195 | V569 | Signed to Unsigned Conversion Error |
| CWE-197 | V642 | Numeric Truncation Error |
| CWE-36 | V631, V3039 | Absolute Path Traversal |
| CWE-369 | V609, V3064 | Divide By Zero |
| CWE-401 | V701, V773 | Improper Release of Memory Before Removing Last Reference ('Memory Leak') |
| CWE-404 | V611, V773 | Improper Resource Shutdown or Release |
| CWE-415 | V586 | Double Free |
| CWE-416 | V774 | Use after free |
| CWE-457 | V573, V614, V670, V3070, V3128 | Use of Uninitialized Variable |
| CWE-462 | V766, V3058 | Duplicate Key in Associative List (Alist) |
| CWE-467 | V511, V512, V568 | Use of sizeof() on a Pointer Type |
| CWE-468 | V613, V620, V643 | Incorrect Pointer Scaling |
| CWE-476 | V522, V595, V664, V757, V769, V3019, V3042, V3080, V3095, V3105, V3125 | NULL Pointer Dereference |
| CWE-478 | V577, V719, V622, V3002 | Missing Default Case in Switch Statement |
| CWE-481 | V559, V3055 | Assigning instead of comparing |
| CWE-482 | V607 | Comparing instead of Assigning |
| CWE-483 | V640, V3043 | Incorrect Block Delimitation |
| CWE-561 | V551, V695, V734, V776, V779, V3021 | Dead Code |
| CWE-562 | V558 | Return of Stack Variable Address |
| CWE-563 | V519, V603, V751, V763, V3061, V3065, V3077, V3117 | Assignment to Variable without Use ('Unused Variable') |
| CWE-570 | V501, V547, V560, V654, V3022, V3063 | Expression is Always False |
| CWE-571 | V501, V547, V560, V617, V654, V694, V3022, V3063 | Expression is Always True |
| CWE-587 | V566 | Assignment of a Fixed Address to a Pointer |
| CWE-588 | V641 | Attempt to Access Child of a Non-structure Pointer |
| CWE-674 | V3110 | Uncontrolled Recursion |
| CWE-690 | V522, V3080 | Unchecked Return Value to NULL Pointer Dereference |
| CWE-762 | V611 | Mismatched Memory Management Routines |
| CWE-805 | V512, V594, V3106 | Buffer Access with Incorrect Length Value |
| CWE-806 | V512 | Buffer Access Using Size of Source Buffer |
| CWE-843 | V641 | Access of Resource Using Incompatible Type ('Type Confusion') |
Table N1. The first draft of the correspondence between CWE and PVS-Studio diagnostics.
Now we can write in our articles devoted to the project checks about the potential vulnerabilities as well. As this trend is becoming more common among the analyzers, we will also touch upon this topic in our articles.
Demonstration
Let us see how this table can be used in the articles. We will analyze a project and have a look at the diagnostic warnings from the point of view of the weaknesses.
Of course, not every project is worth examining in terms of vulnerabilities. So let us consider such a serious project like Apache HTTP Server.
As we check it, we see bugs crawling everywhere across the code. But wait! These are not just bugs, but security weaknesses. It sounds more serious, when we speak about safety issues, rather than about banal typos and errors.
I should say right away, that this time we are not going to analyze the whole project, because we have a task of showing how the table can be used in practice. Here are only three warnings.
Example N1.
#define myConnConfig(c) \
(SSLConnRec *)ap_get_module_config(c->conn_config, &ssl_module)
....
int ssl_callback_alpn_select(SSL *ssl,
const unsigned char **out, unsigned char *outlen,
const unsigned char *in, unsigned int inlen,
void *arg)
{
conn_rec *c = (conn_rec*)SSL_get_app_data(ssl);
SSLConnRec *sslconn = myConnConfig(c);
apr_array_header_t *client_protos;
const char *proposed;
size_t len;
int i;
/* If the connection object is not available,
* then there's nothing for us to do. */
if (c == NULL) {
return SSL_TLSEXT_ERR_OK;
}
....
}
PVS-Studio analyzer issues a warning: V595 The 'c' pointer was utilized before it was verified against nullptr. Check lines: 2340, 2348. ssl_engine_kernel.c 2340
In terms of security defects this is: CWE-476 (NULL Pointer Dereference)
The main point of this error. Let us point out two most important lines of code:
SSLConnRec *sslconn = myConnConfig(c);
if (c == NULL) {
The check (c == NULL) shows that the pointer can be NULL. However, it is already dereferenced inside the myConnConfig macro:
#define myConnConfig(c) \
(SSLConnRec *)ap_get_module_config(c->conn_config, &ssl_module)
Thus, this code is no way protected against the null pointer dereference.
Example N2.
int get_password(struct passwd_ctx *ctx)
{
char buf[MAX_STRING_LEN + 1];
....
memset(buf, '\0', sizeof(buf));
return 0;
err_too_long:
....
}
PVS-Studio analyzer issues a warning: V597 The compiler could delete the 'memset' function call, which is used to flush 'buf' buffer. The memset_s() function should be used to erase the private data. passwd_common.c 165
In terms of security defects this is: CWE-14 (Compiler Removal of Code to Clear Buffers)
The main point of this error. When compiling the code in optimized mode, the compiler will remove the call of the memset function, because from the compiler's point of view, this call is redundant. After the buffer that was created on the stack is filled with zeroes, it is not used in any way. This means that filling the buffer with zeros is a waste of time and the call of the memset function should be removed. Thus, private data will not be overwritten and will stay in the memory.
I want to note that this is not some abstract theoretically possible behavior of a compiler. Compilers really do so to speed up our programs. Details:
- Overwriting memory-why?
- V597. The compiler could delete the 'memset' function call, which is used to flush 'Foo' buffer.
Example N3
static int is_quoted_pair(const char *s)
{
int res = -1;
int c;
if (((s + 1) != NULL) && (*s == '\\')) {
c = (int) *(s + 1);
if (apr_isascii(c)) {
res = 1;
}
}
return (res);
}
PVS-Studio analyzer issues a warning: V694 The condition ((s + 1) != ((void *) 0)) is only false if there is pointer overflow which is undefined behaviour anyway. mod_mime.c 531
In terms of security defects this is: CWE-571 (Expression is Always True)
The main point of this error: the condition ((s + 1) != NULL) is always true. It may be false only in case of the pointer overflow. It causes undefined behavior, so there is no sense in speaking about this case. We may consider that the condition is always true; the analyzer warned us about it.
We are not authors of the code, so we do not know for sure, how it should be written, but most likely, in this way:
if ((*(s + 1) != '\0') && (*s == '\\')) {Conclusion
Hooray, PVS-Studio analyzer can be used to detect potential vulnerabilities in the code!
For those who are willing to investigate the analyzer abilities, we suggest trying a demo version on the project. Product page: PVS-Studio.
In case you have any technical questions or questions concerning the licensing of the product, we ask to write to us at support [@] viva64.com or use the feedback form.
No comments:
Post a Comment