So, we need a sec advisory for all the affected versions. If somebody else besides me wants to do this, see previous Sec Advisory bugs and the Release guide.
Adding bug 305353, which is a blocker and affects 2.16 only, and bug 309952, which isn't a blocker but which is ready for checkin (except a missing 2.18 backport from joel... who said he would do it very soon).
FYI, all 4 security bugs are ready for checkin, except the 2.18 backport of bug 309952 which still waits for wicked to review it... which should be done very soon now. ;)
bug 305353 has now had its own advisory, forced because the issue went public already. http://www.bugzilla.org/security/2.16.10-nr/
bug 309952 won't be ready for 2.20.1 as wicked changed his mind and finally denied review for all patches. ;) Removing it from the list.
No longer depends on: 309952
Summary: Security Advisory for 2.16.11, 2.18.5, 2.20.1, and 2.21.2 → Security Advisory for 2.16.11, 2.18.5, 2.20.1, and 2.22rc1
Note that I added bug 325079 to the list, which is now ready for checkin (only affects 2.19.3 and above).
Created attachment 212354 [details] sec adv, v1 OK, this is an attempt. I hope this helps.
Comment on attachment 212354 [details] sec adv, v1 >+ Escaped HTML markups in titles of RSS feeds are incorrectly decoded by > some RSS readers and could potentially lead to XSS vulnerabilities. Should this really be "markups"? To me, it should just be markup. >If you are using a development snapshot, you should upgrade to 2.22rc1, >use CVS to update, or apply the patches from the specific bugs listed below. >Class: XSS vulnerability >Versions: 2.20rc1 - 2.20, 2.21.1 >Description: Some RSS readers incorrectly decode escaped HTML markups in Same comment re: markups. > feed titles and this could be used to inject some scripts. > Despite this is not a Bugzilla bug, we prefer to shift to Despite -> Although? > Atom feeds, where the RFC is unambiguous about HTML markups And again. > in feed titles. >Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=313441 > > >Issue 3 >------- >Class: Information Leak Earlier, the advisory implies that this allows my login username/password to be stolen - is that an information leak? >Description: If the URL to the homepage contains a double slash // in > the path and you are using the login form in this page to > authenticate, your login and password are redirected to > the computer in the local intranet corresponding to the part > of the URL being at the right of //. This poses a number of questions to me: 1) Does it only affect me if I'm using bugzilla on my intranet? That is: http://pi/bugzilla// would show it, but http://bugzilla.mozilla.org// would not? 2) Would it not be simpler to say "to the root of the website"?
Created attachment 212359 [details] sec adv, v2 Second attempt, with the help of Gavin Sharp for the third issue.
Comment on attachment 212359 [details] sec adv, v2 Looks great! >Class: Sensitive Data Exposure Except this is called "Information Leak," I believe. Or perhaps "Password Stealing." Or something. I suppose "Sensitive Data Exposure" might be fine. :-)
Attachment #212359 - Flags: review? → review+
Comment on attachment 212359 [details] sec adv, v2 You may want to note, on issue 1, that the previleges required to do this are administrative.
(In reply to comment #9) > Except this is called "Information Leak," I believe. Or perhaps "Password > Stealing." Or something. I suppose "Sensitive Data Exposure" might be fine. :-) It was Information Leak when I made my original comments. However, to me, information leak would be (e.g) revealing a hidden product. Enabling someone to possibly steal my username and password is MORE than just an information leak.
Comment on attachment 212359 [details] sec adv, v2 >Summary >======= > >+ The login form on the home page may redirect you outside the Bugzilla > installation, allowing the login name and password to be stolen. This item sounds *really* dangerous from this description. Reading the details below, it seems not quite so dangerous. We know from experience that people don't like to read more than they have to, so we should avoid scaring them here. >Development snapshots of 2.21 before 2.22.rc1 are also vulnerable. >If you are using a development snapshot, you should upgrade to 2.22rc1, >use CVS to update, or apply the patches from the specific bugs listed below. Is it 2.22.rc1 or 2.22rc1? We should pick one and be consistent. I prefer 2.22rc1 personally. >None of these vulnerabilities affect the old Bugzilla 2.16 branch. General users don't know what a branch is. We should instead say "2.16.x versions" or something to that effect. >Issue 1 >------- >Class: SQL injection >Versions: 2.17.1 and above >Description: The 'whinedays' parameter, editable from editparams.cgi, > is not validated before being saved. This can lead to SQL > injection in the whineatnews.pl script. > The validation for the 'mostfreqthreshold' parameter is also > missing, but this is not exploitable. >Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=312498 Someone else mentioned it earlier, but we really should indicate that it requires a user with administrative privs to exploit. Perhaps "SQL injection by an administrator" as the Class?
Attachment #212359 - Flags: review-
Created attachment 212510 [details] sec adv, v3
Attachment #212510 - Flags: review?(justdave) → review+
Security Advisory sent to BugTraq, mozilla-webtools, and announce@. I signed it for mozilla-webtools and announce@, but not for BugTraq (since it was more of a pain for BugTraq since I use their web form to submit).
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.