Author: bbossola

Supply Chain Shock: Backdoor in liblzma Highlights Third-Party Package Risks

bbossola, , , , , , , , Leave a comment

The open-source software (OSS) ecosystem thrives on the principles of transparency and collaborative development. However, a recent critical vulnerability discovered in the core library, liblzma, has cast a shadow on this trust. The vulnerability, which was disguised as a bug fix, contained malicious code that could have potentially granted attackers access to users’ systems through SSH servers. This unsettling incident serves as a sobering reminder of the tangible risks inherent in relying on third-party software packages, even within the seemingly open and collaborative realm of OSS.

What happened?

liblzma, a critical library used for compression in many Linux distributions, was compromised by a backdoor hidden within its source code. This backdoor, attributed to a contributor named Jia T75, remained undetected for two years. During the build process, the backdoor would infect the system, specifically targeting x86_64 Linux systems. This vulnerability could have allowed attackers to compromise SSH servers, potentially granting them unauthorized access to a user’s system.

Why third-party packages are a risk

While OSS thrives on collaboration, it also introduces vulnerabilities. We rely on the good faith of developers contributing code. Malicious actors can exploit this trust by injecting backdoors or other harmful code into seemingly legitimate libraries like liblzma.

What can you Do?

To mitigate the risks associated with third-party software packages, it is imperative to stay vigilant and proactive. Patching software promptly by updating your system regularly ensures you have the latest security fixes in place. Furthermore, exercising caution when obtaining software updates and packages by exclusively utilizing official or trusted sources is of utmost importance. Thoroughly researching the maintainers of the software packages you rely upon can shed light on their track record of responsible updates and reputation within the community. Whenever feasible, exploring alternatives to widely used libraries can be a prudent strategy, as diversifying your software portfolio can reduce the potential impact of a single vulnerability. By adopting these measures, you can bolster the security posture of your systems and minimize the risks posed by third-party software dependencies.

How Meterian can help

The liblzma backdoor incident serves as a wake-up call, and it highlights the need for constant vigilance. By understanding the risks and taking preventative measures, we can build a more secure software ecosystem. Remember, security is an ongoing process, not a one-time fix .

Security solutions like Meterian can be powerful allies in mitigating the risks of third-party packages. Meterian’s notification system keeps you informed about the latest vulnerabilities impacting your software ecosystem, including critical flaws like the recently discovered liblzma backdoor. Through timely alerts and detailed reporting, Meterian ensures you stay on top of potential threats before they can be exploited]. Additionally, Meterian’s Software Composition Analysis (SCA) solution goes a step further by scanning your codebase for known vulnerabilities within dependencies like liblzma. By proactively identifying these risks, SCA allows you to take early action and prioritize patching vulnerable components, ultimately safeguarding your systems and data.

Don’t wait for the next major vulnerability to compromise your systems. Take control of your software security today. Try Meterian for free and experience the power of proactive vulnerability detection and management.

An important note!

The xz/liblzma packages are sometimes included in major Linux distributions, and much of the focus is now there, also because this vulnerability can be exploited to execute remote commands over SSH. However, please be aware that this vulnerability may affect also your application code, either because it may be linking directly liblzma in your C/C++ applications or because, via conan, you previously used the package xz_utils in one of the vulnerable versions (5.6.0, 5.6.1). Furthermore, other wrappers such as xz.ex (elixir), xz.net (dotnet), ruby-xz (ruby) and similar packages may indirectly pull the affected package.

Update – 15 April 2024

This is a novel situation, and there is still much uncertainty. We are aware of only a single known exploit path at this time, but there may be additional scenarios that have not yet been identified.

In detail, so far, it looks like the payload activates if the running program has the process name /usr/sbin/sshd, however, based on ongoing analysis, it may activate also in other scenarios too, unrelated to SSH. This matter is still investigated, you can keep an eye at this page to follow the active investigation.


References

  1. Backdoor in the xz source code: https://www.openwall.com/lists/oss-security/2024/03/29/4
  2. Backdoor in upstream xz/liblzma leading to SSH server compromise: https://news.ycombinator.com/item?id=39868673
  3. NVD reference: https://nvd.nist.gov/vuln/detail/CVE-2024-3094
  4. A live analysis of the backdoor: https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
  5. Ongoing investigation: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Supply Chain Shock: Backdoor in liblzma Highlights Third-Party Package Risks

Understanding SBOMs: A Crucial Aspect of the EU Cyber Resilience Act (CRA)

bbossola, , , Leave a comment

The EU Cyber Resilience Act

The European Union Cyber Resilience Act (CRA), which was proposed on September 15, 2022, is the first EU-wide legislation addressing cybersecurity requirements for software and hardware manufacturers. Unlike the U.S. Executive Order, the CRA extends to all vendors who create products with digital components that connect to the internet. It will become enforceable in early 2027, three years after its ratification.

