Ola Lundqvist <o...@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 <b...@debian.org>
