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

Status: VERIFIED FIXED

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

Description

[Neal Poole]

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

Comment 1

[Michael Coates [:mcoates] (acct no longer active)]

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.

Comment 2

[Neal Poole]

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.

Comment 3

[Wil Clouser [:clouserw]]

Thanks for the bug report, this is fixed in r81567

Comment 4

[Michael Coates [:mcoates] (acct no longer active)]

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.

Comment 7

[Neal Poole]

Looks good from here too! Thanks for such a speedy response. :)