SBOM Requirements of the CRA

One of its key requirements focuses on Software Bill of Materials (SBOMs). An SBOM is essentially a comprehensive inventory of all software components used in a product. It provides transparency by listing out the dependencies, libraries, and third-party code that make up a software application. Think of it as a “recipe” for your software – it tells you exactly what ingredients (components) are included.

The key points related to Software Bill of Materials (SBOM) requirements under the EU Cyber Resilience Act are:

  • Manufacturers must identify and document product components and vulnerabilities, including the creation of a SBOM of at least the top-level dependencies of the product
  • The SBOM does not have to be made publicly available
  • The SBOM should be included in the technical documentation and, upon request, provided to market surveillance authorities

The EU Cyber Resilience Act mandates SBOM adoption to enhance cybersecurity and ensure transparency in software and hardware supply chains. Manufacturers need to create SBOMs for their products, while public availability is not required.

Why SBOMs are essential

SBOMs are a sensible tool to manage your supply chain transparency. With the increasing complexity of software supply chains, understanding what goes into your product is crucial. SBOMs allow manufacturers to trace the origins of each component, identify vulnerabilities, and assess risks.

By having an SBOM, organisations can proactively address security vulnerabilities. When a known vulnerability is discovered in a library or component, manufacturers can quickly assess which products are affected and take necessary remediation steps.

They are also required for compliance and legal requirements. Specifically, the CRA mandates that manufacturers create SBOMs for their products. Compliance ensures that products meet cybersecurity standards and reduces legal risks.

Why SBOMs are complicated

Creating and maintaining Software Bill of Materials (SBOMs) is a time-consuming process due to the intricate nature of modern software. Applications are no longer simple; they consist of interconnected components, libraries, and dependencies. The prevalence of open-source software further complicates matters. Each component introduces its own set of dependencies, licences, and potential vulnerabilities. Identifying and tracking all these elements manually is a daunting task. Ensuring accuracy, compliance, and security within this complex landscape inevitably consumes significant time and effort.

That’s the reason why it’s a good idea to adopt an automated solution that takes this problem away.

Meterian: your automated SBOM solution

Using automated analysis, Meterian continuously scans your codebase, identifies the whole network of dependencies, and generates an SBOM automatically. No manual effort required, as SBOMS can be created and stored during the analysis, or later on demand. This will save a substantial amount of time to your developers, who can say goodbye to weeks of research at each release. Everything happens directly on your pipelines or at the touch of a button.

With the help of his powerful vulnerability scanner, Meterian provides you all relevant vulnerability Insights. The Meterian vulnerability database tracks more than 340k vulnerabilities across more than 20 different OSINT sources. You will also automatically receive real-time alerts about vulnerabilities in your components, even if you do not actively analyse them: Meterian will do it for you.

Meterian is easy to integrate in your processes, as it seamlessly integrates with your development pipelines, ensuring continuous monitoring without any extra activity. A simple click, some lines of YAML, one or two lines of script, is all it takes. You get protection against vulnerabilities and compliance at the same time, without any extra effort.

Conclusion

As the EU Cyber Resilience Act comes into effect, manufacturers are required to embrace SBOMs to ensure transparency, enhance risk management, and achieve compliance. The Meterian platform simplifies the generation of SBOMs, enabling you to concentrate on developing secure and resilient software.

Remember: An SBOM isn’t just a regulatory requirement; it’s a powerful tool for safeguarding your digital products. Start creating your SBOMs today!

Understanding SBOMs: A Crucial Aspect of the EU Cyber Resilience Act (CRA)

Precise and Timely Vulnerability Notifications with Meterian

bbossola, , , 2 Comments

Stop worrying about missing critical vulnerability alerts. As application security experts, we know the constant struggle to stay informed about the latest threats facing your open-source components. That’s why we’re excited to introduce Meterian’s vulnerability notification system, designed to provide timely, accurate, and actionable information so you can take immediate steps to protect your applications.

Unparalleled Insight into Open-Source Risks

Meterian boasts the largest OSINT vulnerability database on the market, meticulously tracking over 335,000 vulnerabilities daily across 20+ diverse sources. We go beyond mere quantity, offering almost 94,000 unique vulnerabilities spanning 16 programming languages, ensuring comprehensive coverage for your development stack. Every day,

Never Miss a Critical Update

Our system proactively identifies new open-source component vulnerabilities and critical updates, delivering comprehensive notifications straight to your inbox. Each notification contains all the essential details to address the issue effectively:

  • Precise component name and ecosystem
  • Affected version range
  • Detailed vulnerability description
  • CVE identifier (if available)
  • Associated CVSS and EPSS scores
  • List of unaffected versions
  • Links for further exploration

What’s a CVE?

