Closed Bug 629689 Opened 15 years ago Closed 15 years ago

XSS on mail.mozilla.org

Categories

(Security Assurance :: General, task)

Product:
Security Assurance
Component:
General
Type:
task
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: firealwaysworks, Assigned: justdave)

References

(
URL
)

Details

(Keywords: reporter-external, wsec-xss, Whiteboard: [infrasec:xss][ws:critical])

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.10 (maverick) Firefox/3.6.13 Build Identifier: XSS affecting the config POST variable. PoC: curl https://mail.mozilla.org/mmsearch/design -d 'sort=score&config=1 ></a><ScRiPt>alert(1)</ScRiPt>&method=and&words=on&format=short' Reproducible: Always
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Whiteboard: [infrasec:xss][ws:high]
This is a problem in the htdig patch that's incorporated into mailman (http://www.openinfo.co.uk/mm/patches/444884/). templates/en/htdig_access_error.html <P> If you want to make another attempt to access a list archive then go via the list users <A HREF="%(listinfo_link)s">information page</A>. </P> %(listinfo_link)s isn't sanitized. From mmsearch.py:make_inserts() 'listinfo_link': urlbase + '/listinfo/' + listname, listname just comes from the URL, sadly... I don't have Mailman's source handy, so not sure how Mailman sanitizes stuff.
This bug needs to get fixed, seems to have dropped through the cracks. Wrong components?
Assignee: nobody → server-ops
Component: Other → Server Operations: Security
Product: Websites → mozilla.org
QA Contact: other → clyon
Whiteboard: [infrasec:xss][ws:high] → [infrasec:xss][ws:critical]
Version: unspecified → other
Dave: are you still the one handling mailman these days?
Assignee: server-ops → justdave
Test case: curl https://mail.mozilla.org/mmsearch/design -d 'sort=score&config=1 ></a><ScRiPt>alert(1)</ScRiPt>&method=and&words=on&format=short' Vulnerable Response (note script tags in response): <HTML> <HEAD> <TITLE>htdig Archives Access Failure</TITLE> </HEAD> <BODY BGCOLOR="#ffffff"> <H1>htdig Archives Access Failure</H1> The requested list cannot be accessed. design:1 ></a><ScRiPt>alert(1)</ScRiPt> <P> If you want to make another attempt to access a list archive then go via the list users <A HREF="https://mail.mozilla.org//listinfo/1 ></a><ScRiPt>alert(1)</ScRiPt>">information page</A>. </P> <P> If this problem persists then please e-mail the following information to the <A HREF="mailto:mailman@mozilla.org">mailman@mozilla.org</A>: </P> <PRE> Referer not known /mmsearch/design </PRE> <HR> </BODY> </HTML>
CCing the maintainer of the above patch. Interestingly enough I just deployed the latest version of this patch from http://www.msapiro.net/mm/ to our sites about 2 hours prior to when this testcase was posted, having not seen this bug yet. I just verified the testcase is still exploitable.
The deployment earlier today was part of fixing an another XSS in upstream mailman, fwiw, that was bug 536436.
I suppose I am the defacto maintainer of this patch (sigh ...). The fix for this issue is to change the line in mmsearch.py referred to in comment #2 above or in the patch that creates it from + 'listinfo_link': urlbase + '/listinfo/' + listname, to + 'listinfo_link': urlbase + '/listinfo/' + Utils.websafe(listname), I will make the above change on all my copies of the patch, but it is up to Richard Barrett to change anything on the <http://www.openinfo.co.uk/mm/> site.
(In reply to comment #9) > I will make the above change on all my copies of the patch, but it is up to > Richard Barrett to change anything on the <http://www.openinfo.co.uk/mm/> site. Do you know a good way to contact him (or have you already?) Thanks! Wrote: /usr/src/redhat/SRPMS/mailman-2.1.14-3mozilla2.rhel5.src.rpm Wrote: /usr/src/redhat/RPMS/i386/mailman-2.1.14-3mozilla2.rhel5.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/mailman-debuginfo-2.1.14-3mozilla2.rhel5.i386.rpm * Fri Feb 18 2011 Dave Miller <justdave@mozilla.com> 2:2.1.14-3mozilla2 - Fix for https://bugzilla.mozilla.org/show_bug.cgi?id=629689 (XSS in htdig patch) And deployed on both lists.mozilla.org and mail.mozilla.org
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
And that didn't fix the problem, I can still reproduce the test case.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Seems to be here: + raise _search_exception(listname, 'list', '%s:%s' % (path_listname, listname)) changed to + raise _search_exception(listname, 'list', '%s:%s' % (path_listname, listname))
er, the fixed line is: + raise _search_exception(listname, 'list', '%s:%s' % (path_listname, Utils.websafe(listname)))
Wrote: /usr/src/redhat/SRPMS/mailman-2.1.14-3mozilla3.rhel5.src.rpm Wrote: /usr/src/redhat/RPMS/i386/mailman-2.1.14-3mozilla3.rhel5.i386.rpm Wrote: /usr/src/redhat/RPMS/i386/mailman-debuginfo-2.1.14-3mozilla3.rhel5.i386.rpm * Fri Feb 18 2011 Dave Miller <justdave@mozilla.com> 2:2.1.14-3mozilla3 - Revised fix for https://bugzilla.mozilla.org/show_bug.cgi?id=629689 (previous one was incomplete) and deployed.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
(In reply to comment #11) > (In reply to comment #9) > > I will make the above change on all my copies of the patch, but it is up to > > Richard Barrett to change anything on the <http://www.openinfo.co.uk/mm/> site. > > Do you know a good way to contact him (or have you already?) Thanks! I haven't contacted him, but as far as I know you can reach him at <r.barrett@openinfo.co.uk>.
I've emailed Richard giving him a heads-up.
(In reply to comment #14) > er, the fixed line is: > > + raise _search_exception(listname, 'list', '%s:%s' % > (path_listname, Utils.websafe(listname))) This fix is good, but I'm not convinced that it is still not incomplete. I will look at this in more detail in a few days.
I have looked at this further, and I have come up with a different fix. Instead of the two changes in comments 9 and 14, I have applied Utils.websafe() to the listname and detail arguments in the __init__() method of the _search_exception class. That portion of the original patch creating mmsearch.py becomes + def __init__(self, listname, reason, detail): + self.listname = Utils.websafe(listname) + self.reason = reason + self.detail = Utils.websafe(detail) + This catches the above attack and also another attack where the XSS HTML is in a variable name rather than a value, e.g. curl https://mail.mozilla.org/mmsearch/design -d 'sort=score&config=1&></a><ScRiPt>alert(1)</ScRiPt>=1&method=and&words=on&format=short' Also, for completeness, the same fix should be applied to the remote_mmsearch module, only there we need to use Python's cgi.escape() as below instead of Mailman's Utils.websafe because remote_mmsearch does not have access to Mailman modules. + def __init__(self, listname, reason, detail): + self.listname = cgi.escape(listname) + self.reason = reason + self.detail = cgi.escape(detail) + I have applied these changes to all my versions of the patch.
Did this get a CVE Number? I know two CVE's where issued for Mailman, CVE-2010-3089 and CVE-2011-0707, Which one is this?
(In reply to comment #20) > Did this get a CVE Number? I know two CVE's where issued for Mailman, > CVE-2010-3089 and CVE-2011-0707, Which one is this? Neither. Note that mmsearch is not part of normal mailman. Dan, probably still reasonable to assign a CVE for this, as I bet others are using this as well...
Awesome thanks, Can the CVE reference this advisory: https://sitewat.ch/en/Advisory/3
mike: your information is incorrect on that advisory. The version number given for the "upgrade to" is the version of Mailman that the patch applies to, and not the version of the patch. The patches themselves aren't versioned, and the fixed ones are at http://www.msapiro.net/mm/ . The patches on http://www.openinfo.co.uk/mm/ have not yet been updated (and the patch for Mailman 2.1.14 hasn't even been posted there). I never heard back from Richard (owner of the openinfo site) in response to my heads-up email about it.
I suppose it would work to reference the patch by date... the fixed patches were posted on 21-Feb-2011.
mike: I notice you updated the vulnerable version on your advisory based on my above comments, but your solution still says "Upgrade to 2.1.12" when it should be something to the effect of "Apply new patch posted on 21-Feb-2011 or later" or something. Might also need to point out Mark Sapiro's site for the fixed version, since the openinfo page still says "Last updated: 09/07/2009 13:50" in a not-quite-so-obvious spot on the page.
Oah sorry about that. I updated the advisory.
Group: websites-security
Status: RESOLVED → VERIFIED
Component: Server Operations: Security → Security Assurance: Operations
Adding keywords to bugs for metrics, no action required. Sorry about bugmail spam.
Keywords: wsec-xss
Flags: sec-bounty+
Component: Operations Security (OpSec): General → General
Product: mozilla.org → Enterprise Information Security
You need to log in before you can comment on or make changes to this bug.