Zero Day Threat is a term for development vulnerabilities that have not yet been discovered. Such vulnerabilities can be exploited by cybercriminals, which will ultimately affect the company's reputation. The developers are faced with the task of minimizing the number of defects in the code that could cause such a vulnerability. One of the tools to help identify security flaws is the PVS-Studio static code analyzer for C, C ++, C #, Java.
Zero day threat
Zero-day threat is a term that identifies gaps and vulnerabilities that were allowed by developers, but have not yet been discovered. Until the vulnerability is fixed, it can be used to access networks, remotely control a computer, manipulate data, etc. This name of the term has been established because the developers do not have a day to fix the defect, since no one knows about it yet. At one time, such large companies and software such as Adobe , Windows , Tor browser, and many others suffered from such vulnerabilities.
Some organizations were lucky, their vulnerability was found by people who were not going to use it, and they simply provided information about the problem. For example, this was with MacOS . Or there was an update that, in addition to new features, also accidentally fixed the zero-day threat.
However, there were other situations. For example, Google Chrome at one time urgently had to fix a vulnerability that allowed an attacker to remotely execute arbitrary code on a victim’s device.
The problem with this threat is that it is impossible to defend against it 100%, since it is difficult to defend yourself against what you do not yet know. However, there are ways to reduce the likelihood of such a threat in your project, and we will discuss them later, but to start with a little theory.
Static analysis
Static code analysis is the process of checking the program code by the analyzer without starting the program itself. Static analysis can be considered as an automated code review process. In some cases, the effectiveness of static analysis is superior to code review, but it cannot be considered as a complete alternative to code review by several programmers. Below I tried to briefly outline the pros and cons of code review and static code analysis relative to each other.
| Code Review
| Static analysis
|
|---|---|
| The ability to identify not only simple, but also high-level errors
| You can find errors without even knowing about such a pattern of defects or vulnerabilities
|
| The architecture of the application improves and a unified coding style is developed.
| You may find errors that are difficult to search during code review (for example, typos)
|
| High price
| Lower price than code review
|
| It takes a lot of time from programmers. It is necessary to take breaks, as attention is quickly dulled
| Inevitable false positives and the need to tune the analyzer
|
CVE and CWE
Common Vulnerabilities and Exposures (CVE) is a database of software errors that can be used by cybercriminals. CVE was created to streamline known software defects. Most information security tools used their own databases and names, and in order to eliminate this chaos and add compatibility with various tools, MITER in 1999 created CVE. However, CVE was not enough to evaluate code security. This requires something more precise, with a detailed description of the problems and less crude than she is. Therefore, the Common Weakness Enumeration (CWE) base was created that meets these requirements. If the error is on the CWE list, then it is likely that it will lead to a vulnerability that could be exploited by the attacker and get into the CVE list. For clarity, you can look at the Euler diagram below.
Some static analyzers can tell the developer that, for example, the project uses the library in which the vulnerability is found. This allows you to select a newer version of the library in which the vulnerability has already been fixed, and reduce the likelihood of problems with threats arising from someone else's code.
With the advent of the development of CVE and CWE lists, many information security tools have taken care of their support, including static analyzers. Such analyzers can be regarded as a SAST solution. SAST (Static Application Security Testing) allows developers to find vulnerabilities in the application source code already in the early stages of the software development life cycle.
Using SAST in development is another option to minimize the likelihood of a zero-day threat. The analyzer, classifying its errors according to the CWE, can tell where a possible vulnerability is hiding. And by correcting these errors, the developer makes his application more reliable and reduces the likelihood of a 0-day threat.
There are various tools for static security testing. To demonstrate the capabilities in dealing with vulnerabilities, let us dwell on the PVS-Studio tool. Warnings from this analyzer can be classified as CWE. Let's look at a few examples.
Warning PVS-Studio: CWE-561 : Dead Code ( V3021 ).
public string EncodeImage(....) { if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("inputPath"); } if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("outputPath"); } .... }
This code inadvertently made a typo. In two if conditions, the same variable is checked. Judging by the generated exception, in the second condition the variable outputPath should be checked. As a result, part of the code is unreachable.
Such errors look harmless at first glance. However, this impression can be very misleading. Consider a very simple and, at first glance, also harmless error related to duplication of the goto operator.
At one time, this error caused a vulnerability in the iOS operating system.
Vulnerability Description CVE-2014-1266 : The SSLVerifySignedServerKeyExchange function in libsecurity_ssl / lib / sslKeyExchange.c in the Secure Transport feature in the Data Security component in Apple iOS 6.x before 6.1.6 and 7.x before 7.0.6, Apple TV 6.x before 6.0.2, and Apple OS X 10.9.x before 10.9.2 does not check the signature in a TLS Server Key Exchange message, which allows man-in-the-middle attackers to spoof SSL servers by using an arbitrary private key for the signing step or omitting the signing step.
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; .... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; .... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }
Due to the double goto , a situation with unreachable code also arises. Regardless of the conditions, the second goto statement will be executed in the if statements. This leads to the fact that verification of the signature does not occur. The function returns 0, which means that everything is fine with the signature, and then the program receives the key from the server, even if there are problems with the signature. This key is needed to encrypt data during transmission.
The consequences of such a simple mistake were very serious. Therefore, it makes no sense to argue how dangerous this or that error is classified as CWE. It just needs to be fixed, thereby making the code more secure.
By the way, the described error could easily be detected by the PVS-Studio analyzer. He would give two CWE warnings here right away:
Let's look at another example. Back in 2012, it became known about the security problem in MySQL, in which an attacker could enter the MySQL database. I will provide a snippet of code that served as the reason for this.
CVE-2012-2122 Description : sql / password.c in Oracle MySQL 5.1.x before 5.1.63, 5.5.x before 5.5.24, and 5.6.x before 5.6.6, and MariaDB 5.1.x before 5.1.62, 5.2.x before 5.2.12, 5.3.x before 5.3.6, and 5.5.x before 5.5.23, when running in certain environments with certain implementations of the memcmp function, allows remote attackers to bypass authentication by repeatedly authenticating with the same incorrect password, which eventually causes a token comparison to succeed due to an improperly-checked return value.
typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
The return type of the memcmp function is int , and the return type of the check_scramble function is my_bool , in fact, char . As a result, an int is cast to a char , at which the most significant bits are discarded. This led to the fact that in about 1 case out of 256, it was possible to connect with any password, knowing the username.
Again, this CWE error could be neutralized and prevented from turning into a CVE even at the stage of writing the code. For example, the PVS-Studio static analyzer generates the following warning: CWE-197 ( V642 ): Numeric Truncation Error.
In continuation of this topic, I propose to look at the article " How can PVS-Studio help in searching for vulnerabilities? "
Conclusion
0-day vulnerabilities - a thing from which there is no guaranteed protection. But the likelihood of their occurrence can be significantly reduced. For this, specialized SAST solutions such as PVS-Studio can be used. If your project detects errors that can be classified as CWE, then you should pay attention to them and fix them. Despite the fact that only a small amount of CWE will fill up the CVE list by eliminating CWE errors, you protect your application from many potential threats.
Sitelinks
- Download and try PVS-Studio
- Technologies used in the PVS-Studio code analyzer to search for errors and potential vulnerabilities
- PVS-Studio alert classification according to Common Weakness Enumeration (CWE)
- PVS-Studio alert classification according to SEI CERT Coding Standard
If you want to share this article with an English-speaking audience, then please use the link to the translation: Ekaterina Nikiforova. PVS-Studio Static Analyzer as a Tool for Protection against Zero-Day Vulnerabilities .