Bleichenbacher Attack in Rails (Ruby)

The Bleichenbacher attack (CVE-1998-0101) exploits padding oracle vulnerabilities in RSA PKCS#1 v1.5 decryption, allowing an attacker to decrypt ciphertexts or forge signatures by observing whether a server returns distinct error messages for invalid padding versus other decryption failures. In Ruby on Rails applications, this vulnerability can surface when developers use low-level OpenSSL bindings directly for RSA decryption without proper error handling, particularly in legacy systems or custom authentication flows involving RSA-encrypted tokens.

Rails itself does not include RSA decryption in its core, but applications often integrate with external systems (e.g., SAML, JWT with RSA, or legacy SOAP services) using the openssl standard library. A vulnerable pattern occurs when rescuing OpenSSL::PKey::RSAError broadly and returning different HTTP status codes or messages based on the exception type. For example, distinguishing between OpenSSL::PKey::RSAError (padding error) and other errors like OpenSSL::PKey::RSAError for key issues can create a padding oracle if the application’s response leaks information about the padding validity.

Consider a Rails API endpoint that decrypts an RSA-encrypted session token using a private key. If the application returns a 400 Bad Request for padding errors but a 500 Internal Server Error for other failures, an attacker can iteratively modify the ciphertext and observe the responses to gradually decrypt the token. This is especially dangerous in Rails API-only applications where token-based authentication is common and error responses are not uniformly handled. The combination of Ruby’s OpenSSL bindings, which expose low-level decryption errors, and Rails’ flexible error handling via rescue_from or inline begin/rescue blocks, can inadvertently create a side channel if developers do not normalize error responses.

middleBrick’s black-box scanning can detect such behavior by sending malformed RSA ciphertexts to API endpoints and analyzing response differences. Since the test is unauthenticated and focuses on the attack surface, it identifies endpoints where error messages vary based on cryptographic validity—directly mapping to the Bleichenbacher oracle condition without requiring source code access.

The fix for Bleichenbacher in Ruby on Rails applications is to eliminate the padding oracle by ensuring that all RSA decryption errors produce identical responses, regardless of the failure cause. This must be done at the code level where OpenSSL is invoked, as Rails does not provide built-in RSA decryption helpers. The solution involves two steps: using RSA-OAEP instead of PKCS#1 v1.5 where possible, and if legacy PKCS#1 v1.5 is required, ensuring uniform error handling.

First, prefer RSA-OAEP, which is not vulnerable to Bleichenbacher due to its provable security padding. In Ruby, this is done using OpenSSL::PKey::RSA#private_decrypt with the OpenSSL::PKey::RSA::PKCS1_OAEP_PADDING flag. For example, in a Rails service object handling token decryption:

# app/services/token_decrypter.rb
class TokenDecrypter
  def self.decrypt(token, private_key_pem)
    private_key = OpenSSL::PKey::RSA.new(private_key_pem)
    begin
      # Use OAEP padding to avoid Bleichenbacher vulnerability
      private_key.private_decrypt(token, OpenSSL::PKey::RSA::PKCS1_OAEP_PADDING)
    rescue OpenSSL::PKey::RSAError => e
      # Normalize all decryption errors to prevent oracle
      Rails.logger.warn('RSA decryption failed')
      raise ActiveSupport::MessageVerifier::InvalidSignature, 'Invalid token'
    end
  end
end

If PKCS#1 v1.5 must be used (e.g., for interoperability), the rescue block must not leak any information about the error type. All OpenSSL::PKey::RSAError exceptions—whether due to padding, length, or key issues—must result in the same response. In a Rails controller, this means avoiding rescue_from that distinguishes error types:

# app/controllers/sessions_controller.rb
class SessionsController < ApplicationController
  def create
    token = decrypt_params[:encrypted_token]
    begin
      decrypted = TokenDecrypter.decrypt(token, Rails.application.credentials.decrypt_key)
      # Process decrypted token
      render json: { status: 'ok' }
    rescue ActiveSupport::MessageVerifier::InvalidSignature, OpenSSL::PKey::RSAError
      # Identical response for ALL verification/decryption failures
      head :bad_request
    end
  end
end

This approach ensures that whether the failure is due to invalid padding, incorrect key, or tampered ciphertext, the client receives a 400 Bad Request with no additional detail. middleBrick validates this fix by confirming that error responses are indistinguishable across multiple malformed ciphertext probes, thereby closing the oracle channel. Developers should also update dependencies like ruby-saml or jwt to versions that use OAEP or constant-time error handling, as some gems may internally use vulnerable patterns.