Package Instance

Active Record subject to Regular Expression Denial-of-Service (ReDoS)
The PostgreSQL adapter in Active Record before 6.1.2.1, 6.0.3.5, 5.2.4.5 suffers from a regular expression denial of service (REDoS) vulnerability. Carefully crafted input can cause the input validation in the `money` type of the PostgreSQL adapter in Active Record to spend too much time in a regular expression, resulting in the potential for a DoS attack. This only impacts Rails applications that are using PostgreSQL along with money type columns that take user input.

ReDoS based DoS vulnerability in Action Dispatch
There is a possible regular expression based DoS vulnerability in Action Dispatch. Specially crafted cookies, in combination with a specially crafted `X_FORWARDED_HOST` header can cause the regular expression engine to enter a state of catastrophic backtracking. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability All users running an affected release should either upgrade or use one of the workarounds immediately.

Circumvention of file size limits in ActiveStorage
There is a vulnerability in ActiveStorage's S3 adapter that allows the Content-Length of a direct file upload to be modified by an end user.

Versions Affected:  rails < 5.2.4.2, rails < 6.0.3.1
Not affected:       Applications that do not use the direct upload functionality of the ActiveStorage S3 adapter.
Fixed Versions:     rails >= 5.2.4.3, rails >= 6.0.3.1

Impact
------

Utilizing this vulnerability, an attacker can control the Content-Length of an S3 direct upload URL without receiving a new signature from the server. This could be used to bypass controls in place on the server to limit upload size.

Workarounds
-----------

This is a low-severity security issue. As such, no workaround is necessarily until such time as the application can be upgraded.

Path Traversal in Action View
# File Content Disclosure in Action View

Impact 
------ 
There is a possible file content disclosure vulnerability in Action View.  Specially crafted accept headers in combination with calls to `render file:`  can cause arbitrary files on the target server to be rendered, disclosing the  file contents. 

The impact is limited to calls to `render` which render file contents without  a specified accept format.  Impacted code in a controller looks something like this: 

``` ruby
class UserController < ApplicationController 
  def index 
    render file: "#{Rails.root}/some/file" 
  end 
end 
``` 

Rendering templates as opposed to files is not impacted by this vulnerability. 

All users running an affected release should either upgrade or use one of the workarounds immediately. 

Releases 
-------- 
The 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, and 4.2.11.1 releases are available at the normal locations. 

Workarounds 
----------- 
This vulnerability can be mitigated by specifying a format for file rendering, like this: 

``` ruby
class UserController < ApplicationController 
  def index 
    render file: "#{Rails.root}/some/file", formats: [:html] 
  end 
end 
``` 

In summary, impacted calls to `render` look like this: 

``` 
render file: "#{Rails.root}/some/file" 
``` 

The vulnerability can be mitigated by changing to this: 

``` 
render file: "#{Rails.root}/some/file", formats: [:html] 
``` 

Other calls to `render` are not impacted. 

Alternatively, the following monkey patch can be applied in an initializer: 

``` ruby
$ cat config/initializers/formats_filter.rb 
# frozen_string_literal: true 

ActionDispatch::Request.prepend(Module.new do 
  def formats 
    super().select do |format| 
      format.symbol || format.ref == "*/*" 
    end 
  end 
end) 
``` 

Credits 
------- 
Thanks to John Hawthorn <john@hawthorn.email> of GitHub

Possible Strong Parameters Bypass in ActionPack
There is a strong parameters bypass vector in ActionPack.

Versions Affected:  rails <= 6.0.3
Not affected:       rails < 5.0.0
Fixed Versions:     rails >= 5.2.4.3, rails >= 6.0.3.1

Impact
------
In some cases user supplied information can be inadvertently leaked from
Strong Parameters.  Specifically the return value of `each`, or `each_value`,
or `each_pair` will return the underlying "untrusted" hash of data that was
read from the parameters.  Applications that use this return value may be
inadvertently use untrusted user input.

Impacted code will look something like this:

```
def update
  # Attacker has included the parameter: `{ is_admin: true }`
  User.update(clean_up_params)
end

def clean_up_params
   params.each { |k, v|  SomeModel.check(v) if k == :name }
end
```

Note the mistaken use of `each` in the `clean_up_params` method in the above
example.

Workarounds
-----------
Do not use the return values of `each`, `each_value`, or `each_pair` in your
application.

Allocation of Resources Without Limits or Throttling
There is a possible denial of service vulnerability in Action View (Rails)  where specially crafted accept headers can cause action view to consume % cpu and make the server unresponsive.