Hi
I have mixed feelings too. You have to make a dist-upgrade in order to make it take effect. On the other hand, that may be a good thing as admins will understand that there is a new dependency and in case they do not want it they have the possibility to keep the old one (at least for a while).
In any case I'll try to describe in what situations this vulnerability is a real problem (at least as I understand it).
What ruby-rest-client do is to send all cookies to the redirect target that was sent by the original target. This means that that the redirect target will get all the cookies for the original target regardless whether they are on the same domain or not. Essentially this means that anyone that can make a redirect to another site, can also steal all the cookies including session cookies.
Here are some more details:
UA makes a HTTP request to orig_url
Server responds with 301 redirect to target_url and a set-cookie header.
UA makes a new HTTP reqiest to target_url will all cookies in the set-cookie header from above.
Target_url should not get cookies from orig_url in case they are on different domains. In this case they do.
Is this a problem? In most cases no because:
- most redirects are from a link in one domain to another link in the same domain.
- people with authority to make http redirect are typically site admins on the original target and they could have the cookies anyway
- and finally because I do not think this software is generally used to fetch things that are redirected
- Not sure if set-cookie header is typically set in a http redirect.
So if you ask me the probability is low. However the impact could be quite high, that is account sessions can be hijacked.
There is also another alternative and that is to stop sending any cookies to the redirect target. That is the "hackish" solution, but that one may introduce a regression problem. However I think that may be better than to do nothing. At least if we have some sponsors using this software.
Is it worth it? Not sure. If our sponsors use this software, I guess yes, but I do not think it is critical either.
I think we should do it in the following priority order:
1) Make the update with new dependency (but as it is a new dependency and it may not be worth it maybe not)
2) Make an update that do not set any cookies to a redirect target (and clearly document this in the security advisory). If we do not think any sponsors use this software we could of course skip it.
3) No update at all
What do you think?
Cheers
// Ola
Quoting also the mail from Lucas Kanashiro here as I got two different opinions at about the same time:
Hi Ola,
I had a look in this package a couple of weeks ago and I found the same problem. I discussed it with Antonio and I think that we can skip this package instead of add a new dependency in wheezy. We guess that implement a cookie_jar "by hand" is not a good idea :)
Cheers,