Our website uses cookies to enhance your browsing experience.
Accept
to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
* By clicking this button you agree to our Privacy Policy statement

close form
Free PVS‑Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

close form
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

close form
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

close form
check circle
Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
>
PVS-Studio: searching software weakness…

PVS-Studio: searching software weaknesses

Mar 16 2017

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.

0486_CWE/image1.png

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.



Comments (0)

Next comments next comments
close comment form