[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Issues regarding ruby-rack/CVE-2019-16782


Thank a lot for the explanation. Yes that was a little of an unfortunate naming. In any case it does not matter so much.

Some thoughts.

1) It should be possible to change all entries in the session database from the session id (public_id) to the hashed variant to retain all sessions. This assumes that there is some kind of upgrade function that is run when the software is upgraded.

2) Database queries are fairly constant. But sure it is probably possible to do this timing attach, at least when the attacher is really close to the server.

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?

Best regards

// Ola

On Fri, 14 Feb 2020 at 06:01, Brian May <bam@debian.org> wrote:
Ola Lundqvist <ola@inguza.com> writes:

> I would have understood the upstream argument if the public key is a hash
> of the private one. If it is the other way around (as you describe it) I do
> not see any point.
> That would even be a new CVE, because that is a security issue, really.
> I think it should return the public key and the public key should be a hash
> of the private one.

I do think the names upstream has chosen for these variables is rather

public/private makes it seem like public key cryptography, where there
is a public key, and it is safe for *anybody* to know this value
(depending on how much you trust the cryptography that is).

Not the case here. If you hashed the private id to create the public id
you would still need to keep the public id secret. But that wouldn't
work, because you couldn't lookup the session in the database using the
public key.

"public_id" is the secret session key that is stored in a cookie on the
user's browser. It must remain secret at all times, just like any
session key. It gives the holder unlimited access to the session.

Normally we would lookup the session directly in the database as in
query(public_id). However, as the attacker can carefully control the
input and time how long it takes, this can lead to timing attacks.

So instead we hash the public_id first. As in query(hash(public_id)).
Now an attacker has problems carefully controlling the input to the
database query, and this makes it hard (or impossible?) to do a timing
based attack.

Upstream has decided to call this hashed value the private key. As in

private_id = hash(public_id)

I think this is unfortunate terminology. Possibly it
external_id/internal_id would be better. However I think we are stuck
with it now.

If there was an SQL operation that allowed us to do a query with a fixed
time, that would also solve the problem. Unfortunately, I don't think
there is such a thing. It has already been the goal for SQL databases to
make these queries as fast as possible.

Does this help explain things?

I am still unclear why Rack has this issue, and not other libraries that
do a similar lookup of an untrusted key value provided by the user in
the database, e.g. Django.
Brian May <bam@debian.org>

 --- Inguza Technology AB --- MSc in Information Technology ----
|  ola@inguza.com                    opal@debian.org            |
|  http://inguza.com/                Mobile: +46 (0)70-332 1551 |

Reply to: