After a CVE on open source software has been discovered and a fix has been released, a fruitful practice for security researchers is to go deep into the nature of the CVE and the fix. 

In addition to curiosity, this good practice helps professionals and researchers extend their knowledge and improve their understanding of security vulnerabilities. 

Being an engineer at Checkmarx, the main tool that comes to mind to deep dive into the nature of vulnerabilities is the Checkmarx Static Application Security Testing (SAST) engine. 

This blog post will go into details about the nature of two separate vulnerabilities, CVE-2022-3602 and CVE-2022-3786, which hit the news at the beginning of November impacting a very well-known and largely adopted open source software package, OpenSSL. We will explore their fix and how Checkmarx solutions can detect such vulnerable code and support developers with remediation.  

CVE-2022-3602 and CVE-2022-3786 

The official page from OpenSSL, dealing with November’s CVEs (CVE-2022-3786 and CVE-2022-3602) can be found here. 

The two vulnerabilities affect OpenSSL up to version 3.0.6, and they involve a file named punycode.c, which is one of the files that manage the parsing of specific encoding of domain names (known as punycode). 

With both vulnerabilities, “A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking”, and they have been classified as CWE-120 by NIST, as a “Classical Buffer Overflow.” 

Buffer overflows

Generally, in C language, it is important to securely manage memory buffers to avoid any value written in a buffer from being reused elsewhere in the code and being interpreted with unexpected semantics. It’s worth noting that in C, buffers include strings too! 

Traditionally, strings are represented as a region of memory containing data terminated with a NULL character. Different string handling methods may rely on this NULL character to determine the length of the string. If a buffer that does not contain a NULL terminator is passed to one of these functions, the function will read past the end of the buffer or will lead to unexpected behaviors, such as buffer overflows. 

Let’s go through some technical details on the nature of the two OpenSSL vulnerabilities. 

CVE-2022-3602 

It is a buffer overflow related to the function ossl_punycode_decode, where there is a check on the size of a buffer for larger-than (>) values but omits the equals-to (=) values out of any check, as seen below. 

The red highlight is the old version of the ossl_punycode_decode source code (OpenSSL 3.0.6), while the green one is the fixed version (OpenSSL 3.0.7). 

The check at line 184 was leaving the case “=” unchecked, letting data with the same size of max_out variable to reach the next lines in the program and enter the further part of the function. 

The fix addresses such a case, by adding the “=” case to the ones that must be excluded with return 0. 

According to this evidence, the buffer overflow is due to the absence of a proper check against the size of a buffer which EQUALS the maximum, while there are cases defined to address sizes that are larger (return 0) and smaller (just continue). 

Technically, this case is similar to off-by-one vulnerabilities, where an application does not properly manage buffers which are exactly the size of the maximum expected, due to several assumptions on the data structures received in input. 

Various assumptions can be done on data structures received in input, and they all deal about trusting the source of such input, in term of its content, its format, and its size; to build secure code, assumptions should be avoided. 

Instead, sanitization and validation techniques should be implemented in the code: sanitization is the activity of removing extraneous data from a given input, transforming it into harmless data, compatible with business rules and security policies (e.g. removing special characters from a string before using it as a parameter in SQL); validation, on the other hand, is the activity of checking the content of a given input and rejecting any input that does not comply with application’s constraints (e.g. rejecting any string that is greater or equals to the size of a memory buffer). 

Checkmarx’s Codebashing training platform offers several lessons to teach developers how to write secure code in C, addressing proper methods to manage structures such as buffers, stacks, and heaps, which can help developers avoid introducing vulnerabilities in their code, such as CVE-2022-3602. 

For example, regarding off-by-one, Checkmarx’s gamified platform shows the student a part of vulnerable code and its side effects at runtime, both in memory and interactively: 

In this scenario, the vulnerable code is robust when the buffer is larger or smaller than the expected size; however, it is not safe when exactly 8 characters are entered. 

CVE-2022-3786 

t is a buffer overflow related to the function ossl_punycode_decode, which manages several cases of writing characters (chars) to a buffer, before using that buffer in further contexts, such as reading it as a string. 

OpenSSL 3.0.7 introduced the use of this PUSHC macro, to manage operations in buffers properly, as stacks: 

The macro is then used in place of old 3.0.6 “memcpy” functions, everywhere it is needed. 

