XSS/HTML Injection in Gaia music app, through meta information

RESOLVED FIXED in FxOS-S5 (21Aug)

Status

defect
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: tedd, Assigned: tedd)

Tracking

({sec-low, wsec-xss})

unspecified
FxOS-S5 (21Aug)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(b2g-v2.0 wontfix, b2g-v2.0M wontfix, b2g-v2.1 wontfix, b2g-v2.1S wontfix, b2g-v2.2 wontfix, b2g-v2.2r wontfix, b2g-master fixed)

Details

Attachments

(3 attachments)

Posted image music_poc.png
When the user searches for music inside the music app, a HTML injection can be triggered through the meta information of the song files.

The cause of the problem is a innerHTML assignment [1] for search results.

This could also be abused by sharing a song over Bluetooth onto the target device, the user would still have to search for something that includes the malicious file in the results in order to trigger the injection.

A potential fix is to use the Sanitizer Library[2]

[1] https://github.com/mozilla-b2g/gaia/blob/246c92f657f0f6e5a56dd252ce455bb2e8f90fdd/apps/music/js/utils.js#L59
[2] https://developer.mozilla.org/en-US/Firefox_OS/Security/Security_Automation
This patch fixes the problem, but I haven't pushed to try.

I only rebuild the music app and replaced it on my phone to give it a try.
Please create a pull request at https://github.com/mozilla-b2g/gaia so we can trigger the automated tests.

Also, note that this version of the music app is due to be replaced in a few weeks, so I'm not sure this patch will ever see a proper release. Still, it's probably good to fix it.
Oh, and thanks for the patch!
Jim, can you tell which releases are affected?

> Please create a pull request at https://github.com/mozilla-b2g/gaia so we
> can trigger the automated tests.

A public pull request may be in order. Just worried about 0daying ourselves.
Keywords: sec-low
^^^^
Flags: needinfo?(squibblyflabbetydoo)
I can take care of this patch. Not sure how it goes with gaia-try though, but I can run the tests locally.

Also I'm not sure how far back we'll have to uplift this.
Assignee: nobody → julian.r.hector
Status: NEW → ASSIGNED
(In reply to Christiane Ruetten [:cr] from comment #4)
> Jim, can you tell which releases are affected?

1.1+.

> A public pull request may be in order. Just worried about 0daying ourselves.

Once the PR is landed, it'll be public anyway. A PR on Github without a description of the bug wouldn't be any more revealing.
Flags: needinfo?(squibblyflabbetydoo)
Comment on attachment 8643167 [details] [review]
PR gaia - Fix injection using Sanitizer r=squib

Thanks for the patch!
Attachment #8643167 - Flags: review?(squibblyflabbetydoo) → review+
Is this patch ready to land, or do you need to do anything with it before I hit the big green button?
Flags: needinfo?(julian.r.hector)
The automatic test started by the pull request didn't trigger any errors, unless we have other tests that need to be performed, I would say that the patch is ready.
Flags: needinfo?(julian.r.hector)
Ok, I'll merge the patch once Gaia re-opens. Thanks again!
Landed: https://github.com/mozilla-b2g/gaia/commit/84fc50c0b4da86de68ed82022b5f05c9968da0e5
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
For what it's worth, here's the bug that introduced this: bug 838036.
Not sure if this is worth backporting or not given it's a sec-low.
Target Milestone: --- → FxOS-S5 (21Aug)
Group: core-security → core-security-release
Jim, is this something worth backporting to v2.2?
Flags: needinfo?(squibblyflabbetydoo)
Thanks to other security features, I don't think this allows someone to inject scripts, so it's really just a cosmetic thing. I wouldn't bother backporting.
Flags: needinfo?(squibblyflabbetydoo)
(In reply to Jim Porter (:squib) from comment #17)
> Thanks to other security features, I don't think this allows someone to
> inject scripts, so it's really just a cosmetic thing. I wouldn't bother
> backporting.

Please let us NOT call fixing Cross-Site Scripting a "cosmetic thing". Content Security Policy is just a mitigation technology.
You know, just like wearing a seat belt doesn't make us all run red traffic lights.


The severity is sec-low because it's rather unlikely that an attacker will get you to download and search for a particular file, so I agree that it does not need backporting.
(In reply to Frederik Braun [:freddyb] from comment #18)
> (In reply to Jim Porter (:squib) from comment #17)
> > Thanks to other security features, I don't think this allows someone to
> > inject scripts, so it's really just a cosmetic thing. I wouldn't bother
> > backporting.
> 
> Please let us NOT call fixing Cross-Site Scripting a "cosmetic thing".
> Content Security Policy is just a mitigation technology.
> You know, just like wearing a seat belt doesn't make us all run red traffic
> lights.

If CSP can somehow be broken to run arbitrary Javascript, then we should backport this. My understanding is that that's impossible. Assuming my understanding is correct, the analogy would be more like "you don't need to wear a belt if you already have suspenders on."

> The severity is sec-low because it's rather unlikely that an attacker will
> get you to download and search for a particular file, so I agree that it
> does not need backporting.

If CSP can be broken in this case, all it takes is to get the evil file on the phone and wait for the user to search for *anything* and then they're in trouble. Just put all the letters of the alphabet in the song title, and any search will initially show the evil file, triggering this bug.

My recommendation for not backporting is based *entirely* on the assumption (as told to me by others with more familiarity with CSP than I) that an attacker can't use this hole to run JS. If that's so, then this is indeed a "cosmetic thing"; if not, then it should be backported.
CSP is meant to prevent JS execution, but not every CSP bypass is backported to older versions of Firefox OS.
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.