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.

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.

Untrusted users able to run pending migrations in production
There is a vulnerability in versions of Rails prior to 6.0.3.2 that allowed
an untrusted user to run any pending migrations on a Rails app running in
production.

This vulnerability has been assigned the CVE identifier CVE-2020-8185.

Versions Affected:  6.0.0 < rails < 6.0.3.2
Not affected:       Applications with `config.action_dispatch.show_exceptions = false` (this is not a default setting in production)
Fixed Versions:     rails >= 6.0.3.2

Impact
------

Using this issue, an attacker would be able to execute any migrations that
are pending for a Rails app running in production mode. It is important to
note that an attacker is limited to running migrations the application
developer has already defined in their application and ones that have not
already ran.

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

Until such time as the patch can be applied, application developers should
disable the ActionDispatch middleware in their production environment via
a line such as this one in their config/environment/production.rb:

`config.middleware.delete ActionDispatch::ActionableExceptions`

Session fixation vulnerability via Set-Cookie headers
The package rest-client in `abstract_response.rb` improperly handles `Set-Cookie` headers on HTTP redirection responses. Any cookies will be forwarded to the redirection target regardless of domain, path, or expiration. If you control a redirection source, you can cause rest-client to perform a request to any third-party domain with cookies of your choosing, which may be useful in performing a session fixation attack. If you control a redirection target, you can steal any cookies set by the third-party redirection request.

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.

Possible information leak / session hijack vulnerability
There's a possible information leak / session hijack vulnerability in Rack.

Attackers may be able to find and hijack sessions by using timing attacks
targeting the session id. Session ids are usually stored and indexed in a
database that uses some kind of scheme for speeding up lookups of that
session id. By carefully measuring the amount of time it takes to look up
a session, an attacker may be able to find a valid session id and hijack
the session.

The session id itself may be generated randomly, but the way the session is
indexed by the backing store does not use a secure comparison.

Impact:

The session id stored in a cookie is the same id that is used when querying
the backing session storage engine.  Most storage mechanisms (for example a
database) use some sort of indexing in order to speed up the lookup of that
id.  By carefully timing requests and session lookup failures, an attacker
may be able to perform a timing attack to determine an existing session id
and hijack that session.

Timing attack vulnerability
Sinatra rack-protection contains a timing attack vulnerability in the CSRF token checking that can result in signatures can be exposed. This attack appear to be exploitable via network connectivity to the ruby application.

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

Potential XSS vulnerability in Action View
There is a potential Cross-Site Scripting (XSS) vulnerability in Action
View's translation helpers. Views that allow the user to control the
default (not found) value of the `t` and `translate` helpers could be
susceptible to XSS attacks.

Impact
------

When an HTML-unsafe string is passed as the default for a missing
translation key [named `html` or ending in `_html`](https://guides.rubyonrails.org/i18n.html#using-safe-html-translations),
the default string is incorrectly marked as HTML-safe and not escaped.
Vulnerable code may look like the following examples:

```erb
<%# The welcome_html translation is not defined for the current locale: %>
<%= t("welcome_html", default: untrusted_user_controlled_string) %>

<%# Neither the title.html translation nor the missing.html translation is defined for the current locale: %>
<%= t("title.html", default: [:"missing.html", untrusted_user_controlled_string]) %>
```

Workarounds
-----------
Impacted users who can’t upgrade to a patched Rails version can avoid
this issue by manually escaping default translations with the
`html_escape` helper (aliased as `h`):

```erb
<%= t("welcome_html", default: h(untrusted_user_controlled_string)) %>
```