Similar to the previous example above, the red highlight is the old version of the ossl_punycode_decode source code (OpenSSL 3.0.6), while the green one is the fixed version (OpenSSL 3.0.7). 

The change on line 301 manages the absence of the NULL character, which may lead to unexpected behaviors if the just populated stack is used in other contexts (e.g., as a string!). 

Checkmarx SAST has a specific query for C/C++ Language which is called “Improper_Null_Termination.” It is in the category of Buffer Overflows, and it has High severity. 

Its goal is to identify buffers that have not been properly terminated by NULL characters. 

By scanning OpenSSL 3.0.6 with Checkmarx SAST, the punycode file appears in two results related to line 276 and 297 for Improper Null Termination query: 

The description of the finding at line 276 states: 

“The buffer outptr in openssl-openssl-3.0.6cryptopunycode.c at line 276 does not have a null terminator. Any subsequent operations on this buffer that treat it as a null-terminated string will result in unexpected or dangerous behavior.” 

By scanning OpenSSL 3.0.7 with the same preset, the two vulnerabilities appear as fixed: 

Conclusion

Any application may present vulnerabilities due to the large size of applications, inheritances from older versions, mistakes, or errors. As evident with the recently identified OpenSSL vulnerabilities, even well-maintained and mature applications may present vulnerabilities that could be all but impossible to be identified by a manual review of the code. 

At the same time, the security awareness of developers is a key factor to produce and maintain secure code. 

Checkmarx SAST and Checkmarx Codebashing can help in raising the bar of security in your company and in your developers and security champions. Both solutions are fully integrated into our Checkmarx One Application Security Platform. 

Learn More

To learn more or see for yourself, request a demo today! 

Organizations looking to adopt or improve an AppSec program often encounter challenges when trying to harmonize among various security scans and tools. And collecting, collating, and filtering security scan data is only half the battle—we also need to empower development and DevOps teams to take action to mitigate found vulnerabilities and risks in order to develop an effective security strategy. 

Often, information security and development teams have differing objectives; InfoSec teams aim to implement security controls to minimize risk as much as possible, whereas dev teams try to address security requirements with the lowest impact and effort without jeopardizing application stability or new features. And unless vulnerabilities are identified early in the development process, implementing necessary security controls can result in significant delays, frustrating both teams in the process. 

With Checkmarx One, organizations can reduce friction among AppSec and development teams by simplifying, optimizing, and expediting the identification and remediation of security vulnerabilities, all within a single tool earlier in the software development process. 

