Hi Now I have been thinking about this a little more. I have now understood that there is one attack vector that I had not been thinking of. The session id length and its randomness is an important factor but the timing attack can exploit the database indexing functionality in order to reduce the session search space and thereby reduce the "search for all possible session ids" to something much smaller.
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. 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. 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. 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. Hope this helps. Best regards // Ola On Tue, 18 Feb 2020 at 10:12, Ola Lundqvist <o...@inguza.com> wrote: > Hi > > Precisely. This is why I was asking about the length of the session id > used. With the length we can estimate how many times an attacker my try to > find all possible values. > If this is small enough (and the attacker is close enough) it can be > exploited. But if the session key is really large, then there is no way > that this can be done in practice even with ears of tries. > > // Ola > > On Tue, 18 Feb 2020 at 09:50, Brian May <b...@debian.org> wrote: > >> Ola Lundqvist <o...@inguza.com> writes: >> >> > So regarding your throught about why Rack has this and not others. Well >> I >> > think all have the same issue. I think it is a little of a stretch that >> > this can be used in practice. I mean an attacker must do a broad search >> of >> > all possible session identifiers to make use of this. Or have I >> > misunderstood something? >> >> I suspect you are mostly correct. >> >> However how many people would really notice if an attacker made numerous >> connections to their website in attempt to exploit this? >> -- >> Brian May <b...@debian.org> >> > > > -- > --- Inguza Technology AB --- MSc in Information Technology ---- > | o...@inguza.com o...@debian.org | > | http://inguza.com/ Mobile: +46 (0)70-332 1551 | > --------------------------------------------------------------- > > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
