[DRE-maint] Debian LTS Security update of ruby-rest-client (advice needed)

Wed May 25 20:47:58 UTC 2016

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 <ola at inguza.com> 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 <hertzog at debian.org>
> 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 ----
> /  ola at inguza.com                    Folkebogatan 26            \
> |  opal at debian.org                   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 ----
/  ola at inguza.com                    Folkebogatan 26            \
|  opal at debian.org                   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  /
 ---------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20160525/7bedfab2/attachment.html>