A CVE is like the official scoreboard listing of a severe foul or broken piece of equipment (a security flaw) that the entire league (the tech world) agrees must be fixed. Meterian acts as your team’s Defensive Coordinator, constantly watching the game for any new fouls and sending a precise, instant notification only to the players (developers) who are currently using that faulty gear, telling them exactly how to swap it out for a legal one before the referee throws a flag (a breach).

We believe that staying informed about vulnerabilities requires a comprehensive view. That’s why our platform not only delivers daily updates but also offers a valuable 30-day history, for free. This historical perspective allows you to track the evolution of vulnerabilities: whether you’re a seasoned developer or an individual user, understanding the trends over the past month can empower you to make informed decisions and take proactive security measures. Visit our Meterian Vulnerabilities pages to explore this rich history and stay ahead of the curve.

Tailored Alerts for Subscribed Users

We understand that information overload can be counterproductive. That’s why we offer two distinct notification systems for subscribed users:

  • Sentinel that continuously monitors previously scanned projects
  • Allerta that provides alerts based on a user specific preferences

Sentinel Notification System: Continuous Security Monitoring

Our Sentinel Notification System is your ticket to continuous security monitoring. It offers timely alerts to development teams, even without active scans. Once a project is under Meterian’s purview, Sentinel automatically and routinely examines it for new vulnerabilities. This seamless process ensures ongoing security screening, eliminating the need for user intervention. With Sentinel, you can rest assured that your projects remain protected around the clock.

Allerta Notification System: Tailored Security Alerts

The Allerta Notification System is designed with flexibility in mind. It allows users to tailor security alerts based on their preferences. You can define your interests, specifying preferred ecosystems, and scoring thresholds, ensuring that you receive notifications that align with your specific needs. Whether you’re a developer focusing on a particular programming language or a security professional seeking a broader view, Allerta provides precise information tailored to your requirements. With Allerta, you gain the ability to customize your security alerts while staying well-informed about the vulnerabilities that matter most to you.

 

Empowering Developers and Security Teams

Developers can focus on specific languages, while security personnel maintain a global view. All notifications provide granular details, including the affected component and version, so everyone has the context needed to make informed decisions. Don’t wait for a breach to expose your vulnerabilities. Meterian’s notification system empowers you to take control of your application security.

Sign up for a free trial today and experience the power of proactive application security. See for yourself how Meterian can keep you ahead of the curve and your applications safe. And remember, you can always consult the daily vulnerability report online, completely free: no subscriptions needed.

Take action now and protect your applications from the ever-evolving threat landscape!

Precise and Timely Vulnerability Notifications with Meterian

Enhancing Application Security with Meterian: A Powerful SonarQube Integration

bbossolaLeave a comment

In the fast-paced world of software development, ensuring code security is paramount. Vulnerabilities can lurk in unexpected places, and addressing them swiftly is crucial to safeguarding your applications and your users. That’s where Static Application Security Testing (SAST) and Software Composition Analysis (SCA) come into play. Today, we’re excited to announce a game-changing integration between Meterian, a leading cloud SCA solution, and SonarQube, a renowned SAST platform. In this blog post, we’ll explore the advantages of combining these two powerful tools and dive into the specifics of the Meterian and SonarQube integration.

Advantages of SAST with SCA: A Dynamic Duo for Code Security

Before delving into the integration, let’s understand why the combination of SAST and SCA is a game-changer for code security.

1. Comprehensive Vulnerability Detection: SAST analyzes your source code for security issues, identifying vulnerabilities from the code’s perspective. SCA, on the other hand, scans your dependencies for known vulnerabilities. Together, they provide comprehensive coverage, helping you identify and address issues across your codebase.

2. Early Detection: SAST and SCA work in different phases of the development lifecycle. SAST scans your code during development, while SCA monitors dependencies throughout the software’s lifetime. This early detection ensures that vulnerabilities are identified and remedied promptly, reducing the cost and effort of fixing issues in later stages.

3. Precise Remediation: By pinpointing vulnerabilities in both your code and dependencies, you gain precise information on what needs to be fixed. This helps developers focus their efforts on high-priority issues, improving efficiency and reducing false positives.

4. Improved Compliance: Many industries have strict compliance requirements. The combination of SAST and SCA aids in meeting these regulations by providing a robust security framework for your applications.

5. Enhanced Security Posture: Together, SAST and SCA help you build a stronger security posture, which is especially important in today’s threat landscape. By addressing vulnerabilities early and comprehensively, you reduce the attack surface and mitigate security risks effectively.


Meterian and SonarQube Integration: A Closer Look

Let’s now take a more detailed look at the most important aspects of the Meterian and SonarQube integration

