Codebashing

Llama Drama: Critical Vulnerability CVE-2024-34359 Threatening Your Software Supply Chain

Guy Nachshon — Thu, 16 May 2024 15:21:11 +0000

Key Points

The critical vulnerability CVE-2024-34359 has been discovered by retr0reg in the “llama_cpp_python” Python package.
This vulnerability allows attackers to execute arbitrary code from the misuse of the Jinja2 template engine.
Over 6k AI models om HuggingFace using llama_cpp_python and Jinja2 are vulnerable.
A fix has been issued in v0.2.72
This vulnerability underscores the importance of security in AI systems and software supply chain.

Imagine downloading a seemingly harmless AI model from a trusted platform like Hugging Face, only to discover that it has opened a backdoor for attackers to control your system. This is the potential risk posed by CVE-2024-34359. This critical vulnerability affects the popular llama_cpp_python package, which is used for integrating AI models with Python. If exploited, it could allow attackers to execute arbitrary code on your system, compromising data and operations. Over 6,000 models on Hugging Face were potentially vulnerable, highlighting the broad and severe impact this could have on businesses, developers, and users alike. This vulnerability underscores the fact that AI platforms and developers have yet to fully catch up to the challenges of supply chain security.

Understanding Jinja2 and llama_cpp_python

Jinja2: This library is a popular Python tool for template rendering, primarily used for generating HTML. Its ability to execute dynamic content makes it powerful but can pose a significant security risk if not correctly configured to restrict unsafe operations.

`llama_cpp_python`: This package integrates Python’s ease of use with C++’s performance, making it ideal for complex AI models handling large data volumes. However, its use of Jinja2 for processing model metadata without enabling necessary security safeguards exposes it to template injection attacks.

[image: jinja and llama]

What is CVE-2024-34359?

CVE-2024-34359 is a critical vulnerability stemming from the misuse of the Jinja2 template engine within the `llama_cpp_python` package. This package, designed to enhance computational efficiency by integrating Python with C++, is used in AI applications. The core issue arises from processing template data without proper security measures such as sandboxing, which Jinja2 supports but was not implemented in this instance. This oversight allows attackers to inject malicious templates that execute arbitrary code on the host system.

The Implications of an SSTI Vulnerability

The exploitation of this vulnerability can lead to unauthorized actions by attackers, including data theft, system compromise, and disruption of operations. Given the critical role of AI systems in processing sensitive and extensive datasets, the impact of such vulnerabilities can be widespread, affecting everything from individual privacy to organizational operational integrity.

The Risk Landscape in AI and Supply Chain Security

This vulnerability underscores a critical concern: the security of AI systems is deeply intertwined with the security of their supply chains. Dependencies on third-party libraries and frameworks can introduce vulnerabilities that compromise entire systems. The key risks include:

Extended Attack Surface: Integrations across systems mean that a vulnerability in one component can affect connected systems.
Data Sensitivity: AI systems often handle particularly sensitive data, making breaches severely impactful.
Third-party Risk: Dependency on external libraries or frameworks can introduce unexpected vulnerabilities if these components are not securely managed.

A Growing Concern

With over 6,000 models on the HuggingFace platform using `gguf` format with templates—thus potentially susceptible to similar vulnerabilities—the breadth of the risk is substantial. This highlights the necessity for increased vigilance and enhanced security measures across all platforms hosting or distributing AI models.

Mitigation

The vulnerability identified has been addressed in version 0.2.72 of the llama-cpp-python package, which includes a fix enhancing sandboxing and input validation measures. Organizations are advised to update to this latest version promptly to secure their systems.

Conclusion

The discovery of CVE-2024-34359 serves as a stark reminder of the vulnerabilities that can arise at the confluence of AI and supply chain security. It highlights the need for vigilant security practices throughout the lifecycle of AI systems and their components. As AI technology becomes more embedded in critical applications, ensuring these systems are built and maintained with a security-first approach is vital to safeguard against potential threats that could undermine the technology’s benefits.

Introducing AI Security Champion with Auto-remediation for SAST

Avi Hein — Sun, 05 May 2024 22:00:00 +0000

