PVS-Studio: searching software weaknesses

Andrey Karpov
Articles: 316


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.

Picture 2

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:

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.



Use PVS-Studio to search for bugs in C, C++ and C# code

We offer you to check your project code with PVS-Studio. Just one bug found in the project will show you the benefits of the static code analysis methodology better than a dozen of the articles.

goto PVS-Studio;

Andrey Karpov
Articles: 316


Do you make errors in the code?

Check your code
with PVS-Studio

Static code analysis
for C, C++ and C#

goto PVS-Studio;