1. Streamlined Workflow: The integration seamlessly incorporates Meterian’s SCA results into your SonarQube environment. This means that you can access SCA insights right where you already manage your code analysis, streamlining your workflow. View problems directly within the SonarQube interface while retaining the ability to drill down into the full Meterian report for a comprehensive view of vulnerabilities and dependencies.

2. Real-time Feedback with Custom Notifications: Receive real-time feedback on your code’s security status, and stay informed about any new vulnerabilities affecting your dependencies. Meterian takes it a step further by offering customizable notification options. You can receive alerts via Slack, Email, or WebHook, ensuring that your team stays instantly updated and can take immediate action to address any issues.

3. Remediation Guidance with Safe Dependency Versions: The integration provides detailed remediation guidance, helping developers understand and resolve vulnerabilities effectively. When vulnerabilities are detected, Meterian goes a step beyond by not only identifying the issues but also providing safe versions of the dependencies to use in order to mitigate these vulnerabilities effectively. This valuable guidance streamlines the remediation process, ensuring that developers have access to trusted solutions for code security..

4. Enhanced Quality beyonde code: Achieve higher code quality and security standards by leveraging Meterian’s comprehensive vulnerability database and SonarQube’s powerful analysis capabilities. The integration not only identifies vulnerabilities but also extends its benefits by detecting out-of-date dependencies within your codebase. This ensures that your applications not only remain secure but also stay up-to-date with the latest libraries and components.

5. Strengthened Compliance with License Reporting and SBOM: In addition to its robust security features, the Meterian and SonarQube integration significantly strengthens compliance efforts. Meterian goes beyond security by reporting licenses for all dependencies used in your software projects. This comprehensive license reporting ensures that your organization remains compliant with licensing requirements, reducing the risk of legal and financial liabilities. Furthermore, Meterian provides a full Software Bill of Materials (SBOM), offering transparency into all the components and libraries used in your applications. By combining security and compliance in one integrated solution, you can achieve a higher level of confidence in your code while minimizing legal risks.

Getting Started with the Integration

Getting started with the Meterian and SonarQube integration is straightforward. Simply follow these steps, as described in Meterian’s documentation page:

  1. Install the Meterian Plugin: Begin by installing the Meterian plugin for SonarQube in your local installation: it should be as easy as dropping the jarfile in the plugins folder (docs)

  2. Configure the Integration: Adjust the plugin properties if needed: the defaults should be already a fair fit. (docs)

  3. Add Meterian to your pipelines and enjoy seamless SCA Insights: With the integration set up, and Meterian in your pipelines, you’ll start receiving valuable SCA insights within your SonarQube environment. (docs)

The plugin supports at the moment NodeJS on NPM, and Java/Kotlin on Maven and Gradle. Support for .NET is planned by the end of this month, then Swift and Go will follow shortly. It can run on SonarQube v9.x, support for 10.x and cloud is coming later this year (roadmap).


Conclusion

Code security is a top priority for every software development team. The integration between Meterian, a leading cloud SCA solution, and SonarQube, a renowned SAST platform, offers a powerful combination to enhance your code security efforts. By leveraging the advantages of SAST and SCA, you can achieve comprehensive vulnerability detection, early issue identification, precise remediation, improved compliance, and an enhanced security posture. The Meterian and SonarQube integration streamlines your workflow, provides real-time feedback, offers remediation guidance, reduces false positives, and enhances code quality, making it an invaluable asset for any development team.

To get started with this integration and improve your application security, visit Meterian’s documentation page today. Elevate your security game and build robust, secure applications with Meterian and SonarQube.

Stay secure, stay confident!

Meterian Logo

All trademarks are the property of respective owners

Enhancing Application Security with Meterian: A Powerful SonarQube Integration

Improved Security for Swift Developers: Meterian Now Supports SwiftPM!

bbossola, , , , Leave a comment

Meterian is proud to announce that it now supports Swift Package Manager (SwiftPM), providing improved security for Swift developers. This new feature allows Swift developers to seamlessly integrate Meterian’s powerful security scanning capabilities into their Swift projects, helping them identify and fix vulnerabilities in their open source dependencies.

SwiftPM is the official package manager for Swift, the popular programming language developed by Apple for building iOS, macOS, watchOS, and tvOS applications. It simplifies the process of managing dependencies in Swift projects and enables developers to easily share their code as packages. With Meterian’s support for SwiftPM, developers can now add an additional layer of security to their Swift projects by automatically scanning their dependencies for known security vulnerabilities.

I am using Cocoapods: why is this important?

While Cocoapods has been the de facto dependency manager for iOS and macOS projects for several years, SwiftPM has emerged as a powerful alternative, offering several advantages over its predecessor.

Firstly, SwiftPM is an official tool provided by Apple, which means that it is well-integrated with the Xcode development environment and has the backing of the Swift community. This ensures that SwiftPM is continuously updated with the latest features and security enhancements, making it a reliable and secure option for managing dependencies in Swift projects.

Secondly, SwiftPM is designed to be lightweight and fast, with a simple command-line interface that is easy to use and understand. This makes it an ideal tool for small to medium-sized projects, where simplicity and ease of use are essential. Cocoapods, on the other hand, can be slow and cumbersome, particularly for large projects with numerous dependencies, where the overhead of managing the Podfile can become overwhelming.

Thirdly, SwiftPM has a modular architecture that allows developers to easily share code between different projects and platforms, making it a more flexible and versatile tool than Cocoapods. This makes it particularly useful for developers working on cross-platform projects, where code sharing is critical.

Finally, SwiftPM is a more modern and future-proof solution than Cocoapods, which relies on Ruby. SwiftPM is written in Swift and does not require any extra tooling, making it a natural choice for iOS and macOS developers

Overall, while Cocoapods has been a valuable tool for many iOS and macOS developers over the years, SwiftPM has emerged as a more modern, lightweight, and flexible alternative, offering several advantages over its predecessor. With Meterian’s support for SwiftPM, developers now have access to a powerful security scanning solution that is well-integrated with the Swift ecosystem and provides critical security enhancements for their Swift projects.

I am switching to SwiftPM. How does Meterian help me?

Meterian’s SCA solution uses advanced scanning techniques to analyze the source code of open source dependencies and identifies any known security vulnerabilities or licensing issues. The results are presented in a comprehensive dashboard, allowing developers to easily understand the security status of their dependencies and take appropriate actions to address any identified issues.

One of the key benefits of using Meterian with SwiftPM is the seamless integration into the Swift development workflow. Developers can simply add Meterian as a build step in their SwiftPM build process, making it easy to incorporate security scanning into their existing development pipeline. This ensures that security is considered as an integral part of the development process, reducing the risk of shipping software with vulnerable dependencies.

Another powerful feature of Meterian is its ability to provide remediation guidance. When vulnerabilities are identified, Meterian provides detailed information on how to fix the issue, including code snippets, links to relevant documentation, and recommendations for alternative libraries or versions. This helps Swift developers quickly address security issues and keep their dependencies up to date.

Meterian’s support for SwiftPM comes at a critical time when security is a top concern for software development teams. As cyber threats continue to evolve and open source vulnerabilities become more prevalent, it is crucial for Swift developers to proactively manage the security of their dependencies. By leveraging Meterian’s advanced scanning capabilities, Swift developers can ensure that their software is built on a solid foundation of secure dependencies, minimizing the risk of security breaches and protecting their users’ data.

I want to use Meterian: what should I do?

Meterian is free for open source projects! If you have a GitHub OSS project, you can easily integrate Meterian using the GitHub Action following this step-by-step guide or you can checkout this live example on GitHub. We do have also native integrations with BitBucket and Azure Devops, and also integrations with other CI/CD platforms.

Meterian is here to help!

Meterian’s support for SwiftPM brings enhanced security to Swift developers, allowing them to easily scan their open source dependencies for known vulnerabilities and proactively manage their software’s security. With its seamless integration into the SwiftPM workflow and comprehensive remediation guidance, Meterian empowers Swift developers to build secure software and protect their users’ data. To learn more about Meterian’s support for SwiftPM and how it can help improve the security of your Swift projects, visit Meterian’s website at www.meterian.io.

Improved Security for Swift Developers: Meterian Now Supports SwiftPM!

Meterian now supports pnpm!

bbossola, Leave a comment

Hello fellow developers!

We are happy to report that now Meterian supports pnpm, a new fast and more efficient alternative to npm. It’s comparably faster, especially when installing packages, compared to npm and it also saves a lot of disk space as it used symlinks to represent modules. Pnpm also supports very well monorepos using workspaces, and it has built-in support for multiple packages in a repository.

Pnpm support is available out of the box now in GitHub Actions, Azure DevOps, Bitbucket Pipes and of course using either the thin CLI or the dockerized CLI, so that you can continue to be informed about any vulnerable, out of date, or non-business friendly node module in your dependencies.

Remember: Meterian is free for open source!

Meterian now supports pnpm!

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

bbossola, , Leave a comment

Red alert! All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered vulnerabilities “Spring4Shell” since its announcement, between 29th and 30th March, 2022, affecting various Spring components.

CVE-2022-22963

Vulnerability Score: 9.5 (CVSS: 3.0 / AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H)
Platform: Java
Components: org.springframework.cloud:spring-cloud-function-core, org.springframework.cloud:spring-cloud-function-context
Affected versions: 3.1.6, 3.2.2 and older unsupported versions
Fixed in version: 3.1.7, 3.2.3

CVE-2022-22965