Applications have vulnerabilities. Lots of them. And there’s not enough time to fix them all. In Checkmarx’ recently released Future of Application Security report, 29% of AppSec managers reported that they knowingly released vulnerable applications in order to meet a deadline and 27% reported that the vulnerabilities would be fixed in a later release.

But what if you could get reliable guidance and a suggested fix for those vulnerabilities? You can now – using Generative AI.

We previously announced AI Guided Remediation for IaC, and now we’re happy to now introduce AI Security Champion with auto-remediation for SAST.

This solution goes beyond mere identification by offering actionable fixes alongside each finding.

These recommendations, tailored to the specific vulnerability, allow developers to:

Deepen their understanding of the issue’s nature and impact.
Navigate the remediation process with confidence, saving time and resources.
Make the fix as quickly and easily as possible.

Introducing AI Security Champion for SAST

AI Security Champion for SAST uses the power of GenAI to propose code to fix each vulnerability.

The AI Security Champion goes beyond simply identifying vulnerabilities. While guided remediation provides AI-generated assistance, suggestions, explanations, and other guidance in human-readable language, auto-remediation provides the actual code that can be used directly within the development workflow.

This empowers developers to confidently navigate the remediation process, saving valuable time and resources, enabling developers to review and then automatically implement the fix. It’s as simple as copy and paste (and soon, we will also add the ability to automatically implement it at the touch of a button)!

This integration signifies a significant advancement in the realm of application security testing. By harnessing the power of artificial intelligence, we are excited to offer a streamlined and efficient approach to vulnerability remediation, enabling organizations to achieve their security goals without compromising development velocity.

How It Works

AI Security Champion with auto-remediation is an integral part of the Checkmarx One platform, which makes it easy to adopt and implement. The new AI Security Champion function meets developers where they are – within the integrated development environments (IDE) that developers are already using.

Initial Setup

To set it up, select the “AI Security Champion” plugin from the plugins menu within Checkmarx One.

Then connect to ChatGPT.

Make AI Your Newest Security Champion

Once it’s set up, this is where to start moving forward. Everything takes place in the IDE as Checkmarx is fully integrated. Developers stay in their natural environment.

After set up, select a vulnerability from Checkmarx One results.

Select the “AI Security Champion” tab from the Checkmarx One results and click Start Remediation.

AI Security Champion shows the developer the following:

Confidence score – On a scale of 0 (low)-100 (high), indicates the degree of confidence of how exploitable the vulnerability is in the context of your code.
Explanation – An OpenAI-generated description of the vulnerability.
Proposed remediation –A customized code snippet, generated by OpenAI, that can be used to remediate the vulnerability in your code.
“Ask a question” – A further prompt to ask AI Security Champion about the vulnerability or proposed code.

How to Get Started

Checkmarx SAST users on Checkmarx One can get started straight away. Simply enable AI Security Champion.

Taking advantage of the capabilities presented by AI are just another reason to use Checkmarx One. Existing CxSAST users can work with their customer success manager to migrate to Checkmarx One.

Existing customers can contact their account manager to learn more. Everyone else, contact Checkmarx today.

The Global Codebashing AppSec Training Initiative by Checkmarx and OWASP

Guy Rotem — Thu, 18 Apr 2024 11:00:00 +0000

Professionals in any profession need to train. The more training you do, the better you’ll get. This is relevant to any profession, and Application Security (Appsec) is no exception. This is why Checkmarx and OWASP are thrilled to announce the Global Codebashing Appsec Training Initiative, which will provide all OWASP members around the world access to Codebashing – Checkmarx’ Appsec Training platform.

The importance of Appsec is very well recognized in the software and security worlds. Organizations from all verticals must secure their software applications and need to start from the first line of code, and as a part of the software development process.

It is the responsibility of all organizations – big and small, regardless of industry – to educate their staff on best practices in AppSec and cybersecurity.

Cybersecurity training is not a “one size fits all” but requires organizations to provide the right training to their employees, and the training needs to relate to the responsibilities and job functions of the specific responsibilities of the employees.It’s important to recognize that different employees require different training programs. General security awareness programs are not enough for AppSec professionals and software developers. Codebashing was built to meet AppSec professionals and developers where they are.

