1123433 - COPPA error screen in FxAccounts signup allows loading arbitrary web content into B2G root process

Status: RESOLVED FIXED

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

Description

[Kartikaya Gupta (email:[e-mail])]

In following the STR for bug 1109531 on master, I noticed that an external website (hosted at ftc.gov) gets loaded into the b2g root process. This seems bad, as we don't control this content and a user clicking on links from that page can theoretically load arbitrary content into the b2g root process.

STR (basically copied from bug 1109531):
1. go to settings > Firefox accounts
2. click on "create account or sign in"
3. enter a bogus email address that has no firefox account associated with it (e.g. [e-mail]) and hit next
4. In the age verification drop-down pick a recent year (e.g. 2014) and hit next
5. On the COPPA error message screen that shows up click on "learn more"

Comment 1

[Kartikaya Gupta (email:[e-mail])]

I was able to repro this on master, but based on bug 1109531 and bug 1040424 it probably goes all the way back to 2.0 and earlier.

Comment 2

[Kevin Grandon :kgrandon]

I'm not sure if or how qawanted works with secure bugs, but we should try to get branch checks here - though maybe a dev should go through and figure that out.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

2.1 is definitely affected as well, I loaded a build and verified.

Comment 4

[Kevin Grandon :kgrandon]

Sounds like 2.2 will probably be affected then.

Comment 5

[Matt Wobensmith [:mwobensmith][:matt:]]

Naoki, we need someone to investigate how far back this might go. Can you or someone else in QA help?

Comment 6

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Firefox Accounts was introduced in 2.0: https://wiki.mozilla.org/B2G/Roadmap/Archive_-_Past_Releases_Complete_Features w/ bug 941723

1.4 shouldn't be affected.

It sounds like we just need to test 2.0 since 2.0M is an offshoot of 2.0.  Is that correct?  Are we also trying to find the regression range?  It almost sounds like this was there from the beginning.
(Trying to understand the scope of what needs to be tested)

Comment 7

[Matt Wobensmith [:mwobensmith][:matt:]]

We were just trying to answer the question in comment 2, w/r/t regression range. If we have no additional information on top of what you provided (and thanks for that) then I guess that's all we can do from the QA side for now.

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Peter, can you have someone check if this happens on 2.0 please?
You may have to add that person to the bug for them to see it.

Comment 9

[Peter Bylenga [:PBylenga]]

Will do, Jayme, can you take a look please?

Comment 10

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue DOES occur on 2.0 Flame KK.

Environmental Variables:
Device: Flame 2.0
BuildID: 20150120081659
Gaia: 736933b25ded904f0cb935a0d48f1f3cf91d33ad
Gecko: 0c9b6ff58714
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

I also verified that on the v165 1.4 Flame KK base, there is no Firefox account options under settings.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

[Blocking Requested - why for this release]: Security bug

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Jared/Fernando, do you know who should be looking into this? I'm not sure if it this is considerd a FxA error or a gaia system error.

Comment 13

[Fernando Jiménez Moreno [:ferjm]]

Ugh, that's true. I'll try to get to this next week.

Comment 14

[Fernando Jiménez Moreno [:ferjm]]