Vulnerability Score: 9.5 (CVSS:3.0 / AV: N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H)
Platform: Java
Components: org.springframework:spring-beans
Affected versions: all versions before 5.2.20, all versions before 5.3.18 
Fixed in version: 5.2.20, 5.3.18

Please note that this affects also the spring-framework package and the spring-boot package, that both use the offending libraries. New versions of such packages have been made available. You can upgrade spring-framework to version 5.2.20 or 5.3.18, and you can upgrade spring-boot to version 2.5.12 or 2.6.6 (note that spring-boot itself includes spring-framework, no other upgrades necessary).

Which systems does these affect?

CVE-2022-22963 affects any project built using a vulnerable version of Spring Cloud, a framework that provides tools for developers to quickly build some of the common patterns in distributed systems. The “functions” part is a subsystem used to implement serverless functions like AWS lambda or Google Cloud Functions: if you are using such subsystem you are potentially affected.

CVE-2022-22965 affects any project built using a vulnerable version of Spring Framework, Spring Boot or the library spring-beans. A successful attack, however, can only be conducted undere these conditions:

  • JDK 9 or higher is used as the runtime environment
  • Apache Tomcat is used as the Servlet container
  • The application is packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
  • There is a dependency with spring-webmvc or spring-webflux, or an endpoint is used with DataBinder enabled

Please note however that analysis are undergoing and the nature of the vulnerability is quite general: we suggest you keep monitoring this page for further updates.


Why do these threats demand an urgent patch?

Both vulnerabilities allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers. It’s a simple exploit, as it requires only to send a crafted HTTP header in a request in order to execute code on the remote host. These vulnerabilities are actively exploited in the wild.


How can I check if my system is affected?

If you maintain any software using Java libraries, check if you are using any Spring Cloud Function library. The  Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries.  If it is using the offending package, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.

If you are a developer and you have access to the code, you can simply execute this command from your terminal:

CVE-2022-22963:

$ mvn dependency:tree | grep spring-cloud-function | grep compile
[INFO] +- org.springframework.cloud:spring-cloud-function-core:jar:3.1.2:compile

If you see any response lines, check the version: if it’s below 3.1.7 (as in the above example) or, if using 3.2.x, below 3.2.3, you may be affected.

CVE-2022-22965:

$ mvn dependency:tree | grep spring-beans | grep compile
[INFO] +- org.springframework:spring-beans:jar:5.3.11:compile

If you see any response lines, check the version: if it’s below 5.3.18 (as in the above example) or, if using 5.2.x, below 5.2.20, you may be affected.


My system has the vulnerable spring cloud function library — how can I mitigate the risk?

There are now patched versions of the affected components that resolve the issues, they are available via the standard Maven repositories. Upgrade the offending packages using the patched versions, as described in this article.

If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before.

CVE-2022-22963:

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-function-core</artifactId>
        <version>3.1.7</version>
    </dependency>

Please be aware that there are multiple packages rooted in "spring-cloud-function": you will need to upgrade all of them, in particular "spring-cloud-function-context" which is also directly affected.

CVE-2022-22965:

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>5.3.18</version>
    </dependency>

Please be aware that you may need / may be better to upgrade the parent pom of the project using an unaffected version of spring boot / spring framework (see at the start of the article).


What can I do to proactively protect from such vulnerabilities?

We always suggest you regularly scan your software code bases. 

  • To do a scan from the command line using the Meterian CLI scanner
  • To include this as part of your continuous improvement efforts to build resilience into your software development lifecycle, see our documentation on the various integrations we support with GitHub Actions, Azure DevOps Pipelines, and others.


Are Meterian applications affected by the spring vulnerability?

We have verified our applications and none are using the offending packages in a vulnerable configuration. We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components. Given the nature of this vulnerability we will be running a specific monitoring for the following days, while more details are unfolded in regards to those vulnerabilities.   

Related references

CVE-2022-22963

CVE-2022-22965

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

Is it a good idea to have vulnerable opensource components in my application?

bbossola, , , Leave a comment

This may seem to be a trivial question or something more like a joke. Why would one keep a vulnerable component in his tech stack? That said, from time to time, we meet people who simply answer “well, this is not an issue”.

Surprisingly, some are part of the technology leadership, or even the security chapter. Often their answer is usually along the lines of: “Well, you should know there’s a difference between vulnerable and exploitable: the fact that a component is vulnerable does not automatically mean that it’s possible to exploit it”.

“There’s a difference between vulnerable and exploitable…”

Yes, that is perfectly correct. We know it, as we do our own analysis as part of our routine.

Do you know what the problem is? You are probably not involved in the project and you are not a developer. I can bet that you are not continuously monitoring and assessing the code that your developers are daily pushing. Are you? Because at the speed innovation is going these days, there’s no guarantee that even tomorrow one of your developers will push a line of code that will enable the exploit. Yes, these exploits may be quite complex but also may be very easy to enable. It’s possible that an application including a vulnerable component is not exploitable today, but what about tomorrow? Your software is changing continuously.

