[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN_LGv17OG6JB-dm+t62WbDJajEAdik+fncnownEvrv+NUSvoQ@mail.gmail.com>
Date: Thu, 19 Dec 2019 00:33:59 +0500
From: "Alexander E. Patrakov" <patrakov@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: [CVE-2019-16782] Possible Information Leak /
Session Hijack Vulnerability in Rack
On Wed, Dec 18, 2019 at 11:17 PM Aaron Patterson
<aaron.patterson@...il.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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