Sorry folks, I am quite busy with FxOS v3 stuff and 2.2 feature landing, so I am not sure when I will be able to get to this one :(. Jared, if you have any free cycles, could you take a look at this one, please? Thanks!

Comment 15

[Kevin Grandon :kgrandon]

I took a quick look and noticed at least 2 other links which open content in the root process. Privacy Notice and Terms of Service on the first page. The easy fix here is to include the oop config for BrowserFrame.

Fixing the error message is a bit more tricky without a large refactoring. The best solution I had for that is to use a custom element which handles the stringification quite well.

Comment 16

[Kevin Grandon :kgrandon]

Attachment: Github pull request

Comment 17

[Kevin Grandon :kgrandon]

Comment on attachment 8567692 [details] [review]
Github pull request

Jared, Fernando - I had some time on the plane so I took a quick look at this. Either of you guys want to take a quick look and let me know if this is a reasonable approach? Thanks!

Comment 18

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Comment on attachment 8567692 [details] [review]
Github pull request

This patch looks good, but I'm not a system peer, and haven't tested it on device. If there are concerns, I think we could definitely just not link out to the FTC COPPA info page; I'm not sure it's properly internationalized, so it might be useless to most of our audience. Anyway, f+ from me, thanks so much kgrandon ^_^

Comment 19

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 8567692 [details] [review]
Github pull request

Thank you Kevin! LGTM

Comment 20

[Kevin Grandon :kgrandon]

Thanks guys taking this for now. Also going to just leave the link in for now as changing it would result in requiring a string change. It might be a change we want to make in 3.0 though.

Comment 21

[Kevin Grandon :kgrandon]

Bhavana - I'll get this into 3.0, but who should make the 2.0 blocking call on this bug?

Comment 22

[Kevin Grandon :kgrandon]

In master: https://github.com/mozilla-b2g/gaia/commit/77381a5b9e4852240dc0ed5604cdbbd1fdf8571a

Comment 23

[Ryan VanderMeulen [:RyanVM]]

While this technically meets the criteria for auto-uplift seeing as how it's a sec-high, it sounds like it's complicated by string changes? I'll defer to y'all's judgement then as to what releases this should be backported to.

Comment 24

[Kevin Grandon :kgrandon]

I actually made an attempt to make no string changes, so there is no localization needed for this. If this meets criteria for auto-uplift then we should be good to go.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/a79f091778cb0c287541dfcfdabd9d5b1ecfb879

This needs rebasing for v2.0/v2.1, though.

Comment 26

[Kevin Grandon :kgrandon]

I have a patch for 2.1 ready, but it's not working for some reason =/

I'm getting an error, "Operation is not supported" - it seems there's some problem with web components for some reason. Will investigate further.

Comment 27

[Kevin Grandon :kgrandon]

This is working fine on 2.2 though. At this point I'm not sure how to fix 2.0 and 2.1 without making string changes.

Comment 28

[Kevin Grandon :kgrandon]

(In reply to Kevin Grandon :kgrandon from comment #27)
> This is working fine on 2.2 though. At this point I'm not sure how to fix
> 2.0 and 2.1 without making string changes.

I'm going to mark 2.0 and 2.1 as wontfix here for the time being. I'm currently unable to make a fix there without doing a string change unless someone has a better idea.

I'm not sure what the process typically is here, so please chime in if you think this is wrong.

Comment 29

[bhavana bajaj [:bajaj]]

Sorry for the late response on this one, given the string change I don't think we can land this at this time. But this is also a sec-high, so I am Ni'ing Paul to make sure about this decision or raise any concerns if we should try to find more options(hard coded strings?) to fix this depending on his assessment from security side.

Comment 30

[Kevin Grandon :kgrandon]

The 2.0 and 2.1 fix would be to change the error message. I suppose in this case we would have an english-only string for all locales.

Comment 31

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

So lets think about what the actual attack scenario would be here. IIUC  an attacker would need to coerce the user to complete the STR above in comment 1, and then somehow get the victim to continue browsing to arbitrary web content in the same window. I note that the URL in Gaia not SSL so there is small chance of an opportunistic redirection to malicious content for an attacker who already has an active MITM position (e.g. over insecure wifi) . [1] But that seems pretty unlikely in the grand scheme of things? And then you of course still need some kind of Firefox exploit to take advantages of the root privileges...

TLDR: If comment 30 is easy, then may as well do it, but if its risky, then I'm not sure we need to worry too much. 


[1] Annoying sidenote:  the COPA page actually redirects from http -> https... shame don't we link to the SSL page, which would limit this attack! http://www.ftc.gov/news-events/media-resources/protecting-consumer-privacy/kids-privacy-coppa. Maybe it wasn't always a secure page...

Comment 32

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

Re-rating this as per my previous comment. It might actually be a sec-low given the requirement for an additional vuln, but I'll err on the side of caution.