Package Instance

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.

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

Versions Affected:  rails <= 6.0.3
Not affected:       rails < 4.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.

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

Ability to forge per-form CSRF tokens given a global CSRF token
It is possible to possible to, given a global CSRF token such as the one
present in the authenticity_token meta tag, forge a per-form CSRF token for
any action for that session.

Versions Affected:  rails < 5.2.5, rails < 6.0.4
Not affected:       Applications without existing HTML injection vulnerabilities.
Fixed Versions:     rails >= 5.2.4.3, rails >= 6.0.3.1

Impact
------

Given the ability to extract the global CSRF token, an attacker would be able to
construct a per-form CSRF token for that session.

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

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

Potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore
There is potentially unexpected behaviour in the MemCacheStore and RedisCacheStore where, when
untrusted user input is written to the cache store using the `raw: true` parameter, re-reading the result
from the cache can evaluate the user input as a Marshalled object instead of plain text. Vulnerable code looks like:

```
data = cache.fetch("demo", raw: true) { untrusted_string }
```

Versions Affected:  rails < 5.2.5, rails < 6.0.4
Not affected:       Applications not using MemCacheStore or RedisCacheStore. Applications that do not use the `raw` option when storing untrusted user input.
Fixed Versions:     rails >= 5.2.4.3, rails >= 6.0.3.1

Impact
------

Unmarshalling of untrusted user input can have impact up to and including RCE. At a minimum,
this vulnerability allows an attacker to inject untrusted Ruby objects into a web application.

In addition to upgrading to the latest versions of Rails, developers should ensure that whenever
they are calling `Rails.cache.fetch` they are using consistent values of the `raw` parameter for both
reading and writing, especially in the case of the RedisCacheStore which does not, prior to these changes,
detect if data was serialized using the raw option upon deserialization.

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

It is recommended that application developers apply the suggested patch or upgrade to the latest release as
soon as possible. If this is not possible, we recommend ensuring that all user-provided strings cached using
the `raw` argument should be double-checked to ensure that they conform to the expected format.

Improper Input Validation
A remote code execution vulnerability in development mode Rails can allow an attacker to guess the automatically generated development mode secret token. This secret token can be used in combination with other Rails internals to escalate to a remote code execution exploit.

CSRF Vulnerability in rails-ujs
There is an vulnerability in rails-ujs that allows attackers to send
CSRF tokens to wrong domains.

Versions Affected:  rails <= 6.0.3
Not affected:       Applications which don't use rails-ujs.
Fixed Versions:     rails >= 5.2.4.3, rails >= 6.0.3.1

Impact
------

This is a regression of CVE-2015-1840.

In the scenario where an attacker might be able to control the href attribute of an anchor tag or
the action attribute of a form tag that will trigger a POST action, the attacker can set the
href or action to a cross-origin URL, and the CSRF token will be sent.

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

To work around this problem, change code that allows users to control the href attribute of an anchor
tag or the action attribute of a form tag to filter the user parameters.

For example, code like this:

    link_to params

to code like this:

    link_to filtered_params

    def filtered_params
      # Filter just the parameters that you trust
    end

Possible DoS Vulnerability in Active Record PostgreSQL adapter
There is a possible DoS vulnerability in the PostgreSQL adapter in Active
Record. This vulnerability has been assigned the CVE identifier CVE-2021-22880.

Versions Affected:  >= 4.2.0
Not affected:       < 4.2.0
Fixed Versions:     6.1.2.1, 6.0.3.5, 5.2.4.5

Impact
------
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.

Workarounds
-----------
In the case a patch can't be applied, the following monkey patch can be used
in an initializer:

```
module ActiveRecord
  module ConnectionAdapters
    module PostgreSQL
      module OID # :nodoc:
        class Money < Type::Decimal # :nodoc:
          def cast_value(value)
            return value unless ::String === value

            value = value.sub(/^\((.+)\)$/, '-\1') # (4)
            case value
            when /^-?\D*+[\d,]+\.\d{2}$/  # (1)
              value.gsub!(/[^-\d.]/, "")
            when /^-?\D*+[\d.]+,\d{2}$/  # (2)
              value.gsub!(/[^-\d,]/, "").sub!(/,/, ".")
            end

            super(value)
          end
        end
      end
    end
  end
end
```

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.