Ola Lundqvist <ola@inguza.com> 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.
Agreed.
> 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
anyway.
> 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)
http://blog.remarkablelabs.com/2012/12/activerecord-sessionstore-gem-extraction-rails-4-countdown-to-2013
--
Brian May <bam@debian.org>