The rest-client team discovered a vulnerability which has now been fixed in rest-client 1.8.0. https://rubygems.org/gems/rest-client/versions/1.8.0 https://github.com/rest-client/rest-client/issues/369 The problematic behavior was introduced in rest-client 1.6.1: any Set-Cookie headers present in an HTTP 30x redirection response are blindly sent to the redirection target, regardless of domain, path, expiration, or secure cookie settings. All subsequent 1.6.x and 1.7.x releases are affected. Similarly to the issue with python-requests (CVE-2015-2296), the issue could be exploited in the following ways: - If you are the redirection source (i.e. you can make rest-client hit your URL), you can make rest-client perform a request to any third-party domain with cookies of your choosing. This may be useful in performing a session fixation attack. - If you are the redirection target (i.e. you can make a third-party site redirect to your URL), you can steal any cookies set by the third-party redirection.
Created rubygem-rest-client tracking bugs for this issue: Affects: fedora-all [bug 1205294]
Upstream patch: https://github.com/rest-client/rest-client/commit/c215b22bdbcb988dcc40117ff45432b0db25175b
The full patch is three commits: https://github.com/rest-client/rest-client/pull/365.patch
There are two ways this issue can be exploited: - If you are the redirection source (i.e. you can make rest-client hit your URL), you can make rest-client perform a request to any third-party domain with cookies of your choosing. This may be useful in performing a session fixation attack. This means vulnerable product we ship must make request to malicious site (to get fixated cookie) AND upon getting redirect log in to the victim site (using attacker supplied cookie) AND we assume the product uses cookies to authenticate with victim site AND that victim site does not reset session after login (i.e. is vulnerable to session fixation). - If you are the redirection target (i.e. you can make a third-party site redirect to your URL), you can steal any cookies set by the third-party redirection. This means vulnerable product we ship must make a request to vulnerable site AND attacker must arrange vulnerable site redirects to his malicious one AND we assume the product uses cookies to authenticate with victim site. Based on the above analysis, the security implications of this issue are quite minimal.