Closed Bug 628697 Opened 9 years ago Closed 9 years ago

Directory Traversal / Local File Inclusion on addons.mozilla.org

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect, P1, blocker)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: neal, Assigned: clouserw)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [infrasec:input][ws:critical])

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.237 Safari/534.10
Build Identifier: 

app/controllers/pages_controller.php in the CakePHP code for AMO is vulnerable to a local file inclusion vulnerability. It takes user input via the query string to determine which template should be loaded. By injecting URL-encoded slashes and a URL-encoded null byte, it is possible to use arbitrary files on the filesystem as templates, echoing their content to the page. My proof of concept loads the /etc/passwd file for the AMO server.

Reproducible: Always

Steps to Reproduce:
1. Go to https://addons.mozilla.org/en-US/firefox/pages/..%252f..%252f..%252f..%252f..%252f..%252f..%252fetc/passwd%2500
2. See the contents of /etc/passwd
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [ws:need triage]
Severity: critical → blocker
Priority: -- → P1
Whiteboard: [ws:need triage] → [infrasec:input][ws:critical]
Confirmed ability to view any system files. Password hashes are not exposed. The password file is shadowed and the shadow file is not viewable.  Unclear if local php files would render. Need to find a local php file to test that.
https://addons.mozilla.org/en-US/firefox/pages/..%252f..%252fconfig/config.php%2500
Displays nothing, indicating it is being parsed as PHP

https://addons.mozilla.org/en-US/firefox/pages/..%252f..%252fviews/admin/serverstatus.thtml%2500
This is echoing out REVISION, indicating it is being parsed as PHP (which makes sense, since thtml files are PHP).

I tried uploading a search XML file containing PHP inside of an HTML comment (<!-- <?php passthru('whoami') ?> -->) but I'm not sure where on the filesystem the file is actually being stored, so I couldn't execute it.
Thanks for the bug report, this is fixed in r81567
Assignee: nobody → clouserw
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Neal, Thanks again. You should see that the issue is fixed on the live servers. Front end caching may show you the stale data for a few minutes. You can append &a=b to the url to force new data.

This bug will be submitted for bug bounty review.
Looks good from here too! Thanks for such a speedy response. :)
Group: client-services-security
Status: RESOLVED → VERIFIED
Blocks: 835438
Flags: sec-bounty+
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.