“…but developers push new code daily, software is changing continuously.”

Do you know why Struts in Equifax was hacked? Because of a log message. A simple log message that echoes the content of a header, only that such content contained OGNL code, crafted by an attacker.

Do you know how jackson-databind remote code execution can be exploited? It’s just one configuration property away: enable polymorphic JSON deserialization and you are on.An apparently innocuous JSON message can feed now code to your server to be remotely executed.

So, in your position, I would not sit too complacent on the fact that you have vulnerable components that today cannot be exploited because of the current application code. That code changes continuously, daily, and unless you have in place an incredibly strict validation process, you are at risk, and you are putting your customers at risk. I do not believe such risk is acceptable.

“Most of the times the fix is just one patch away.”

Furthermore, most of the time fixes are just a patch away. We are not talking about a four-week refactoring session, but probably more like a one minute change and a run of the normal test regression suites, And if you had a system in place to continuously check your components against known vulnerabilities, you would have caught such an issue and patched it a while ago.

This is not a commercial plug for Meterian. Yes. this is our bread and butter, and we think we provide tons of value for the money. But some of our competitors do that as well. Maybe you are already using one of them in your company, and that’s great. Plug that in and set your customers free from this risk.

Nobody likes to be hacked.

Is it a good idea to have vulnerable opensource components in my application?

The new social network from Trump may violate the AGPL license.

bbossola, , , Leave a comment

It looks that everybody can misread a license, even a former President of the United States. The Software Freedom Conservancy (SFC) concluded that Trump’s new social network, “Truth Social”, violates the terms of the AGPL license. It looks like the code of the system is simply a copy of Mastodon, an existing open-source social network licensed under the AGPLv3 license. That license is a (very infectious) copyleft license, it specifically states that every user is entitled to receive the complete source code of the system. “Truth Social” is not compliant on this aspect, and also violates the license calling their software “proprietary”.

“…an entire open-source platform was just copied with no regard to the license…”

This is a very common mistake: nowadays software is built by hundreds of open-source components and license compliance is a very complex task, you can read an explanation in this article. However, in this instance and based on the SFC analysis, an entire open-source licensed platform was just copied and reused, with no regard to the license.

So what are the options for Truth Social at this time? I believe they can: 

  • release the derived system under a compatible open-source license, most possibly the AGPLv3 itself, and make their code publicly available
  • obtain a license for commercial use from the Mastodon contributors, but I doubt this will be possible, also given Mastodon view on Gab, another right-wing social
  • rewrite everything from scratch and relaunch

Of course, they may also fight this in court, but having seen some of the evidence from Mastodon, I doubt this is going to be a successful choice. It will be interesting to follow how this will evolve.

*** UPDATE ***

The Gab team, threatened by legal action, decided to release the source code publicly!
https://uk.pcmag.com/social-media/137421/trumps-social-media-site-quietly-admits-its-based-on-mastodon

The new social network from Trump may violate the AGPL license.

Rust— the new language shaking up the open source programming world

bbossolaLeave a comment

Rust is a relatively “new” software language across all the available ones at this time and rising in popularity among developers. Having been voted ‘most loved’ language for the past five years1, it is no wonder that Rust is gaining more attention. Read on to hear why we think Rust is worth your time.

Why a developer should consider Rust

Rust is a system language, along the lines of C and C++, but at the same times it incorporates many of the features of higher level languages, such as:

  • A reliable memory management (without a garbage collector)
  • An extremely low overhead
  • The use of static typing
  • A build design that prioritises performance (at the level of C and C++)
  • The use of a modern package management ecosystem

Remember Go? Rust will almost be faster than Go in run-time benchmarks because it has superior fine-grained control over how concurrency works in terms of threads and shared resources2. 

Additionally, Rust is being considered for use in the Linux Kernel3 by Linus himself, which is no small feat. Rust also supports WebAssembly4, just in case you fancy writing some web stuff 🙂

Rust has also become the ideal candidate for  IoT application development. Labeled as fast, reliable, and secure by Smart Device Management organisation Dwello5 who switched to Rust for their IoT platform. As they build IoT applications, developers have many programming languages to choose from. Some popular options are Java, C, JavaScript and Python. C and C++ are especially popular for device-run code. Another, less popular, option today is Rust, but that is likely to change. Let’s start with the characteristics of any programming language that makes it a good candidate for IoT development.

Application performance is a top priority, especially for code running on devices with minimal CPU and memory resources.  Developers can develop highly performant applications with C and C++, but at a cost. C and C++ developers know all too well the risks and challenges of dealing with bugs related to memory management such as unhandled null pointers and failing to deallocate unused memory.

