Security
Headlines
HeadlinesLatestCVEs

Headline

GHSA-m875-3xf6-mf78: unpoly-rails Denial of Service vulnerability

There is a possible Denial of Service (DoS) vulnerability in the unpoly-rails gem that implements the Unpoly server protocol for Rails applications.

Impact

This issues affects Rails applications that operate as an upstream of a load balancer’s that uses passive health checks.

The unpoly-rails gem echoes the request URL as an X-Up-Location response header. By making a request with exceedingly long URLs (paths or query string), an attacker can cause unpoly-rails to write a exceedingly large response header.

If the response header is too large to be parsed by a load balancer downstream of the Rails application, it may cause the load balancer to remove the upstream from a load balancing group. This causes that application instance to become unavailable until a configured timeout is reached or until an active healthcheck succeeds.

Patches

The fixed release 2.7.2.2+ is available via RubyGems and GitHub.

Workarounds

If you cannot upgrade to a fixed release, several workarounds are available:

  • Configure your load balancer to use active health checks, e.g. by periodically requesting a route with a known response that indicates healthiness.

  • Configure your load balancer so the maximum size of response headers is at least twice the maximum size of a URL.

  • Instead of changing your server configuration you may also configure your Rails application to delete redundant X-Up-Location headers set by unpoly-rails:

    class ApplicationController < ActionController::Base
    
      after_action :remove_redundant_up_location_header
      
      private
      
      def remove_redundant_up_location_header
        if request.original_url == response.headers['X-Up-Location']
          response.headers.delete('X-Up-Location')
        end
      end
    
    end
    

References

ghsa
#vulnerability#dos#git#nginx#ruby

There is a possible Denial of Service (DoS) vulnerability in the unpoly-rails gem that implements the Unpoly server protocol for Rails applications.

Impact

This issues affects Rails applications that operate as an upstream of a load balancer’s that uses passive health checks.

The unpoly-rails gem echoes the request URL as an X-Up-Location response header. By making a request with exceedingly long URLs (paths or query string), an attacker can cause unpoly-rails to write a exceedingly large response header.

If the response header is too large to be parsed by a load balancer downstream of the Rails application, it may cause the load balancer to remove the upstream from a load balancing group. This causes that application instance to become unavailable until a configured timeout is reached or until an active healthcheck succeeds.

Patches

The fixed release 2.7.2.2+ is available via RubyGems and GitHub.

Workarounds

If you cannot upgrade to a fixed release, several workarounds are available:

  • Configure your load balancer to use active health checks, e.g. by periodically requesting a route with a known response that indicates healthiness.

  • Configure your load balancer so the maximum size of response headers is at least twice the maximum size of a URL.

  • Instead of changing your server configuration you may also configure your Rails application to delete redundant X-Up-Location headers set by unpoly-rails:

    class ApplicationController < ActionController::Base

    after_action :remove_redundant_up_location_header

    private

    def remove_redundant_up_location_header if request.original_url == response.headers[‘X-Up-Location’] response.headers.delete(‘X-Up-Location’) end end

    end

References

  • Common HTTP Response Header Limits
  • Nginx Proxy buffer tuning
  • 414 Request-URI too long
  • Unpoly server protocol

References

  • GHSA-m875-3xf6-mf78
  • https://nvd.nist.gov/vuln/detail/CVE-2023-28846
  • unpoly/unpoly-rails@cd9ad00
  • https://docs.nginx.com/nginx/admin-guide/load-balancer/http-health-check/#passive-health-checks
  • https://github.com/unpoly/unpoly-rails/
  • https://makandracards.com/operations/537537-nginx-proxy-buffer-tuning
  • https://tryhexadecimal.com/guides/http/414-request-uri-too-long
  • https://unpoly.com/up.protocol

Related news

CVE-2023-28846: GitHub - unpoly/unpoly-rails: Ruby on Rails bindings for Unpoly

Unpoly is a JavaScript framework for server-side web applications. There is a possible Denial of Service (DoS) vulnerability in the `unpoly-rails` gem that implements the Unpoly server protocol for Rails applications. This issues affects Rails applications that operate as an upstream of a load balancer's that uses passive health checks. The `unpoly-rails` gem echoes the request URL as an `X-Up-Location` response header. By making a request with exceedingly long URLs (paths or query string), an attacker can cause unpoly-rails to write a exceedingly large response header. If the response header is too large to be parsed by a load balancer downstream of the Rails application, it may cause the load balancer to remove the upstream from a load balancing group. This causes that application instance to become unavailable until a configured timeout is reached or until an active healthcheck succeeds. This issue has been fixed and released as version 2.7.2.2 which is available via RubyGems and Gi...

ghsa: Latest News

GHSA-hqmp-g7ph-x543: TunnelVision - decloaking VPNs using DHCP