Hi again I have not heard any advice on this matter.
Do you think this problem is severe enough to include a new package in wheezy? Or do you think I should simply disable all cookies after being redirected? Or do you think we can skip this altogether? // Ola On Sun, May 22, 2016 at 12:02 AM, Ola Lundqvist <[email protected]> wrote: > 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, > > > On Fri, May 20, 2016 at 2:16 PM, Raphael Hertzog <[email protected]> > wrote: > >> On Fri, 20 May 2016, Antonio Terceiro wrote: >> > > I see two options: >> > > 1) I upload this fix above and we introduce the ruby-http-cookie (its >> > > dependencies are already there, I have tested with the jessie version >> of >> > > ruby-http-cookie on wheezy, so it is just to add this package too) >> > > 2) We tell that the fix is not important enough. >> > > I do not see the point in trying to change the correction in some >> other way >> > > for wheezy. >> > >> > Can you introduce new packages in LTS? If you can, then just doing that >> > and using the patch that was applied in jessie is probably good enough. >> >> Technically we can but we need a ftpmaster to process NEW on >> security.debian.org I guess. >> >> From a policy point of view, I have mixed feelings. It means the security >> upgrade might not be picked by "apt-get upgrade" due to the new >> dependency. >> >> Is the CVE severe enough to justify that extra work? >> >> Cheers, >> -- >> Raphaël Hertzog ◈ Debian Developer >> >> Support Debian LTS: http://www.freexian.com/services/debian-lts.html >> Learn to master Debian: http://debian-handbook.info/get/ >> > > > > -- > --- Inguza Technology AB --- MSc in Information Technology ---- > / [email protected] Folkebogatan 26 \ > | [email protected] 654 68 KARLSTAD | > | http://inguza.com/ Mobile: +46 (0)70-332 1551 | > \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / > --------------------------------------------------------------- > > -- --- Inguza Technology AB --- MSc in Information Technology ---- / [email protected] Folkebogatan 26 \ | [email protected] 654 68 KARLSTAD | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