This joint initiative by Checkmarx and OWASP comes to play in parallel with the recent publication in the US by the National Institute of Standards and Technology (NIST), which published the updated 2.0 version of the Cybersecurity Framework (CSF 2.0), along with the NIS2 regulation (EU) that go into effect in October 2024. Both regulations rely on cybersecurity training as a condition for compliance.

Codebashing is a toolbox that allows companies to tailor, run, and manage a training program based on their specific needs and goals. It also allows developers to consume micro-content on their own timeline and at their own pace, without disrupting their workflow.

OWASP, as a community, have been leaders in the AppSec world since the beginning, and this new initiative will allow members to continue to advance their knowledge and expertise – so they can continue to be leaders for years to come.

By making AppSec training accessible, Checkmarx is truly securing the applications that are driving our world.

Thank you to Andew van der Stock, Executive Director of OWASP, and to all the people at Checkmarx who have been instrumental at making this partnership come to life!

The Buzz Around Developer Experience: Unlocking the Potential of Superior DevEx with Codebashing 2.0

Maor Sorero — Mon, 24 Jul 2023 16:01:52 +0000

Developer Experience (DevEx) is a term that is rapidly gaining traction, but what’s behind the buzz? The answer lies in the profound impact that a superior DevEx can have on software developers’ productivity, satisfaction, and proficiency in their day-to-day operations. It’s a game-changer that can revolutionize production cycles, streamline processes, accelerate development timelines, and foster innovation. As organizations strive for excellence in software development, investing in a top-notch DevEx becomes critical.

The Checkmarx Approach to Developer Experience

DevEx considers all the tools, processes, and systems developers use during software development. A well-designed DevEx translates to more efficient developers, which could even lead to expedited releases with reduced bug rates. At Checkmarx, we recognize the importance of a comprehensive, developer-oriented approach to AppSec. We aim to seamlessly blend security into the developer’s existing workflow, allowing developers to concentrate on their main goal – developing exceptional applications.

In Application Security, TRUST is not just a word; it’s a vital element. It’s the bond that aligns CISOs, AppSec teams, security champions, and developers – shaping a security program’s framework, methodology, goals, and progress. Trust emphasizes the significance of an effective DevEx program, where developers can confidently navigate the security landscape while maintaining productivity.

At Checkmarx, we believe that an effective DevEx program requires specific elements to thrive:

Improved accuracy and heightened alert fidelity: Providing developers accurate security insight is essential. By enhancing alert fidelity, organizations empower their teams to take immediate action, focusing efforts on high-impact vulnerabilities that pose the most significant risk to applications.
Knowing where to start to make the greatest impact: Knowing where to begin can be daunting, especially with countless potential vulnerabilities to address. Effective DevEx programs provide clear visibility into an application’s security posture, offering prioritization mechanisms to identify and address vulnerabilities based on severity, and potential impact. This can allow for effective resource allocation, which can maximize the impact on application security.
Seamless integration within the developers’ ecosystem: AppSec should seamlessly integrate into the developers’ existing workflow. This integration ensures that security is an intrinsic part of the development process that empowers developers to identify, and remediate, vulnerabilities in real time. Organizations that encourage secure coding practices may find they have a faster time-to-market. by embedding security checks into their ecosystems.
Giving every developer the knowledge to write secure code faster: Developer education plays a fundamental role in a successful DevEx program. Equipping developers with the knowledge and tools to write secure code can save valuable time and resources. Comprehensive security education platforms, like Codebashing, provide interactive and gamified learning experiences that proactively enable developers to address security concerns during the early stages of development.

By embracing these elements, organizations can create a strong DevEx program that nurtures collaboration, productivity, and security. Trust, accuracy, targeted prioritization, seamless integration, and developer education form the pillars of an effective DevEx strategy that enables organizations to unlock the true potential in their development teams.

The Integral Role of Security Education in Developer Experience

