1804209 - Bugzilla Privilege Escalation Issue.

Status: UNCONFIRMED

(Bugzilla :: Bugzilla-General, defect)

Description

[Sandeep A.S]

Attachment: Bugzillaa-VAPT.pdf

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:107.0) Gecko/20100101 Firefox/107.0

Steps to reproduce:

By copying Bugzilla login session id and login cookie name of the admin user in a normal login session, normal user is able to get administrative privilege.
More details are available in the attachement.

Actual results:

A low-privileged user, by parameter manipulation, can perform malicious activities
posing as another user. By parameter manipulation user can view/edit ticket raised by another user or even the administrative privilege.

Expected results:

Login session id and cookie name should have been mapped and one user should not be allowed to access other users session information.

Comment 1

[Sandeep A.S]

My test installation at https://bugzilla.fcoos.net can be used to test this if required.

Comment 2

[:glob ✱]

Looks like you're reporting an issue with Bugzilla itself, not bugzilla.mozilla.org (which runs a highly modified version of Bugzilla); moving bug.

This bug is invalid; of course if you have access to the bit of information that is used to track sessions then you can perform actions as that user. This is equivalent to filing a security issue stating that if you know another user's password you can log in as them.

If you can access another user's cookie without first authenticating as them then it would be a security issue; that isn't the case here.

Comment 3

[Sandeep A.S]

I agree this is plain logic and common sense.

Comment 4

[Dave Miller [:justdave]]

Since this was determined to not be a security issue, I'm removing the security flag.

Comment 5

[Sandeep A.S]

Here I am seeing a potential risk.
Since the Bugzilla cookie session id is static, a compromised browser can
be used to get the privilege escalation and get admin access.
This is a potential risk. Enabling random session id will help to overcome this.
This is the suggestion given to us.
Our Audit team is not allowing to make Bugzilla to production as they
marked this issue as High security bug.

Comment 6

[Dave Miller [:justdave]]

How is a random session ID generally implemented? Does that just mean re-issuing a new session token and invalidating the old one on each request or something?

Comment 7

[:glob ✱]

I think this is still invalid.

While we can do what we can to prevent attacks (eg. CSP, CSRF, 2FA, attachment control) once a browser is compromised then there's no way to completely protect the system from attacks. For example a bad actor could install an addon that captures all data in real time.

You could mitigate concerns by adjusting the unused cookie lifetime - reducing it down to a day might help address concerns assuming that you can deal with the usability impact this would impose.