1040343 - Invalid HTTPS connections by all app are allowed with one application's iframe mozbrowser

Status: RESOLVED INVALID

(Firefox OS Graveyard :: General, defect)

Description

[Muneaki Nishimura]

Attachment: PoC of this bug.

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Steps to reproduce:

1. Open a https: domain with invalid certificate on an application's iframe mozbrowser.
2. "This Connection is Untrusted" warning page is shown on the iframe, and then, click "Visit site" button.
3. The iframe continues to load resources protected with invalid certificate.


Actual results:

After above processes, all application's all HTTPS access to the domain are permitted 
automatically.


Expected results:

In my understanding, current Firefox OS's architecture allows in-secure HTTPS access only to Browser API.
So, all HTTPS request other than Browser API has to be disallowed.

As an attack scenario,
1. An attacker make victim to press "Visit site" button from one application's iframe mozbrowser by using click jacking technique (see clickjacking.html in the attachment file).
2. After that, the attacker can steal user's information in system-wide level via malicious proxy or by their fake servers.

Comment 2

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

I don't completely understand what comment 0 is saying the problem is, but in testing the PoC I see some bad issues with security exceptions. 

I installed the PoC app. Strangely adding a certificate exception does not work on the pages loaded inside an iframe at all. When I navigated the top level frame (by click the link to "https://selfsigned.jssec.org/cacert.crt") I was then able to click 'visit site' to add a temporary exception. However this exception was not temporary and in fact was still present after a reboot. 

This is not expected: visit site exceptions should only persist until the b2g process is restarted (until the phone is rebooted). 

NOTE: it is known that restarting an app does not clear SSL exceptions, but this seems worse than this.

Comment 3

[Frederik Braun [:freddy]]

FWIW: When I click "visit site" for other sites in the normal browser app, I can make the temporary exception go away by rebooting. I was not able to do that for the PoC app.

Comment 4

[Muneaki Nishimura]

The problematic behavior I'd like to say is that no certificate error are shown after a user accepts certificate error once in an iframe-mozbrowser.

For example, a user opens https://google.com with invalid cert by 'visit link' button in iframe-mozbrowser of App-A.
After that, all HTTPS connections to google.com from not only App-A but also App-B are permitted.

Firefox OS allow to access to invalid HTTPS host only from iframe-mozbrowser,
but, because of this behavior, any HTTPS requests from any applications are accepted.

Comment 5

[Frederik Braun [:freddy]]

Patrick, we have a hard time analyzing the root cause of this behavior and why we're getting different results here and there.

Can you help us investigating this, please?

Comment 6

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

I haven't tried it, but I think what comment 0 said is correct, as there's just one exception service in Gecko: If a site is with an invalid certificate, it will be banned by phone. Say, if we try to view the site in browser app, we'll get the yellow warning page; if we try to open an app that is hosted on the site, we'll get error message and cannot continue to use that app.

However, if user clicks 'visit site' in the warning page, which is only shown in browser app, and then open an app hosted on that site, the certificate of the site will no longer be seen as invalid.

Implementing per-app certificate exception could fix this and bug 858730. However, I am not sure how hard will it be. For now, I think we should at least do some UI change on this.

Comment 7

[Frederik Braun [:freddy]]

Thanks for the insight Patrick. This is in line with what we understood so far.

Additionally, we concluded that the temporary exception *for all apps* would at least be gone after a reboot, but we couldn't even see this either. Can you help and elaborate on this (or even re-test) here, please?

Comment 8

[Muneaki Nishimura]

There is more easy way to reproduce this issue.

1) Change current time to 07/21/2036 by 'Date & Time' menu in Settings.
2) Open Developer menu in Settings.
3) Click 'Launch First Time Use' button and launch FTU app.
4) Open 'Import contacts' screen of FTU app and push 'Facebook' button.
5) Then, you can see certificate error screen on FTU app.
6) Close the screen and open Browser app.
7) Visit https://www.facebook.com/ by Browser app. Then, you can see certificate error because of expiration of certificate.
8) Click 'view site' button and see the facebook.com on your browser.
9) Open 'Import contacts' screen of FTU app again and push 'Facebook' button.
10) FTU app connects to facebook.com via https without any certificate errors.

As you said, 'view site' button doesn't work on Firefox OS simulator 2.0 and 2.1,
but as far as I tried, it works on recent B2G-emulator.

If you cannot proceed 8) on my procedure, please use recent B2G-emulator.

Comment 9

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

'visit site' button is not working on Flame. I will try on emulator later.

Comment 10

[Daniel Veditz [:dveditz]]

There is no certificate management UI on Firefox OS, but it's not uncommon for corporate services to need to go through a MITM security/logging box. The hacky workaround was to make certificate exceptions in the browser global to the device (as patrick said in comment 6).

The user should not be allowed to make an exception in an <iframe> because then they have no way to know for which site they are making that exception, it has to be the top-level browser tab.

I don't know if exceptions in FxOS were intended to be permanent (trust on first use, the default in Firefox desktop) or only for the session (until phone rebooted). It would be nice for users to get the choice, but phone UI is hard.

Comment 11

[Daniel Veditz [:dveditz]]

Camilo: Do you know the model that was intended for b2g certificate exceptions? Are they supposed to be permanent or only until reboot?  I also assume the reporter is wrong about whether "browser" exceptions were intended to create exceptions for other apps (because there's no other way to create exceptions).

Comment 12

[Camilo Viecco (:cviecco)]

I dont remember agreeing on a model. To my understanding they are supposed to be permanent. You are also correct in that the browser is how exceptions are supposed to be done.

I agree with you on not allowing exceptions for iframed content.

Comment 13

[Muneaki Nishimura]

Attachment: Refined PoC app

Comment 14

[Muneaki Nishimura]

Pushing 'visit link' button on cert-error page remains in effect even after rebooting the device.
So when once a user accept certificate error against a host in any application,
all applications on the device allow invalid certificates for the host permanently.

I attached Refined PoC app which can run on the real devices.
1) Please install the application via app-manager to the device.
2) Visit https://selfsigned.jssec.org/ by stock browser application.
3) Then, cert-error page is shown. Please push 'visit link' button and see the page.
4) Start the PoC app and push the button.
5) The app sends a system-xhr to the https://selfsigned.jssec.org/ and it retrieves HTML resources
   despite invalid certificate.
6) Reboot the device.
7) Repeat procedure 4) and 5). You can see the PoC app can connect to the host with invalid certificate
   even after rebooting device.

Comment 15

[Muneaki Nishimura]

Above my comment was incorrect.
Pushing 'visit link' button remains in effect UNTIL rebooting the device.
I apologize my mistake.

Comment 16

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

Patrick, we have more info. Can you look into this? Thank you.

Comment 17

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

I can't see the certificate error page in today's PVT build, filed bug 1056620.

From STR in comment 15 and comment 16, it doesn't seem the button is working improperly. 'Visit link' provides the ability to access the site until next reboot. That is the expected behavior AFAIK.

Comment 18

[Daniel Veditz [:dveditz]]

It's perhaps unclear UI, but this is working as intended. Once the user says a cert is acceptable for a site the phone ecosystem (it's all just Firefox underneath) trusts it. There is no separate concept of "trust this for apps", it's either trusted or not.