Security education is a fundamental component of an effective DevEx strategy. When equipped with strong security skills, developers can identify and resolve vulnerabilities during the initial stages of software development. This proactive approach can minimize potential security incidents, while also saving time and resources that can be spent fixing issues later in the development cycle.

Codebashing 2.0 is a revolutionary tool that provides developers with an interactive security education. It is designed to empower developers and give them the knowledge they need to write secure code from the first line. With tailored training paths, security champion programs, and an engaging, gamified learning environment, Codebashing has quickly become a trusted tool for developer-centric security education.

“It becomes part of everybody’s

workday, identifying potential problems before they

start — and how to avoid them,” said Stearns. “The

learning is continuous and organic, with lessons and

best practices delivered to developers right when

they are needed. That is a powerful proposition.”

Joel Godbout

Cybersecurity and Networking Manager, PCL Construction

What’s New in Codebashing 2.0?

We are excited to announce the launch of Codebashing 2.0, the next generation of our interactive secure code learning platform. Codebashing 2.0 brings a range of exciting new features and enhancements, including:

Personalized Learning Paths: To ensure relevant learning, developers can now access learning paths tailored to their specific skill level and needs.
Security Champion Program: This feature will help organizations nurture a culture of leadership and responsibility. This allows each department to have a dedicated security expert – building trust across your organization and facilitating effective communication between developers and security teams.
Engine Integrations: Codebashing can be seamlessly integrated with Checkmarx One, which allows for a familiar ecosystem for users.
Revamped UX/UI: Codebashing 2.0 offers a more intuitive, user-friendly design, making secure code learning accessible for developers of all levels.
Expanded Content: Our new library extends beyond the Open Web Application Security Project (OWASP) 2023 Top 10, covering a broader range of vulnerability classes for more comprehensive security learning.

Ready to See It in Action?

Investing in Developer Experience is no longer optional for today’s software development lifecycle. Upgrade your DevEx to empower your team with secure code skills.

To learn more about Codebashing 2.0, visit our page and schedule a demo today. Take the first step towards secure code and a better Developer Experience today.

OpenSSL CVE-2022-3786: Food for Thought on the Importance of Security Scanning

Fabrizio Bugli — Thu, 08 Dec 2022 14:12:00 +0000

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!

Apache Unomi CVE-2020-13942: RCE Vulnerabilities Discovered

Eugene Rojavski — Tue, 17 Nov 2020 09:00:14 +0000

“Apache Unomi is a Java Open Source customer data platform, a Java server designed to manage customers, leads and visitors’ data and help personalize customers experiences,” according to its website. Unomi can be used to integrate personalization and profile management within very different systems such as CMSs, CRMs, Issue Trackers, native mobile applications, etc. Unomi was announced to be a Top-Level Apache product in 2019 and is made with high scalability and ease of integration in mind.
Given that Unomi contains an abundance of data and features tight integrations with other systems, making it a highly desired target for attackers, the Checkmarx Security Research Team analyzed the platform to uncover potential security issues. The findings are detailed below.

Executive Summary: CVE-2020-13942

What We Found

Apache Unomi allowed remote attackers to send malicious requests with MVEL and OGNL expressions that could contain arbitrary classes, resulting in Remote Code Execution (RCE) with the privileges of the Unomi application. MVEL and OGNL expressions are evaluated by different classes inside different internal packages of the Unomi package, making them two separate vulnerabilities. The severity of these vulnerabilities is heightened since they can be exploited through a public endpoint, which should be kept public by design for the application to function correctly, with no authentication, and no prior knowledge on the attacker’s part.
Both vulnerabilities, designated as CVE-2020-13942, have a CVS Score of 10.0 (Critical) as they lead to complete compromise of the Unomi service’s confidentiality, integrity, and accessibility, in addition to allowing access to the underlying OS.

Details

Previous RCE Found in Unomi

