Re: [CVE-2019-16782] Possible Information Leak / Session Hijack Vulnerability in Rack

["Alexander E. Patrakov" <patrakov () gmail com>]

On Wed, Dec 18, 2019 at 11:17 PM Aaron Patterson
<aaron.patterson () gmail com> wrote:
> There is a possible information leak / session hijacking vulnerability
> in Rack. This vulnerability has been assigned the CVE identifier
> CVE-2019-16782.
>
> Versions Affected:  All.
> Not affected:       None.
> Fixed Versions:     1.6.12, 2.0.8
>
> There's a possible information leak / session hijack vulnerability in
> Rack. Attackers may be able to find and hijack sessions by using timing
> attacks targeting the session id. Session ids are usually stored and
> indexed in a database that uses some kind of scheme for speeding up
> lookups of that session id. By carefully measuring the amount of time it
> takes to look up a session, an attacker may be able to find a valid
> session id and hijack the session.
>
> 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.

I don't understand why this is reported as something Rack-specific.

If I read the patch correctly (which is improbable, as I don't know
Ruby at all), the idea is:

1. The attacker could send various bogus session ids, starting with
all possible valid bytes. The database, if it uses a trie (yes,
strawman example - is it used by any real-world database?) as a data
structure to speed up looking up sessions, will terminate the
comparison early on invalid bytes, thus disclosing them.
2. Given one valid byte of a session id, the attacker tries to extend
it using the same procedure.
3. At the end, the attacker will get a full session ID.

The patch works by making the thing stored in the database as a key
not the session ID in the cookie, but a hash of it. Therefore, step 2
fails, as it is computationally hard to find something with a given
prefix.

On the other hand, I don't see how a timing attack would be possible
on the most common data structures (B-Tree and Hash) used for database
indexes.

-- 
Alexander E. Patrakov