User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:18.104.22.168) Gecko/20100401 Firefox/3.6.3 Build Identifier: This is a very serious vulnerability and i would like to say that i respect your privacy and I have only done what is necessary to prove that this is a real issue and not a false positive. I like you guys, thank you for making the web a better place. http://bugzilla.org/cgi-bin/mj_wwwusr?passw=&list=GLOBAL&user=&func=help&extra=/../../../../../../../../etc/passwd verification: http://bugzilla.org/cgi-bin/mj_wwwusr?passw=&list=GLOBAL&user=&func=help&extra=/../../../../../../../../etc/group Reproducible: Always
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
justdave: could you ping majordomo about this issue?
Yeah, working on it. This is an upstream bug in Majordomo2, I'm forwarding to the maintainers.
Assignee: website → server-ops
Group: bugzilla-security → webtools-security
Component: bugzilla.org → Server Operations: Security
Product: Bugzilla → mozilla.org
QA Contact: default-qa → clyon
Summary: Directory Traversal (!!!) → Directory Traversal in majordomo2's 'help' command
Version: unspecified → other
Why are we running majordomo on dm-mailman01 again? Why can't we just convert the bugzilla lists into mailman lists? This would be a good time for that.
Summary: Directory Traversal in majordomo2's 'help' command → Directory traversal in majordomo2's 'help' command
It's a pain to convert the archives, etc. It can be done, one of those things nobody has time for. I've disabled the web interface for now, no point leaving this open for exploit when we have secured list archives on the box that shouldn't be shared.
Mike: Thanks a bunch for the report, since nobody said it on this bug yet. :) The distinctions aren't visible a lot to outsiders, but there's (mostly) a different group of people attacking your two bugs. This one affects software running on a Mozilla-operated server, so our server ops team is handling it. The other bug you filed is on a community-operated machine run by the Bugzilla project, so the guys that take care of that machine for Bugzilla are dealing with it.
No longer depends on: 628085
Dave: Interesting. We'll I am happy to help. Yeah, I saw a new name on the other bug, they are also nice to work with. Is this issue bounty worthy because it is a serious issue on a Mozilla server?
(In reply to comment #4) > It's a pain to convert the archives, etc. It can be done, one of those things > nobody has time for. I filed bug 628085 to make time for doing just that so majordomo can be removed completely. :)
(In reply to comment #7) > Is this issue bounty worthy because it is a serious issue on a Mozilla server? This issue has been nominated for a bounty, but it'll be up to the bounty committee to make the final decision on whether this qualifies.
dveditz, need a CVE for this one.
Call this CVE-2011-0049
Jason Tibbits (CCed last night) is a former project lead for Majordomo2, the current project lead (Michael Yount) seems to be MIA at the moment (his last-known email address bounces). Got a reply from Jason via email that he's going to look into it. Unfortunately he also pointed out that it's exploitable via all of Majordomo2's interfaces, not just the web (i.e. you can exploit it via email as well). Send an email to firstname.lastname@example.org with the following in the body of the email: help ../../../../../../../../../../../../../etc/passwd and guess what it mails back to you... I just grepped through them, and the only record of an attempt to exploit this is the one I just did to verify it. For now, I've re-enabled the web interface and hacked out the help command at the object parser level within the backend (it'll tell you the help command doesn't exist now).
them == the logs
How hard would it be to chroot majordomo2 until everything can be moved to mailman (which should still be a priority)?
(In reply to comment #14) > How hard would it be to chroot majordomo2 Probably hard, as postfix has to be able to deliver mail to it, and apache has to interact with it likewise.
This naive fix solves the immediate problem for me. It's been a very long time since I was in this code, however.
Seems to work. Majordomo>help ../../../../../../../../../../../../../etc/passwd = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = help unknowntopic - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ERROR - the document you requested is not available. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = I've deployed this. FWIW, he committed that upstream, I did a cvs update and it picked up his patch, so I didn't have to apply it manually.
@Dave Miller Wow that is so cool!
clyon: can you guys sanity-check the patch here? Source tree is at dm-mailman01:/usr/local/src/majordomo2/ if you need more context.
Can this bug be made public?
Did a new version of majordomo2 get released yet?
There is a current snapshot: http://ftp.mj2.org/pub/mj2/snapshots/2011-02/ Dave Miller said the maintainer's email bounces.
As far as I can recall there were never any actual releases of the code base; just snapshots and CVS. It never really acquired a sufficient number of developers to take off. I still host the CVS server and mailing lists but Michael was essentially the primary developer for the last years of the project and I haven't heard from him in ages.
Ah, ok. I'll send mail to oss-security@ at least informing people of the issue. Resolving and opening this bug as a result.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(In reply to comment #24) > Ah, ok. I'll send mail to oss-security@ at least informing people of the issue. Actually, Mike: Did you want to make any type of formal advisory for this issue? If you want to send something out to the usual lists (full-disclosure, bugtraq, oss-security, etc.), that would be good. If not, I'll probably send out some type of notification just so people know to upgrade and to make sure no vendors have packaged this.
Most of the people actually using majordomo2 are following the email@example.com mailing list. It should go there first, I'd imagine.
@Reed Loden Sounds good to me. Here is the advisory that I would like people to link to: https://sitewat.ch/en/Advisory/View/1
This bug needs to be reopened. The quick fix just changed how the same exploit can be made. For instance, if I was to try this with the new patch: ./..././..././..././..././..././..././..././.../etc/./rc.local I'd end up with the following: ../../../../../../../../etc/./rc.local Obviously, this isn't desirable either, so the patch needs to be changed to use the following regex: s!(^|/)[./]+/!\1!g When, when applied, will scrub the string of any sequences of dots and slashes bound by either the start of the string or a slash on the left, and a terminal slash on the right. The patch attached will fix things. Unfortunately, I'm currently unable to submit it to the MJ2 dev list as it doesn't recognise the .me TLD, but I'll be submitting it there shortly.
Comment on attachment 518705 [details] [diff] [review] Fixed file path scrubbing. This patch fails to apply to current cvs tip of Majordomo2. Coincidentally, Jason appears to have committed another attempt to fix this 2 days ago, which is what conflicts. He didn't do the same as this patch does though.
Attachment #518705 - Flags: review-
Component: Server Operations: Security → Security Assurance: Operations
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.