Re: Issues regarding ruby-rack/CVE-2019-16782
- To: Ola Lundqvist <firstname.lastname@example.org>, Ola Lundqvist <email@example.com>
- Cc: Utkarsh Gupta <firstname.lastname@example.org>, Debian Security Team <email@example.com>, Debian LTS <firstname.lastname@example.org>
- Subject: Re: Issues regarding ruby-rack/CVE-2019-16782
- From: Brian May <email@example.com>
- Date: Tue, 10 Mar 2020 17:38:45 +1100
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <CABY6=0mHZVVo-oi4ghtZNEzRZdgKHir9WwYb8qLR-D8s5UzK5Q@mail.gmail.com>
- References: <email@example.com> <firstname.lastname@example.org> <CABY6=0mXd6jV1Dpb-X=CUZOpakC1CekGNOvOQK+MYy4ZjZtoUw@mail.gmail.com> <email@example.com> <CABY6=0kovrOPLyRgKOUp-0McC=VpBgawqDMBosjL81qq2on-EA@mail.gmail.com> <firstname.lastname@example.org> <CABY6=0nTzFzcHfcJkCOafp+HAZ0wiVMKgHQzJS1OzEu0iYemail@example.com> <firstname.lastname@example.org> <CABY6=0krVCyAwf=M0njTNbCW_Lj5JeeNK1Aksnj8VZJ52_GJjA@mail.gmail.com> <email@example.com> <CABY6=0=ZO1mtPDH3cL1h+gT0LwR48OfkxuwSLW3A1MnjVer8bA@mail.gmail.com> <CABY6=0mHZVVo-oi4ghtZNEzRZdgKHir9WwYb8qLR-D8s5UzK5Q@mail.gmail.com>
Ola Lundqvist <firstname.lastname@example.org> writes:
> I think the attacker needs to be very close, or at least on a connection to
> the server with a very predictable timing making a live server exploit
> difficult from a distance. Potentially possible.
Yes, very likely. Unless the database is loaded, but that too could be
another variable that makes this attack difficult.
> This is a general problem for most kind of services and I do not think it
> is limited to ruby-rack. It just happen to be so that we have a specific
> CVE for ruby-rack. Others may have exactly the same issue.
> The solution to look up the hash of the session id makes sense. It makes
> things much harder to exploit.
> The best solution as I see it is to do one the following:
> alternative 1:
> At upgrade change all database session keys to the hash(key) and then only
> lookup using the hash of the session id key.
> There is no need to change the interface at all as I can see it.
This would be my preference. As I have mentioned before, upstream were
concerned this might break applications.
The details given here -
https://github.com/rack/rack/issues/1432#issuecomment-571688819 - don't
entirely make sense to me. e.g. "The private id could be leaked" - if
the public id is leaked, then it is easy to generate the private id
> alternative 2:
> No change at upgrade. At lookup look for the hash(key) and if that fails
> look for the key. To improve the security we can introduce a random delay
> between 0 and ... well the time a lookup take worst case.
> Still no reason to change the interface as I see it.
Yes, this is what upstream did, apart from the "not change the
interface" or "introduce a random delay".
> alternative 3:
> Do as upstream. The problem is that upstream introduced an API change in a
> non-backwards compatible way. This works for unstable, but I do not think
> it is preferred for oldstable, oldoldstable or stable.
> Which one to choose. I think alternative 1 is the most secure option but
> the upgrade may be complicated and is a little fault prone. I think
> alternative 2 is good enough, especially with some random delay.
Like I said, I am struggling to understand why upstream feels they need
to keep track of two separate ids, or why not just hash the key before
each database lookup.
I am finding it hard to visualise an application that would use the
session id in such a way that it would break if we hash it before
looking up the database.
I am not familiar with Ruby coding standards, Maybe existing Ruby code
can do "interesting things" such as direct lookups in the session database
using the session key?
Also I noticed - and thought interesting - that storing sessions in the
database was considered using rails (not rack being discussed here) was
deprecated in 2012)
Brian May <email@example.com>