302487 - SECURITY: session-stealing / impersonation of other users possible if you have read access to logincookies

Status: RESOLVED WONTFIX

(Bugzilla :: User Accounts, defect)

Description

[Stephen Lee]

A well-known problem with no bug specifically addressing it... mentioned in bug
119524, and follows on from it. The solution being looked at for that bug
prevents someone *guessing* the session ID. This one will prevent someone
reading it from a copy of the database.

At present, all the information necessary to impersonate a user and steal their
session is in the logincookies table.

A user who can:
a) read the logincookies table
b) generate a connection that appears to come from the same IP (block) as one of
the rows in that table (easy if it is a transparent proxy of a large ISP etc.).

will be able to create cookies matching the details in the table and steal the
other user's session, and can therefore impersonate the chosen victim.


To prevent this, the logincookies table should not store the cookie ID. Instead
it should store a cryptographic hash of something like (salt,cookie,userid) as
cryptcookie.
[Question: is it considered ok to use e.g. the same salt as from the password
for all cookies belonging to a user, or will that reduce security somewhere?]

On connecting, the client would supply (cookie,userid) as at present, allowing
the server to calculate the hash of (salt,cookie,userid) using this info and
salt it looked up. If this hash matches a cryptcookie in its logincookies table,
then authentication proceeds as at present (matching cryptcookie after this fix
is equivalent to matching cookie before the fix).

This would mean that even if you can read the logincookies table, you can no
longer generate a cookie that bugzilla would accept, giving one less thing to
worry about when making backups of the database etc.

Comment 1

[Max Kanat-Alexander]

I can hardly imagine a scenario where somebody has read access to the Bugzilla database, but isn't a fully-trusted Bugzilla administrator.

Comment 2

[Stephen Lee]

(In reply to comment #1)
> I can hardly imagine a scenario where somebody has read access to the Bugzilla
> database, but isn't a fully-trusted Bugzilla administrator.

Doesn't need to necessarily be read access to the live database - it could be a recent backup. I believe there's a reason we don't store passwords unencrypted in the database... the same reasoning applies to details of cookies, as a valid cookie is considered as good as a password for most changes.

Currently the logincookies table stores *in the clear* all of the information required to impersonate another user. To an attacker that can access bugzilla using, or appearing to use a similar IP to at least one "interesting" user, this is almost as good as having plaintext passwords. (Especially easy if its a proxy / firewall of a large ISP or a wireless access point or a dynamic IP from a relatively small pool to which the attacker has access ...)


(In fact, at present the attacker doesn't even need read access to the DB, and can guess a cookie ID, but that's bug 119524).

Comment 3

[Robert Chapin]

I agree with Max.  In a situation where the server is compromised, cookies will be the least of your concerns.

Comment 4

[Frédéric Buclin]

WONTFIX?

Comment 5

[Max Kanat-Alexander]

Yeah, WONTFIX. I think our random cookies are protection enough, and anybody who's server has been compromised can safely just clear the whole logincookies table if they have to.