Here are the 5 security bugs being tracked: bug 637981 has a patch, and waiting for my review bug 653477 I'm going to work on it soon. Shouldn't be too hard to fix bug 657158 already has a reviewed patch for 4.x, but needs a backport from reed bug 660053 is ready for checkin bug 660502 has patches, and waiting for mkanat's review.

For the record, all security bugs mentioned in comment 0 except bug 653477 are ready for checkin, backports included. Bug 653477 is not a hard blocker, in case we want to release without it.

Adding bug 670868, which is ready for checkin.

Added bug 674497, which is ready for checkin.

(In reply to comment #1) > For the record, all security bugs mentioned in comment 0 except bug 653477 > are ready for checkin, backports included. Add bug 653477 to the list now. It got r+ for 4.2, and the backports are trivial. So we are ready for checkin. :) I will write the security advisory.

I mention Safari before 5.0.6 in the first item, as this vulnerability is confirmed by Apple itself. No other changes.

Comment on attachment 550082 [details] Sec Adv, v1.1 >* Group names can be guessed when creating or editing bugs. This sounds like people can put bugs into groups that they shouldn't be able to. Perhaps instead: * It is possible to determine whether or not certain group names exist. (And then combine the Search and post_bug/process_bug bugs into one vuln below.) >* When a user changes his email address, Bugzilla trusts a > user-modifiable field for obtaining the current e-mail address to send > a confirmation message. If an attacker has access to the session of > another user, he could alter this field to silently change the email > address of this account. Instead let's just say: * If an attacker has access to a user's session, they can modify that user's email address without that user being notified of the change. (The longer description can go down below.) > patches in "Raw Unified" mode because Internet Explorer 8 > and older, and Safari before 5.0.6 do content sniffing > despite patches are displayed with the text/plain MIME > type, which could lead to the execution of malicious code. Remove "despite patches are displayed with the text/plain MIME type". (Just trying to make it simpler.) >Class: Email Headers Injection I would call it just "Email Header Injection" (no s). >Class: Account Compromise I wouldn't call this Account Compromise, that sounds like it's possible to take over another user's account in broader circumstances than this issue allows. Perhaps something about notifications instead? (Silent Account Change or something, perhaps?) >Description: When a user changes his email address, Bugzilla trusts > a user-modifiable field for obtaining the current e-mail > address to send a confirmation message. "confirmation message to." > If an attacker has > access to the session of another user, he could alter this > field to silently change the email address and get full > control of this account. "If an attacker has access to the session of another user (for example, if that user left their browser window open in a public place), the attacker could alter this field to cause the email-change notification to go to their own address. This means that the user would not be notified that their account had had its email address changed by the attacker." >Class: Information Leak >Versions: 4.1.1, 4.1.2 >Fixed In: 4.1.3 >Description: In Bugzilla 4.1.1 and 4.1.2, custom searches let you > determine if a group exists or not, even for groups which > should remain confidential. > Bugzilla 4.0.2 and below are not affected by this issue. Let's combine this with the post_bug/process_bug one above. >Class: Cross-Site Scripting >Versions: 2.16rc1 to 3.4.11 >Fixed In: 3.4.12 >Description: If a BUGLIST cookie is compromised, "If a BUGLIST cookie is compromised (which is not possible except via a vulnerability outside of Bugzilla)," >The Bugzilla team wish to thank the following people/organizations for >their assistance in locating, advising us of, and assisting us to fix >this issue: > >Frédéric Buclin >Byron Jones >Reed Loden >Max Kanat-Alexander >Neal Poole >Neil Rashbrook >David Lawrence Does this include all of the reporters for all of the bugs? There are so many bugs listed here, I'm surprised there aren't more people involved.

> Does this include all of the reporters for all of the bugs? There are so > many bugs listed here, I'm surprised there aren't more people involved. Yes, the list is complete. You know, I reported 3 sec bugs, and have them assigned to me, and I reviewed the 4 other sec bugs. This means 50% of the work with one single guy. :)

(In reply to comment #8) > Yes, the list is complete. You know, I reported 3 sec bugs, and have them > assigned to me, and I reviewed the 4 other sec bugs. This means 50% of the > work with one single guy. :) Ha, all right! :-) Well done.... :-)

Security advisory sent.