Unomi offers a restricted API that allows retrieving and manipulating data, in addition to a public endpoint where applications can upload and retrieve user data. Unomi allows complex conditions in the requests to its endpoints.
Unomi conditions rely on expression languages (EL), such as OGNL or MVEL, to allow users to craft complex and granular queries. The EL-based conditions are evaluated before accessing data in the storage.
In the versions prior to 1.5.1, these expression languages were not restricted at all—leaving Unomi vulnerable to RCE via Expression Language Injection. An attacker was able to execute arbitrary code, and OS commands on the Unomi server by sending a single request. This vulnerability was classified as CVE-2020-11975 and was fixed. However, due to further investigation by the Checkmarx Security Research Team, we discovered that the fix is not sufficient and can be trivially bypassed.

Patch Not Sufficient – New Vulnerabilities Discovered

The patch for CVE-2020-11975 introduced SecureFilteringClassLoader, which checks the classes used in the expressions against an allowlist and a blocklist. The SecureFilteringClassLoader relies on the assumption that every class in both MVEL and OGNL expressions is loaded using the loadClass() method of the ClassLoader class. The SecureFilteringClassLoader overrides the ClassLoader loadClass method and introduces the allowlist and blocklist checks. This assumption happened to be incorrect. There are multiple ways of loading a class other than calling the loadClass() method, which leads to the security control bypass and leaves Unomi open to RCE.
First, the MVEL expressions in some cases use already instantiated classes, like Runtime or System, without calling loadClass(). This results in the latest version of Unomi (1.5.1) allowing the evaluation of MVEL expressions inside the condition, which contains arbitrary classes.
The following HTTP request has a condition with a parameter containing a MVEL expression (script::Runtime r = Runtime.getRuntime(); r.exec(“touch /tmp/POC”);). Unomi parses the value and executes the code after script:: as an MVEL expression. The expression in the example below creates a Runtime object and runs a “touch” OS command, which creates an empty file in /tmp directory.

Vulnerability #1

Second, there is a way to load classes inside OGNL expressions without triggering the loadClass() call. The following HTTP request gets Runtime and executes an OS command using Java reflections API.

Vulnerability #2

The payload may look scary but it’s simply Runtime r = Runtime.getRuntime(); r.exec(“touch /tmp/POC”); written using reflection API and wrapped into OGNL syntax.
Both presented approaches successfully bypass the security control introduced in version 1.5.1, making it vulnerable to RCE in two different locations.

Possible Attack Scenarios

Unomi can be integrated with various data storage and data analytics systems that usually reside in the internal network. The vulnerability is triggered through a public endpoint and allows an attacker to run OS commands on the vulnerable server. The vulnerable public endpoint makes Unomi an ideal entry point to corporate networks. Its tight integration with other services also makes it a steppingstone for further lateral movement within an internal network.

Summary of Disclosure and Events

After discovering and validating the vulnerabilities, we notified Apache of our findings and worked with them throughout the remediation process until they informed us everything was appropriately patched.
To learn more about these types of vulnerabilities, OWASP and CWE have descriptions, examples, consequences, and related controls, as shown in the following links:

Additionally, read the code, analyze the fix, and learn how to mitigate similar issues via our interactive CxCodebashing lesson here.

Timeline of Disclosure

June 24, 2020 – Vulnerability disclosed to Apache Unomi developers
August 20, 2020 – Code with the mix merged to master branch
November 13, 2020 – version 1.5.2 containing the fixed code is released
November 17, 2020 – public disclosure

Recommendations

The evaluation of user-defined expression language statements is dangerous and hard to constrain. Struts 2 is an excellent example of how hard it is to restrict dynamic OGNL expressions and avoid RCE. These attempts to impose usage restrictions from within/on the EL, rather than restricting tainted EL usage for general purposes, is an iterative approach, rather than a definitive one. Instead, a more reliable means to prevent RCE is to remove the support of arbitrary EL expressions entirely, creating a set of static expressions that rely on dynamic parameters instead.
Static Application Security Testing solutions, like CxSAST, can detect OGNL injections in source code and prevent this sort of vulnerability from making its way into production. Meanwhile, software composition analysis (SCA) solutions, such as CxSCA, will have the necessary data about the vulnerable package and will update CxSCA users as soon as the vulnerability is publicly disclosed. To learn how to mitigate similar issues, visit our CxCodebashing lesson here.

