Re: Issues regarding ruby-rack/CVE-2019-16782
Ola Lundqvist <ola@inguza.com> writes:
> I have looked into this some but I have not been able to determine how long
> the session ids were before the fix. Do anyone have that information?
> Based on that we can rather easily determine how long time a timing attack
> would take. My guess is a really long time.
The more I look into this issue, the more I get confused. In summary, it
seems to be a rather complicated fix for something which I would imagine
to be very simple, and this is making me nervous about trying to come up
with my own simple patch.
>From https://github.com/advisories/GHSA-hrqr-hxpp-chr3:
"Session ids are usually stored and indexed in a database that uses some
kind of scheme for speeding up lookups of that session id."
"The session id itself may be generated randomly, but the way the
session is indexed by the backing store does not use a secure
comparison."
It appears to be talking about the lib/rack/session/pool.rb pool method
of storing sessions.
... but I believe this stores the sessions in a in-memory hash table,
not the database. From the comment at the top of the file:
# Rack::Session::Pool provides simple cookie based session management.
# Session data is stored in a hash held by @pool.
# In the context of a multithreaded environment, sessions being
# committed to the pool is done in a merging manner.
Also, I am not seeing any code that allows the hash to be stored to a
disk file or a database of any kind (did I miss something?)
OK, so maybe we can conduct a timing attack against an in hash. As well
as a database (??). Lets assume we can.
Why do they even need to worry about checking the unhashed id in the
hash table? When you upgrade it will kill the previous processes, which
will kill the previous hash table, and no previous sessions will be
valid anymore anyway. As far as I am aware it is not possible to upgrade
a ruby process without restarting everything.
Another possibility is that the researchers were more concerned about
backends such as "memcache" rather then "cookie" or "pool". However the
change that I can find in upstream only seems to be concerned with the
"pool" backend.
https://github.com/rack/rack/commit/7fecaee81f59926b6e1913511c90650e76673b38
Possibly this is because the memcache method was deprecated and moved to
another gem:
https://github.com/rack/rack/commit/54600771e3c9628c873fb1140b800ebb52f18e70#diff-ec7f0fcff10d701615d85df33fbbd545
Which replaces Memcache with Dalli instead. I have no idea if Dalli has
been appropriately patched to deal with CVE-2019-16782.
--
Brian May <bam@debian.org>
Reply to: