Package Instance

Possible Input Validation Circumvention
Code that uses Active Model based models (including Active Record models) and does not validate user input before passing it to the model can be subject to an attack where specially crafted input will cause the model to skip validations. Rails users using Strong Parameters are generally not impacted by this issue as they are encouraged to allow parameters and must specifically opt-out of input verification using the `permit!` method to allow mass assignment.

Rails Denial of Service vulnerability
Unspecified vulnerability in the "dependency resolution mechanism" in Ruby on Rails 1.1.0 through 1.1.5 allows remote attackers to execute arbitrary Ruby code via a URL that is not properly handled in the routing code, which leads to a denial of service (application hang) or "data loss," a different vulnerability than CVE-2006-4111.

Possible Information Leak Vulnerability
Applications that pass unverified user input to the `render` method in a controller may be vulnerable to an information leak vulnerability. Impacted code will look something like this: ``` def index; render params[:id]; end ``` Carefully crafted requests can cause the above code to render files from unexpected places like outside the application's view directory, and can possibly escalate this to a remote code execution attack.

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.