Final Words/Summary

This type of research is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among all organizations. Checkmarx is committed to analyzing open source software to help development teams build and deploy more-secure applications. Our database of open source libraries and vulnerabilities is cultivated by the Checkmarx Security Research Team, empowering CxSCA customers with risk details, remediation guidance, and exclusive vulnerabilities that go beyond the NVD.
To learn more about this type of RCE vulnerabilities, read our blog about Struts 2. For more information or to speak to a Checkmarx expert about how to detect, prioritize, and remediate open source risks in your code, contact us.

Mutation Cross-Site Scripting (mXSS) Vulnerabilities Discovered in Mozilla-Bleach

Yaniv Nizry — Wed, 08 Jul 2020 11:11:49 +0000

As part of the beta testing phase that took place earlier this year for our recently launched Software Composition Analysis solution, CxSCA, the Checkmarx Security Research Team investigated Mozilla-Bleach, finding multiple concerning security vulnerabilities. Patches were released in mid-March 2020, with Checkmarx CxSCA customers using Bleach receiving notice of the issues in advance. Given that the patches have been in-market for some time, giving Bleach users sufficient time to update their software versions, we’re now publishing the full technical report and proof-of-concept video for educational purposes.

Overview

According to documentation, “Bleach is an allowed-list-based HTML sanitizing library that escapes or strips markup and attributes and is intended for sanitizing text from untrusted sources.” In simpler terms, Bleach is a very user-friendly HTML sanitizer, and its main purpose is to disallow arbitrary tags to run (e.g., JavaScript (JS) tags and attributes to prevent cross-site scripting (XSS)).
After a bit of fuzzing and using some different approaches, Checkmarx researchers discovered the possibility that a mutation XSS (mXSS) vulnerability may exist. With further digging, these suspicions were confirmed, and several mXSS vulnerabilities were discovered in the Mozilla-Bleach python package.
An attacker abusing these vulnerabilities would have the ability to execute an arbitrary JavaScript code on the user end, via various sites or projects that use Bleach.

Mutation XSS (mXSS)

A mXSS vulnerability occurs when there is incoherent parsing between the client and the sanitizer. To understand this better, the following example should help.
Let’s see how a standard browser interprets invalid HTML. When we enter the data below into the innerHTML of the page:The browser will modify the data to make it valid html. In this case, this is what the output looks like:
Now let’s try to change the div tag to a different type of tag, for example:

Doing so will generate the result below:

Both examples act differently because the data inside the tags are parsed differently according to the tag type. Now, imagine the parser goes from left to right. In the first case, after entering the div tag, the parser stays as html and opens an a tag with the title attribute (because the “closing” div tag is text in an attribute, it will not close the tag).
In the second case, when the parser enters the style tag, it changes to CSS parser, which means no a tag is created, and the style tag will be closed where the attribute was supposed to be.
So, how can this information help us in finding vulnerabilities? Imagine a tag that parses differently in different cases, for example, the noscript tag. The trick here is that the noscript tag in HTML is treated differently, whether JavaScript (JS) is enabled or disabled. When JS is enabled, the data inside the tag is parsed as JS. But, when it’s disabled, the data is parsed as html. In nearly all cases, JS is enabled in browsers.
Let’s take a look at how the following input is being interpreted with, and without, JS enabled:

Here, JS is disabled:

Here, JS is enabled:

Vulnerability: CVE-2020-6802

When we tried to pass the above input to Bleach, it sanitized the ‘< ‘characters in the attribute, but also it closed the a tag! This means that it parsed the data in noscript as html.

In this case, the only thing left is to avoid this sanitization. If that wasn’t enough of a challenge, we attempted to enter another parsing into the equation.

This provided the outcome we were anticipating.
Sanitizer view:
Enters noscript and the parser is HTML, opens a style tag, and starts parsing as CSS (or raw text). Everything after the style tag isn’t parsed as html, so from the sanitizer’s viewpoint, there is no closing noscript tag nor img tag.
Browser view:
Enters noscript and the parser is changed to JavaScript. Now the “