Another component of a good IoT development language is developer productivity. Productivity is often a byproduct of skills, tools, and programming language abstractions and patterns. Popular programming languages are well supported by development environments. Additionally, developers acquire build tools and skills with time and experience; as a result, language abstractions and patterns are a key consideration with regards to developer productivity.

For those looking for both application performance and developer productivity, Rust is an increasingly popular option. The IoT market size is expected to grow from $250.72 billion in 2019 to $1,463.19 billion by 20276. Clearly, this is an area of the tech world that is only set to expand in influence. Meterian prioritises remaining at the forefront of innovation and supporting languages that have a vital role in ever advancing tech trends.

Why Meterian has decided to add Rust to its supported languages

First of all, Rust is big in open source, so it’s a natural continuation in our mission to support open source. Although security is extremely important in the Rust philosophy, there are vulnerable packages appearing in the wild. The GitHub advisory database7 does not have an entry for Rust (although some advisories do surface here and there) and the NVD database contains only a portion of all the vulnerable Rust components. Meterian is ingesting not only the NVD and other official security Rust databases, but it’s also actively monitoring many Rust open source projects at their source. Our ongoing efforts for getting the optimal coverage of all known vulnerabilities for open source dependencies extends our mission to Rust developers so we can maximise preventative care for Rust coding projects. 

Rust is important to pay attention to because on average every single rust open source project we scanned contains at least 1 vulnerable component that often could be patched.

Sizing up the risks in the Rust ecosystem

Screenshot from: https://www.rust-lang.org/

Rust, like all other modern languages, has an ecosystem of components, called “crates”, that are available from the open source community, which is accessible at crates.io. Although as a Rust developer you will always prefer writing some code from scratch (at the end of the day, this is a system language), it’s highly likely you won’t be reinventing the wheel. As shown on the screenshot from May 6th, over 60,000 crates with over 6.8 billion downloads, this is a significant size.

There’s a good chance that, if you never checked, you have been using a crate affected by a publicly disclosed vulnerability. Unless you are in application security and unless you spend half of your time reading bulletin boards, advisories, mailing lists, you won’t know about it. However, hackers do. They keep an eye on these vulnerabilities and routinely develop automated attacks to exploit them. In fact, hackers have it nailed to a T. The vulnerabilities are made public on open source vulnerability databases, the code is open source, they already have a botnet to run them (maybe even your Amazon Alexa or Google Play). All of a sudden, your shiny new service written with the latest cutting edge technology is vulnerable, and it can be used to exfiltrate confidential user data from your backend!

Let’s assume, for example, that you are using hyper, an HTTP library:

Screenshot taken from: https://www.rust-lang.org/

Since hyper is a relatively low-level library, it’s meant to be a building block for other libraries and applications. It may be a transitive dependency, a crate that is pulled in your code as the result  of another crate that is used. In particular version 0.12.34 of hyper has an interesting vulnerability: it allows an attacker to remotely execute code on the machine where your code is running. Check out this Common Vulnerabilities and Exposures ID CVE-2020-35863 for more details.  This security vulnerability would allow the attacker, for example, to install a very simple bot on your server, open an undetected tunnel and start pulling data from your proprietary system.

This is the beauty of a tool that detects the problem automatically and informs you promptly. We prioritise your time so that you can focus on the solution to remediate the issue, maximising productivity whilst maintaining high standards of open source security. 

What can Meterian do for you?

Sign up for a free account to see how our invisible security platform can work seamlessly in your software development life cycle (SDLC) and auto-remediate vulnerable components.

1 https: //insights.stackoverflow.com/survey/2020#overview

2 Howarth, Jesse. “Why Discord is switching from Go to Rust”. Discord, 4 Feb 2020, https: //blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

3 Salter, Jim. “Linus Torvalds weighs in on Rust language in the Linux kernel”. Arstechnica, 25 March 2021, https: //arstechnica.com/gadgets/2021/03/linus-torvalds-weighs-in-on-rust-language-in-the-linux-kernel/

4 “Why Rust?”, https: //www.rust-lang.org/what/wasm

5 Hiner, Jeff. “We Rewrote Our IoT Platform in Rust and Got Away With It”. Medium, 31 July 2019, https: //medium.com/dwelo-r-d/we-rewrote-our-iot-platform-in-rust-and-got-away-with-it-2c8867c61b67

6 Fortune Business Insights, https: //www.globenewswire.com/en/news-release/2021/04/08/2206579/0/en/Global-IoT-Market-to-be-Worth-USD-1-463-19-Billion-by-2027-at-24-9-CAGR-Demand-for-Real-time-Insights-to-Spur-Growth-says-Fortune-Business-Insights.html

7 https: //github.com/advisories

Rust— the new language shaking up the open source programming world