Re: Issues regarding ruby-rack/CVE-2019-16782
I would have understood the upstream argument if the public key is a hash of the private one. If it is the other way around (as you describe it) I do not see any point.
That would even be a new CVE, because that is a security issue, really.
I think it should return the public key and the public key should be a hash of the private one.
Ola Lundqvist <firstname.lastname@example.org> 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?
Depending on what the application does the with session id however, just
blindly returning the private id might not always be the correct thing
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.
This is the default session backend, others are also available:
Brian May <email@example.com>
--- Inguza Technology AB --- MSc in Information Technology ----