Closed Bug 799631 Opened 12 years ago Closed 5 years ago

Add APIs for java code in addons to interact with fennec

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
All
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: kats, Unassigned)

References

Details

Bug 794479 allows addons to load arbitrary java code into the fennec process, but currently that code can't do anything useful (at least not easily) since it doesn't have handles to fennec UI objects. We need to add APIs that allow the addons to do useful things safely.
I think it would be awesome if we could provide APIs that prevent add-ons from creating Java crashes that bring down the browser. We have a hard enough time preventing those on our own, and I worry that it would be really hard to catch Java bugs in add-on review if we ever want to host these add-ons on AMO.
It would be, but I don't know if that's entirely possible. AFAIK an uncaught exception on the UI thread will always trigger a fennec crash, and if we allow the addons to add UI widgets with any sort of callback from the android platform it will be near impossible to guard against every single possible exception point. We can certainly try to make it as hard as possible though :)
Hm, is there a way for us to make it obvious that add-on code is in the crash stack? That would make investigating crash reports less confusing (and make us less likely to waste our time trying to figure out a crash that was actually just caused by an add-on). I'm just a believer that if there's a place for add-ons to mess up, they'll probably do it :)
Unlike binary addons (or js addons for that matter) we'll have stack traces for any crashes in java addon code
Flags: sec-review?
Are these Java plugins sandboxed? Will they only have access to APIs that we allow them to see, or will they basically be able to execute anything, including Android APIs?

I think it will be really cool to see some innovative plugins appear that do interact with the OS. But that also raises some security questions and concerns.

For example, maybe we would have to tell users that installing a Java addon will give this addon access to the same kind of resources that Firefox has (the same list of permissions that appears and that you have to agree to when you install Firefox initially).

That list of permissions is pretty broad, so for example a malicious addon would be able to access your gps and camera.

Not saying that is an issue, just something we need to think about :-)
The plugins would not be sandboxed. Using Java's reflection capabilities they will be able to do anything that we can do in Fennec's Java code. Somebody mentioned trying to use the SecurityManager classes to try and limit what the plugin can do, but SecurityManager appears to not be supported on Android. Specifically the Android Javadoc for java.lang.SecurityManager says this:

"Legacy security code; do not use.

Security managers do not provide a secure environment for executing untrusted code. Untrusted code cannot be safely isolated within the Dalvik VM. "

Pretty much says it all. :/
We could do some inspection of the addons in the code that loads them into firefox and see what Android APIs they possibly talk to. By inspecting the dalvik class files.

Technically this is possible, but it is absolutely not 100% secure. Things will fall through.
Copied from a discussion on irc:

st3fan | ok so what you can do on Android is define service apis (using idl) and then those services and firefox can talk to eachother and do 'stuff'. those services would be *installed applications* with their own set of security permissions that a user has to agree to. and they also run as a different uid so they are not in the same space as firefox.