Checkmarx One includes multiple scan engines, including (Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Infrastructure-as-Code (IaC) security, all on a single platform with easy-to-read, correlated scan reports. 

SCA Knowledge Center 

Checkmarx One SCA engine indexes and analyzes software components bound to the scanned application through imported packages and/or dependencies. Third-party software can introduce additional unexpected vulnerabilities in an application and our SCA scan engine can help developers and information security teams understand and remediate those vulnerabilities. 

When an application is scanned, Checkmarx One SCA identifies packages involved in the dependency tree of the application, together with Supply Chain Security (SCS) risks, licensing information, known vulnerabilities, and packages linked to software containers. 

The main result for a given package, found during a Checkmarx One SCA engine’s scan, allows the user to collect all the relevant data to triage the finding and transform this information into a remediation action: 

Checkmarx SCA suggests the newest version of the component, based on all the information collected during the scan and the history of releases of a given package, in terms of security fixes and updates. 

Upgrading to the latest version of a component would need a proper evaluation of impacts not only on application security, but also the functional capabilities within the application; thus, the process of decision may cause friction among Development and InfoSec teams. 

As in this example, upgrading a component three major versions ahead may disrupt features, result in incompatibilities, or require additional development effort. 

Usually, an application security program is adapted to the risk of the application that needs mitigation, and there are some opportunities for negotiation to balance the needs of InfoSec with those of Developers: mitigate risks as much as possible, without breaking any existing application functionality. 

Checkmarx’s AppSec Knowledge Center assists in this goal by identifying and illustrating the history of releases of a given package, to help in that negotiation: 

By browsing the change list, the user can identify the most suitable upgrade, allowing organizations to lower risk while minimizing impact. 

In the example above, there is a version of the mysql-connector-java package (5.1.49) which is suitable for lowering the risk from High to Medium while not changing the major version of the package: 

As a side note, the version slider can also help identify less effective upgrades; for example, a higher major version is not always the most suitable choice (version 8.0.12 still has high vulnerabilities): 

With the support of Checkmarx One’s SCA technology, InfoSec teams and Developers can implement a prioritized remediation program addressing even the most complicate dependency structure, with the opportunity of drilling down each specific dependency and version upgrade recommendation. 

Managing multiple vulnerabilities 

Checkmarx One offers multiple engines, including Software Component Analysis, API Security, IaC Security, and the well-known SAST engine. 

Checkmarx One SAST has the task of executing the source code analysis for an application, supporting a large number of programming languages and frameworks. 

Generally, security vulnerabilities are detected using specific patterns and the evidence of each result is shown through an attack vector or a data flow. 

For example, injection vulnerabilities (such as XSS, SQL Injection) are demonstrated if a dataflow is detected from an untrusted source of data (e.g., user-controllable input), known as a source, and a sink, which is a location in the code where the untrusted data “flows” to a destination point of impact (e.g., a Database operation, an HTML response), without a sanitizer (e.g., parametric queries, proper encoding). 

Due to the nature of applications and their modularity, often several attack vectors have data flows in common: the same user-controllable source could influence several sinks, or a single sink is the destination of multiple user-controllable sources. 

Checkmarx One is often able to identify the Best Fix Location (BFL) and can highlight the specific line number within the specific file where the vulnerability can be addressed, saving both InfoSec teams and developers time and effort. 

To help prioritize findings for both InfoSec and development teams, multiple filtering techniques can be leveraged for Checkmarx One SAST results, allowing teams to apply primary and secondary groupings. 

Filters can be applied by: 

• Grouping all the languages involved 
• Grouping results by severity 
• Grouping results by Sink File (destination of attack vectors) 

Leveraging filtering, InfoSec and development teams can identify pertinent security scan results and properly prioritize mitigation actions. 

For example, in the figure below, we can see the files that are the most impacted by security vulnerabilities, since the files represent multiple attack vectors colliding in the same sink: analyzing these files will help developers resolve a larger number of results in one single analysis: 

In contrast, we can identify which files are most exposed to user-controllable input by grouping per source file: 

In the case of a relevant number of results, it is a major priority for InfoSec teams to lower the effort needed to analyze results. On the other hand, it is a major priority for development teams to address the most punctual (and eventually less numerous) locations in the code to apply the proper mitigations. 

This is the key to a successful AppSec Program. 

Evaluating the security posture 

In general, applications are made up of a number of modules, which may be tied in a single repository or widespread in multiple repositories. Furthermore, application modules may be owned by different development teams. 

An organization can be very diversified and one of the objectives of InfoSec teams is to evaluate the security posture of their assets from perspectives that can differ much from the technical organization of modules and repositories, as seen by developers. 

Checkmarx One offers the opportunity to group different modules of applications (or different applications) under the same entity, to aggregate results, and to have a perception of the general security posture of a given group of assets. 

Every AppSec program has an associated risk level for each asset involved; therefore, it is extremely important to reflect the same logic on the unified security tool. 

Within Checkmarx One, the user can create an application group, which aggregates scans from different projects, optionally giving grouping criteria through tags, and giving a “Criticality Level” to the group itself, as illustrated in the figure below: 

By filtering projects by tag, projects can be assigned to an application group, automatically. 

From a list of projects to application-wise security posture in just a few clicks! 

Scanned projects correspond to specific repositories, modules, languages, microservices, or monolithic applications: 

Grouping them by a given criteria will show the larger picture of the logical entity “Front End Apps:” 

InfoSec team can then see the real security posture of a group of assets: 

Being able to aggregate results across different sets of findings will help InfoSec teams evaluate the overall security posture of a multipart application, drive decisions toward more focused mitigating actions, and assist developers with more accurate employment of their efforts. 

Conclusion

Checkmarx One is a powerful platform, designed to execute a large number of scan operations on applications in a very short time frame. The results can be managed and integrated with multiple issue-tracking environments.  And because we aggregate results from multiple scan engines within a single platform, we improve developer productivity, foster better collaboration among InfoSec and development teams, and help organizations improve their overall security posture through targeted guidance and prioritization. 

Harmonizing the visibility of all the actors involved will help transform results from a security platform into a prioritized, feasible, accurate, and effective mitigation program. 

To see for yourself, sign up for a free trial or reach out to a sales team today!