Re: Issues regarding ruby-rack/CVE-2019-16782

[Brian May <bam@debian.org>]

Ola Lundqvist <ola@inguza.com> writes:

> Interesting. I think the upstream solution to search first for private id
> and then for public id is good enough for Debian stable releases.
> It should be extremely difficult (unless the computer is really slow) to
> calculate the timing for the public id part since there are so many other
> variables like link speed, process switching time and other that will cause
> delays on the same magnitude.
>
> For unstable, maybe a more secure solution is better.
>
> What I think we need to do however is to make a correction without changing
> to the more complex object to avoid breakage. Would that be a lot of work
> to do that?

It is easy to make the complex object auto cast to a string. The problem
is what string should it return?

Should it return the public string? The applications that expect to be
able to use that string to look up session data will break.

Should it return the private string?

Upstream says that this runs the risk of leaking the private key "The
public id is ok for anyone to know, and the private id must be kept
secret." This argument confuses me as the private key is just a hash of
the public key, it seems anybody with the public key can obtain the
private key. Wonder if I misunderstood something here?

def hash_sid(sid)
    Digest::SHA256.hexdigest(sid)
end

def private_id
    "#{ID_VERSION}::#{hash_sid(public_id)}"
end

Depending on what the application does the with session id however, just
blindly returning the private id might not always be the correct thing
either.

Plus now, as applications are adapting to this new API anyway, if we
change this now we could break applications that use the new API.

Django, does a lookup of the Session table using a Session key - which I
believe comes from an untrusted cookie. Probably many others too. Does
this mean Django is equally vulnerable? Or maybe Django already done
something to mitigate against this? I don't see anything.

https://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py

This is the default session backend, others are also available:
https://docs.djangoproject.com/en/3.0/topics/http/sessions/#configuring-sessions
-- 
Brian May <bam@debian.org>