Ruby SAML CVE-2024-45409: As bad as it gets and hiding in plain sight

Just because code is open-source doesn't mean it's secure.

‍Note: WorkOS is not currently, and has never been, affected by the following vulnerability.

‍On September 10th, 2024, a critical security flaw was disclosed in the Ruby-SAML and OmniAuth-SAML libraries, exposing a vulnerability that allows complete authentication bypass.

This flaw, CVE-2024-45409, earned the highest possible score of 10 on GitHub's CVE rubric and a 9.8 NIST base score, making it a "worst-case scenario". Why?

This flaw allows an attacker to log in as any user, including administrators.

Since the vulnerability also affected GitLab, a popular version control system for storing software, attackers could potentially:

• Read secret values from CI/CD systems (such as API keys and database passwords)
• Modify URLs in widely used software, changing them to malicious endpoints
• Embed malware in widely distributed software

Scarily, this vulnerability sat undiscovered in plain sight, in a popular open-source library that was widely used for authentication, for over a decade. When you're finished reading this post, you'll understand:

1. How to determine if your systems are affected
2. How to patch vulnerable systems
3. The flaw in Ruby-SAML that makes it vulnerable
4. How attackers can exploit the vulnerability
5. The ramifications for the open-source ecosystem

Are you affected by Ruby-SAML CVE-2024-45409?

GitLab released a patch release for GitLab Community Edition and Enterprise Edition versions 17.3.3, 17.2.7, 17.1.8, 17.0.8, and 16.11.10, stating that updating the Omniauth-SAML version to 2.2.1 and Ruby SAML version to 1.17.0 will mitigate CVE-2024-45409. The vulnerability impacts self-managed GitLab instances.

Dedicated instances have already been upgraded. In other words, if you’re running any of the above GitLab Community or Enterprise Edition versions, and you have not yet updated Omniauth-SAML to version 2.2.1 and Ruby SAML to version 1.17.0, you are affected and vulnerable. Upgrade these packages immediately.

How does CVE-2024-45409 break SAML authentication?

SAML (Security Assertion Markup Language) is a standard protocol for single sign-on and federated authentication. If you'd like a more in-depth explanation of SAML, we've written a guide explaining what it is and how it works.

A Secure SAML Authentication Process

1. The user attempts to access a service provider (e.g., GitLab)
2. The Service provider redirects user to identity provider (e.g., Google)
3. The Identity provider authenticates user (often via username and password) and returns a signed SAML response
4. The Service provider verifies the signature and performs validation on the SAML response
5. If the Service provider determines the SAML response is valid, it logs the user in using the information provided in the response

How  a subtle XPath query mistake made Ruby-SAML vulnerable

Ruby SAML’s flaw is in how it verifies the integrity of the SAML response (Step 4). XPath is a query language that programmatically selects elements from XML documents. The vulnerable code is shown below:

encoded_digest_value = REXML::XPath.first(ref, "//ds:DigestValue", { "ds" => DSIG })

‍This line uses an XPath selector to find the DigestValue element in the SAML response. The problem is the selector `//ds:DigestValue` is overly permissive.

The `//` in XPath means "search anywhere in the document." This allows the selection of a `DigestValue` element from any part of the SAML response, not just from the intended SignedInfo block.

Because  XPath’s `first` method retrieves only the first matching element, an attacker can inject a forged DigestValue earlier in the document. By selecting an incorrect (potentially forged) DigestValue, the entire signature verification process is compromised.

The system validates the wrong data, potentially allowing unauthorized access. This is a classic example of how overly permissive XML parsing can lead to severe security issues. Even though XPath is part of Ruby’s standard library a very subtle misuse of its query language ultimately led to complete authentication bypass.

Exploiting  CVE-2024-45409 - Step-by-Step

Let's step through exploiting CVE-2024-45409 to understand what a realistic attack scenario looks like.

Step 1: Obtain a Valid SAML Response

Intercept a legitimate SAML response during your own authentication process. This gives you a signed example SAML response from your identity provider.

Step 2: Modify the SAML Response

Inject a forged <ds:DigestValue> element within a <samlp:Extensions> section. Modify the <saml:Assertion> section to impersonate a target user (e.g., an administrator).

Step 3: Craft the Malicious Payload

Here's a simplified example of a modified SAML response:

Step 4: Submit the Modified Response

Send this modified SAML response to the vulnerable service provider (e.g., GitLab). Due to the XPath flaw, the service provider verifies the forged digest value.

Step 5: Bypass Security Checks

The integrity check passes because the forged digest matches the modified assertion. The signature verification also passes as the original signature remains intact.

Step 6: Gain Unauthorized Access

The service provider authenticates you as the specified user (in this case, an admin). At this point, it’s game over, and you have administrator access.

Open source does not necessarily mean secure

The discovery of CVE-2024-45409 in Ruby-SAML is a stark reminder that open-source software, despite its many benefits, is not inherently secure. This vulnerability remained undetected in a popular and mature library for years, highlighting several critical issues in the open-source ecosystem.

The myth of "many eyes"

One common belief about open-source software is that its transparency leads to better security - the "many eyes" theory suggests that with code open for anyone to review, vulnerabilities will be quickly spotted and fixed. Unfortunately, despite a decade of development on Ruby-SAML, this critical flaw went unnoticed.

The challenges of maintaining open-source projects

Ruby-SAML, like many open-source projects, faces several challenges that contributed to this vulnerability remaining undetected:

• Volunteer maintenance: Many open-source projects, including critical security libraries, are maintained by volunteers who may not have the time or resources for comprehensive security audits.
• Complexity and specialization: As software becomes more complex, it becomes harder for generalist programmers to spot security issues in specialized areas like cryptography and authentication.
• Assumption of security: Users and even contributors might assume that widely-used libraries, especially those handling security functions, have already been thoroughly vetted.
• Lack of funding: Many critical open-source projects lack the funding necessary for regular security audits or full-time maintenance.

How to mitigate the impact of flaws like Ruby-SAML’s

The impact of this vulnerability extends far beyond Ruby-SAML itself. As we’ve seen with its effect on GitLab, security flaws in foundational libraries can ripple through the dependency chain, potentially exposing many systems.

To mitigate the impact of Ruby-SAML’s vulnerability and similar flaws, partner with trusted security experts like WorkOS. We ensure robust SAML implementations and safeguard your applications.