Closed Bug 1175425 Opened 7 years ago Closed 7 years ago

UniversalXSS in Quick Translator add-on (raw translation inserted using innerHTML)


( :: Security, defect)

Not set


(Not tracked)



(Reporter: dveditz, Assigned: jorgev)


(Keywords: sec-moderate, Whiteboard: [qa-])

The Security alias received a report from Diaa (@dia2diab) that the Quick Translator add-on is vulnerable to a Universal XSS because the translation is inserted into its panel using innerHTML (much like the problem with another translation add-on in bug 976945)

It appears you'd have to have the user select text in an <input> or <textarea> (the POC uses <input>) and translate only the selected text rather than the entire page, but with that limitation I confirmed the bug. (I can't rule out the possibility of being able to booby-trap the regular text in an HTML doc, but my simpleminded variations on the POC didn't work).

An example test page:

source of POC:
    <input type="text" value="<img src=d onerror=prompt('Hacked')>">
It doesn't matter where the text is. If it's translating a selection, the add-on sends the text of the selection, without escaping any HTML metacharacters, and injects whatever text Google Translate returns, without in any way sanitizing it.

It also requests the translation over HTTP, includes the option of automatically translating text whenever the selection changes, and interacts with content documents entirely via non-X-ray wrappers, including attaching a property to the content window global with several bound methods (which are fortunately not accessible to content in recent versions of Firefox).

So, all-in-all, this is pretty worrying. The add-on has a quarter of a million users, and appears entirely unmaintained, so we may have to block. I'll try contacting them via AMO and give them a week to respond.
Oh sorry, yes. I did mean to mention the worrying warnings about unsafe CPOW usage. The functionality is nice (nicer than the one I'm using) but the implementation is a disaster.
Kris: did you ever hear back? We probably need to block this now.
Flags: needinfo?(kmaglione+bmo)
I haven't heard back. I disabled the AMO listing. The blocklisting question is up to Jorge.
Flags: needinfo?(kmaglione+bmo) → needinfo?(jorge)
Does version 2.0a1 have the same vulnerabilities? It's a big rewrite, supposedly, and pushing that version to users (if it works) would be preferable over blocking it.
Flags: needinfo?(jorge) → needinfo?(kmaglione+bmo)
It looks like it's been completely rewritten from an overlay extension to an SDK extension, but I don't have the time to go through the code at the moment.
Flags: needinfo?(kmaglione+bmo)
Version 2.0a1 looks much better and the POC doesn't work on it. I'm approving it so current users will be updated to it. I'll block the older versions in two weeks, to give users time to update.
The developer decided to hide the extension on AMO. It's unclear if they intend to submit new versions in the future.

All vulnerable versions are now blocked:
Assignee: nobody → jorge
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2015-07
Group: addons-security
Please add STR here or mark it with [qa-] if no QA is needed.
I think it's qa-, the faulty add-on has been blocklisted.
Whiteboard: [qa-]
We are working on a new version, based on 1.0: Did not know that 2.0a1 was released - found it - we will check the differences.
You need to log in before you can comment on or make changes to this bug.