st3fan | that still means we would have to define specific (narrow) APIs to expose but there is no reason why the UI could not be modified by these services, it is just a more difficult but more secure implementation
(In reply to Stefan Arentz [:st3fan] from comment #7)
> We could do some inspection of the addons in the code that loads them into
> firefox and see what Android APIs they possibly talk to. By inspecting the
> dalvik class files.
> 
> Technically this is possible, but it is absolutely not 100% secure. Things
> will fall through.

I don't think is even theoretically 100% secure. You could write some java code that downloads instructions from the internet and runs it using reflection, so it could be doing malicious things without having observably malicious things in the dalvik class files. And since they're compiled bytecode, it would be hard or impossible to tell what the calls to the network stack are doing with the incoming data.

(In reply to Stefan Arentz [:st3fan] from comment #8)
> st3fan | that still means we would have to define specific (narrow) APIs to
> expose but there is no reason why the UI could not be modified by these
> services, it is just a more difficult but more secure implementation

i don't understand this part - how would the (fennec) UI be modified by services running in different android processes?
(In reply to Kartikaya Gupta (:kats) from comment #9)

...

> (In reply to Stefan Arentz [:st3fan] from comment #8)
> > st3fan | that still means we would have to define specific (narrow) APIs to
> > expose but there is no reason why the UI could not be modified by these
> > services, it is just a more difficult but more secure implementation
> 
> i don't understand this part - how would the (fennec) UI be modified by
> services running in different android processes?

I mean that fennec would expose a service api with methods like 'addButtonToLocationBar()'. So the addons would not contain any UI code, they would just tell fennec what to do and get callbacks when those UI items are hit/changed/edited.

I know, it gets complicated :-/
Ah, I see. At that point it becomes simpler to not have java addons at all and just expose those APIs through the NativeWindow API we already expose to addons via javascript.
Flags: sec-review? → sec-review?(mgoodwin)
Some additional comments from interested parties can be found at https://staktrace.com/spout/entry.php?id=778
Depends on: 805436
From some IRC discussion today, here is a use case for java add-ons that is hard to do any other way: adding support for the "S Pen" that comes with the galaxy note [1]. According to the docs [2], to use the SDK we would have to bundle some .so and .jar files with our application, which we don't want to do for all users since it would bloat the APK. Doing this in a java add-on would be perfect, since we could bundle the extra stuff in the add-on.

[1] http://developer.samsung.com/s-pen-sdk
[2] http://developer.samsung.com/s-pen-sdk/technical-docs
(In reply to Kartikaya Gupta (:kats) from comment #13)
> From some IRC discussion today, here is a use case for java add-ons that is
> hard to do any other way: adding support for the "S Pen" that comes with the
> galaxy note [1]. According to the docs [2], to use the SDK we would have to
> bundle some .so and .jar files with our application, which we don't want to
> do for all users since it would bloat the APK. Doing this in a java add-on
> would be perfect, since we could bundle the extra stuff in the add-on.

You could also argue that we simply need a way to make Fennec more modular for our own purposes. I don't think that implies that we must open up the add-on API to allow arbitrary Java and native code?
(In reply to Stefan Arentz [:st3fan] from comment #14)
> You could also argue that we simply need a way to make Fennec more modular
> for our own purposes.

While that is true, no amount of modularity will solve this particular problem, where we want to ship some binary blob to users on particular hardware but not others. The only way to do that is to have separate APKs available via google play, where one APK is for note users only and the the other APK is for everything else. I don't think that's something we want to do - and if we do, we can do that regardless of Fennec modularity.

> I don't think that implies that we must open up the
> add-on API to allow arbitrary Java and native code?

To me it seems like the cleanest way to support this S Pen thingamajig. I'm open to suggestions though.
mgoodwin, any update on this further to what we discussed during the sec-review?
Just some thoughts: Android already supports a sandbox for applications. Any add-on (JS or Java) would still be bound by that sandbox. JS add-ons have full control over much of the Gecko platform and, on desktop, have full control over the UI too. The Java add-ons would have the same kind of abilities. I don't think we are introducing anything new here.

One thing we do want to be able to do is visually inspect the Java code, like we do for JS code, when uploading to AMO. Binary C/C++ code does not allow us to do this and it makes reviewing add-ons much more difficult. I think the Java code would be in byte code format, making it difficult to review as well.
(In reply to Kartikaya Gupta (:kats) from comment #16)
> mgoodwin, any update on this further to what we discussed during the
> sec-review?

Not really. I have my own concerns (equivalent to bug 783921) but if the consensus is that this is desirable and the security risks are acceptable then clearly this is the way forward.

(In reply to Mark Finkle (:mfinkle) from comment #17)
> Just some thoughts: Android already supports a sandbox for applications. Any
> add-on (JS or Java) would still be bound by that sandbox. JS add-ons have
> full control over much of the Gecko platform and, on desktop, have full
> control over the UI too. The Java add-ons would have the same kind of
> abilities. I don't think we are introducing anything new here.

I accept this 100%; this isn't something new. My concern here comes from the fact that Android isn't desktop - the opportunities for attackers to do bad stuff by other means are different.

> One thing we do want to be able to do is visually inspect the Java code,
> like we do for JS code, when uploading to AMO. Binary C/C++ code does not
> allow us to do this and it makes reviewing add-ons much more difficult. I
> think the Java code would be in byte code format, making it difficult to
> review as well.

Agreed. I wonder if we can provide a means for authors to submit Java sources that we then build?
bug 794479 allows intimate, and perhaps fragile, interaction between addon java code and firefox itself.  on the other hand, it would also be possible for addons to bundle an apk file instead of a dex file, which would enable the addon to run entirely separately from firefox, with its own (perhaps more restricted) security sandbox, and communicate with firefox through service interfaces.  this would also have the advantage that it could be engineered so that addons could not crash firefox.  you could argue for either of these approaches.  i don't think we should consider running addons in a separate process that shares firefox's uid as i don't see the advantage in that - you would be paying the separation cost without realizing the security advantage.

with the apk approach, the "add to firefox" button would download the apk file and then hand the apk off to android, which would list the addon's permissions and prompt the user to confirm the installation.  amo could parse the addon's manifest and enforce various restrictions on firefox apk addons that are distributed through amo, perhaps prohibiting them from requesting certain permissions but at a minimum requiring that they support a specific intent that firefox would use to activate them.  this raises the question of whether regular android apps should be able to use the same mechanism to integrate with firefox or if it should be restricted to addons installed through firefox's ui.

either way i would like to see api's for:

* (un)registering first-chance input listeners, allowing addons to augment or replace default handling in firefox.
* adding/removing "overlay" android ui widgets. firefox would essentially ignore the presence of these elements.
* navigating the user to a "document" that is implemented in addon-provided android ui widgets, such as "firefox start". it'd be great if gecko views could be embedded in such a document but i don't know how difficult that would be to implement.
(In reply to 004a0041 from comment #20)
> bug 794479 allows intimate, and perhaps fragile, interaction between addon
> java code and firefox itself.  on the other hand, it would also be possible
> for addons to bundle an apk file instead of a dex file, which would enable
> the addon to run entirely separately from firefox, with its own (perhaps
> more restricted) security sandbox, and communicate with firefox through
> service interfaces.

The problem with this approach is that the "service interfaces" would have to be explicitly defined by FF. And if we're going to be explicitly defining every service interface anyway, then we might as well define them on the NativeWindow JS API which add-ons already have access to. Also note that any "service interfaces" across APKs is going to be pretty limited; I don't think it's possible to create a UI view in one APK process and have it injected into another APK's process. This would limit the usefulness of the addons that could be written using this method.

I agree that allowing Java addons to manipulate Firefox directly via reflection allows for intimate and fragile interaction, but until we know what kind of things people will be doing in their addons it's going to be hard to define any sort of API that we can support, and it's probably best to err on the side of letting addons do more rather than less. Does that argument make sense?

> * (un)registering first-chance input listeners, allowing addons to augment
> or replace default handling in firefox.
> * adding/removing "overlay" android ui widgets. firefox would essentially
> ignore the presence of these elements.
> * navigating the user to a "document" that is implemented in addon-provided
> android ui widgets, such as "firefox start". it'd be great if gecko views
> could be embedded in such a document but i don't know how difficult that
> would be to implement.

Thanks, we will definitely take these into consideration.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #21)
> (In reply to 004a0041 from comment #20)
> > for addons to bundle an apk file instead of a dex file, which would enable
> > the addon to run entirely separately from firefox, with its own (perhaps
> > more restricted) security sandbox, and communicate with firefox through
> > service interfaces.
> 
> The problem with this approach is that the "service interfaces" would have
> to be explicitly defined by FF. And if we're going to be explicitly defining
> every service interface anyway, then we might as well define them on the
> NativeWindow JS API which add-ons already have access to. Also note that any

absolutely. i didn't express a preference one way or the other, and desktop is similarly intimate.  i was just suggesting options.  also note that the bug i filed, which has been dup'ed to this one, was about extending the native ui, which i myself suggested did not necessarily require running java code, if more of the java parts of android were exposed to js.  all that said,

> "service interfaces" across APKs is going to be pretty limited; I don't
> think it's possible to create a UI view in one APK process and have it
> injected into another APK's process. This would limit the usefulness of the
> addons that could be written using this method.

android actually has a lot of pre-written code for remoting ui between processes contained in the RemoteViews class.  arguably firefox may have to extend this a little to make it useful to addon developers (google added this for a very different use case) but most of the code does seem to be there.  i don't think the apk option is as limited as you may think.  finally, i don't know the details of the "S Pen" but it may require permissions that firefox doesn't have, and even if it doesn't there may certainly be other cases where addon developers would like permissions firefox doesn't ask for.  in this regard running in a separate uid may make things possible that are not possible using the intimate approach.

> I agree that allowing Java addons to manipulate Firefox directly via
> reflection allows for intimate and fragile interaction, but until we know
> what kind of things people will be doing in their addons it's going to be
> hard to define any sort of API that we can support, and it's probably best
> to err on the side of letting addons do more rather than less. Does that
> argument make sense?

that argument certainly makes sense, and i think it reflects the spirit from which xul overlays emerged.  there are certainly benefits to intimacy, and allowing people do things you couldn't have contemplated ahead of time.  i'm not opposed to this approach at all, just trying to look at everything.
Status: ASSIGNED → NEW
Dealt with by https://wiki.mozilla.org/Security/Reviews/MobileJavaAddOns. See also bug 805436.
Flags: sec-review?(mgoodwin) → sec-review+
No longer blocks: 862805
I'm not really working on this; unassigning.
Assignee: bugmail.mozilla → nobody

I don't think we're doing this any more. The days of the wild west addons are gone, we're down to "curated webextensions" now.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.