720746 - Security advisory for Bugzilla 4.2rc2, 4.0.4, 3.6.8 and 3.4.14

Status: RESOLVED FIXED

(Bugzilla :: bugzilla.org, defect)

Description

[Frédéric Buclin]

We have two security bugs fixed in these releases: bug 714472 and bug 718319.

Comment 1

[David Lawrence [:dkl]]

Attachment: 3.4.13 sec advisory (v1)

Comment 2

[Frédéric Buclin]

Comment on attachment 591940 [details]
3.4.13 sec advisory (v1)

>* Since Bugzilla allows utf8 in email addresses it was possible for 
>  an attacker to impersonate another user or even gain access to the
>  user's account.

It's wrong to say that an attacker can gain access to the user's account. He has no way to do that. The only problem is that someone else could be confused by his email address when e.g. CC'ing him. Also, the wording makes us think that Bugzilla intentionally accepts UTF8 in email address, which is not true. I would suggest something like:

"When a user creates a new account, Bugzilla doesn't correctly reject email addresses containing non-ASCII characters, which could be used to impersonate another user account."


>* A CSRF vulnerabilty using specially formatted HTML attachments 
>  could allow jsonrpc.cgi POST requests be made to make changes to bugs 
>  as another user.

No need for an HTML attachment. A simple HTML page on another website would do it. Also, making changes to bugs is not the single threat. I would suggest something like:

"A CSRF vulnerability in the implementation of the JSON-RPC API could be used to make changes to bugs or execute some admin tasks without the victim's knowledge."



>Vulnerability Details
>=====================
>
>Class:       Account Compromise

Your account is not compromised, see my comment above.


>Versions:    2.17.1 to 3.4.13, 3.5.1 to 3.6.7, 3.7.1 to 4.0.3,
>             4.1.1 to 4.1.4

Versions before 2.17.1 are also vulnerable. We never restricted email addresses to be ASCII only. So it should say 2.0 to 3.4.13. Also, it must say 4.1.1 to 4.2rc1.


>Description: Bugzilla allows utf8 in email addresses, including characters 
>             in the Cryllic alphabet that look identical to standard ascii 
>             letters. Given that email addresses are used as usernames, this 
>             poses an impersonation risk. It could also be used by an attacker 
>             to maintain access to a victim's account, since their email 
>             address wouldn't appear to have changed.

Don't simply copy and paste the description of the issue written by the reporter. There is no evidence that you can get access to the victim's account, and I think this statement is wrong. I would suggest:

"When a user creates a new account, Bugzilla doesn't correctly reject email addresses containing non-ASCII characters, which could be used to impersonate another user account. Such email addresses could look visually identical to other valid email addresses, and an attacker could try to confuse other users and be added to bugs he shouldn't have access to.



>References:  ttps://bugzilla.mozilla.org/show_bug.cgi?id=714472

s/ttps/https/


>Versions:    3.5.1 to 3.6.7, 3.7.1 to 4.0.3, 4.1.1 to 4.1.4

Must be 4.1.1 to 4.2rc1.


>Description: When making a POST requests using jsonrpc.cgi using certain 
>             content-types in specially formatted HTML attachments, an

As said above, this is not a vulnerability in HTML attachments. Any HTML page with evil code in it could do it, even outside Bugzilla.


>             attacker could potentially make changes to bugs on other sites 
>             as if the user had made the change. The user would have had 
>             to be already logged in to the other site for the vulnerability 
>             to work properly.

Also specify that Bugzilla didn't check the value of the Content-Type header. Maybe start the description with:

"Due to a lack of validation of the Content-Type header, a CSRF vulnerability...."


>Credits
>=======

We traditionally only credit the following people, in this order: assignees, reviewers, reporters. In our case, this means:

Frédéric Buclin
Max Kanat-Alexander
Byron Jones
Mario Gomes
James Kettle

Comment 3

[David Lawrence [:dkl]]

Attachment: 3.4.13 sec advisory (v2)

Thanks for the wording help. Here is a new version which addresses the changes.

dkl

Comment 4

[Frédéric Buclin]

Comment on attachment 592298 [details]
3.4.13 sec advisory (v2)

>Class:       Account Impersonation 
>Versions:    2.0 to 3.4.13, 3.5.1 to 3.6.7, 3.7.1 to 4.0.3,
>             4.1.1 to 4.1.4

4.1.1 to 4.2rc1!


>Description: A CSRF vulnerability due to a lack of validation of the Content-Type 
>             header when making POST requests to jsonrpc.cgi, an attacker could 
>             potentially make changes to bugs on other sites as if the user had 
>             made the change.

This sentence seems incorrectly built to me. The first part has no verb. Also, "other sites" is too vague. Readers won't understand which sites you are talking about.


Also, please remove all these extra whitespaces you left at the end of almost every line you edited. Please also limit the length of lines to 72 characters max (hard limit).

Comment 5

[David Lawrence [:dkl]]

Attachment: 3.4.13 sec advisory (v3)

Hopefully the wording is better on this one and I decreased the text width.

dkl

Comment 6

[Frédéric Buclin]

Comment on attachment 592604 [details]
3.4.13 sec advisory (v3)

>             when making POST requests to jsonrpc.cgi, an attacker
>             could potentially make changes to bugs on another Bugzilla
>             instance as if the user had made the change. The user
>             would have had to be already logged in to the target site
>             for the vulnerability to work.

"on another Bugzilla instance" should probably be "on a Bugzilla instance".
"make changes" vs "had made the change": shouldn't they both be plural?
Also, I think it's hard for readers to understand how the vulnerability works. Maybe we should say something like "If a user visits an HTML page with some malicious JS code in it, an attacker could make changes to a remote Bugzilla installation on behalf of the victim's account by using the JSON-RPC API".

Comment 7

[David Lawrence [:dkl]]

Attachment: 3.4.13 sec advisory (v4)

Reworded the CSRF paragraph to be more more informative on how the
vulnerability works. Please review.

dkl

Comment 8

[Frédéric Buclin]

Comment on attachment 592811 [details]
3.4.13 sec advisory (v4)

Looks good to me now. Thanks! r=LpSolit

Comment 9

[David Lawrence [:dkl]]

Checking in src/security/3.4.13/index.html;
/www/bugzilla-org/src/security/3.4.13/index.html,v  <--  index.html
initial revision: 1.1
done

Comment 10

[Frédéric Buclin]

And sec adv sent to mailing-lists + BugTraq.