Common Weakness Enumeration (CWE)

Common Weakness Enumeration (CWE) is a platform with various weaknesses

associated with computer software. CWE database lists weaknesses that are easy to find and

exploit. During code analysis, the code analyzer detected some vulnerabilities, which are

associated with specific CWEs. Below is a description of CWEs identified by the code analyzer.

CWE-120: Buffer Copy without Checking Size of Input

This CWE is associated with the vulnerability of lack of buffer overflow checks when

using “sprint.” CWE weakness 120 occurs when an input buffer is copied into an output without

verifying its size. As a result, it leads to buffer overflow. The overflow occurs when more data is

put in a buffer than it can hold. An example of this vulnerability from the code analyzer is

“VirtualGL-3.1/client/vglclient.cpp:146: [4] (buffer) sprint.” In order to fix this problem, it is

advisable to replace “sprint” with safer alternatives such as “vsnprintf”, “snprintf”, or sprint_s.”

Common consequences of this vulnerability is that it generally leads to crashes. According to

CWE-120, buffer overflow is associated with C/C++ languages, and it has a high likelihood of

exploitation. More potential mitigation includes using a different language that does not allow

the weakness to happen (Byun et al., 2020). It is also advisable to use automatic detection

mechanisms such as StackGuard and Miscrosoft Visual Studio. The code analyzer associated

CWE-120 with CWE-20 since the buffer overflow may result from improper input validation.

CWE-134: Use of Externally Controlled Format String

Another vulnerability that the code analyzer identified is potential exploitation due to

influenceable format strings when using “snprintf.” This vulnerability can be associated with

CWE-134. This vulnerability occurs when a format string comes from an external source and is
executed by a function that accepts format string as an argument. Sometimes attackers can

modify the string using an external source. As a result, it may lead to denial of service or buffer

overflow (Byun et al., 2020). Examples of this vulnerability as detected by the code analyzer

include “Profiler.cpp:19”, “glinfo_common.c:32”, and “eglxfakerut.cpp:89.” This vulnerability

can be fixed by using a constant format specification. The weakness is often associated with

C/C++ languages, and it can lead to execution of arbitrary code. CWE-134 suggests that we

should send proper number of arguments to a function during implementation stage to mitigate

this weakness.

CWE-362: Race Condition

CWE-362 is a vulnerability that can happen several processes or threads access a shared

resource without being synchronized properly. This vulnerability may lead to unexpected

behavior, such as security vulnerability, crashes, and data corruption. The vulnerability “faker-

sym.h:1047” as seen in the analyzer results often indicates a security flaw. CWE-362 explains

that if an attacker can change any aspect in the path to “access(),” they can exploit the race

condition. The languages associated with this problem include C, C++, and Java. CWE-400

further explains that race condition may cause resource exhaustion if it triggers multiple

initialization routines. Besides, CWE-59 explains that an attacker may access or overwrite

confidential data when loose permission and race condition is combined with predictable

resource names. The likelihood of exploiting this vulnerability is medium. One way to mitigate

this security flaw is to use synchronization primitives during design. Using atomic operations on

shared resources during implementation phase may also mitigate vulnerability. Another CWE

associated with security flaw is CWE-367. This occurs when the state of the resource is

influenced by an attacker between check and use.

CWE-807: Reliance on Untrusted Inputs in a Security Decision

CWE-807 is a security vulnerability that is experienced when a security decision is made

by a program based on an input that is not trusted. Therefore, an attacker can bypass the security

decision and make unauthorized access to the data. In most cases, developers assume that

environment variables and cookies cannot be modified (Wang et al., 2021). However, clients

may use customized clients to change the input. Examples of this vulnerability from the code

analyzer include “GLFrame.cpp:223”, “VGLTransReceiver.cpp:93”, and “vglclient.cpp:70.” One

of the recommendations to address this issue is to check environment variables carefully before

using them. This vulnerability is not language-specific and has a high likelihood of exploitation.

More mitigation measures are to store sensitive data in servers only during the design phase. It is

also essential to use the manual white box technique during detection as it reduces the number of

false positives.

CWE-119: Improper Restriction of Operations

Another vulnerability that was detected by the code analyzer is instance where a program

performs an operation on a memory buffer without checking its bounds. This exposes the

program to data breach since an attacker can use arbitrary memory locations to write the data,

which may lead to some issues such as security flaw, crashes, and corruption of data. CWE-119

vulnerabilities can be prevented by checking bounds of all operations on the memory buffer. The

check will help ensure they do not write outside the buffer bound. Sometimes, the use of memory

sanitizer helps check the vulnerability by inserting an additional code to the program. Some of

the codes that code analyzer found to have CWE-119 vulnerabilities include “vglclient.cpp:67”
and “vglclient.cpp:139.” To address these issues, it is advisable to use function that limit length

and ensuring that the size if larger than the maximum possible length. Related to the

vulnerability involving bounds is CWE-190. The code analyzer also found integer overflow

vulnerability, which is experienced when an arithmetic operation is performed, resulting to an

outcome that is too small or too large to be stored. Some of the remedies for this issue include

using correct integer type that is within the range that the output can accommodate (Kaushik &

Srivastava, 2020). It is confirmed that the use of automated static analysis is effective in

detecting this vulnerability as it reduces the number of false positives. It is also advisable to

define all protocols to identify behaviors that are out-of-bound.

CWE-126: Buffer Over-read

One of the vulnerabilities that was rampant in the code analyzer results is the inability to

handle strings that are not null terminated, leading to over-read. This can be associated with

CWE-126, which occurs when a program reads data from a buffer beyond its end. In such cases,

an attacker can read data from adjacent memory locations, exposing sensitive information like

passwords (Kaushik & Srivastava, 2020). Examples of codes from the analyzer results that has

this vulnerability include “fl_plastic.cxx:104”, “flstring.c:56”, and “glxvisual.cpp:118.” To

address this problem, it is essential to ensure that strings are null-terminated before performing

any operation. The vulnerability may also occur when the function fails to check the second

iterator for any possible over-read conditions. This vulnerability is often associated with C/C++

languages. To address it, on should consider using functions that checks for the 2nd iterators.
 References

Kaushik, A., & Srivastava, V. K. (2020). Threat to big data: common weakness enumerations and

vulnerabilities for hadoop framework. vol, 7, 280-286.

Byun, M., Lee, Y., & Choi, J. Y. (2020, February). Analysis of software weakness detection of

CBMC based on CWE. In 2020 22nd International Conference on Advanced

Communication Technology (ICACT) (pp. 171-175). IEEE.

Wang, T., Qin, S., & Chow, K. P. (2021, October). Towards Vulnerability Types Classification

Using Pure Self-Attention: A Common Weakness Enumeration Based Approach. In 2021

IEEE 24th International Conference on Computational Science and Engineering

(CSE) (pp. 146-153). IEEE.