When starting a sudo session, the password is not validated

RESOLVED FIXED in Bugzilla 4.4

Status

()

Bugzilla
Administration
--
major
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Christophe JAILLET, Assigned: Frédéric Buclin)

Tracking

({regression})

4.4.3
Bugzilla 4.4
regression
Bug Flags:
approval +
approval5.0 +
blocking5.0 +
approval4.4 +
blocking4.4.9 +

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150122214805

Steps to reproduce:

When I impersonate a user, I'm requested a password before beginning the session.

However, even if I leave the password empty, the session is stared without any trouble. It is as if the password was not checked at all.

I've seen issues in bugzilla related to the use of LDAP. In my case, I use LDAP.
(Assignee)

Comment 1

2 years ago
I can reproduce the issue on 4.4.8 and master. 4.2.x and older are not affected.
Assignee: general → administration
Group: bugzilla-security
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: Bugzilla-General → Administration
Ever confirmed: true
Flags: blocking5.0?
Flags: blocking4.4.9?
Keywords: regression
Target Milestone: --- → Bugzilla 4.4
(Assignee)

Comment 2

2 years ago
Looks like I regressed this in Bugzilla 4.4.3 due to bug 713926.
Depends on: 713926
Version: 4.4.7 → 4.4.3
(Assignee)

Comment 3

2 years ago
Ah, I found what the problem is. In relogin.cgi, when we generate login_request_token, the impersonator is already logged in, and so his user ID is used as data to generate the token. But when we validate the token after the form submission, the user is not yet authenticated, and so his user ID is not yet known, and issue_hash_token() falls back to the IP address as data. This means that the generated token doesn't match the initial one, and the validation fails, and so the Bugzilla::Auth system falls back to the existing login cookie of the impersonator, which exists and is valid, which is why the password is silently ignored.
Assignee: administration → LpSolit
Status: NEW → ASSIGNED
(Assignee)

Comment 4

2 years ago
Created attachment 8564457 [details] [diff] [review]
patch, v1

We must momentarily unset the user ID when generating the token as this information is not available when authenticating the user credentials.
Attachment #8564457 - Flags: review?(dkl)
(Assignee)

Comment 5

2 years ago
Decreasing the severity based on the discussion which took place in bug 502649. mkanat suggested to drop this extra password check before starting a sudo session. The impersonator must already be logged in and must have the required privs, and so this regression doesn't let you abuse Bugzilla to become an impersonator if you don't already have the required privs.
Severity: critical → major
Comment on attachment 8564457 [details] [diff] [review]
patch, v1

Review of attachment 8564457 [details] [diff] [review]:
-----------------------------------------------------------------

r=dkl
Attachment #8564457 - Flags: review?(dkl) → review+

Updated

2 years ago
Flags: approval?
Flags: approval5.0?
Flags: approval4.4?
Flags: blocking5.0?
Flags: blocking5.0+
Flags: blocking4.4.9?
Flags: blocking4.4.9+
Flags: approval?
Flags: approval5.0?
Flags: approval5.0+
Flags: approval4.4?
Flags: approval4.4+
Flags: approval+
(Assignee)

Comment 7

2 years ago
To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   9f76caa..10aa3f0  master -> master

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   b4c5ed1..c473640  5.0 -> 5.0

To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   24b471d..0a18f0f  4.4 -> 4.4
Group: bugzilla-security
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Summary: Impersonate does not check the confirmation password requested before Starting the session → When starting a sudo session, the password is not validated
You need to log in before you can comment on or make changes to this bug.