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