New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Apr 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

[Android] Block access to 'java.lang.Object.getClass' method in Java Bridge

Project Member Reported by mnaga...@chromium.org, Apr 3 2014 Back to list

Issue description

Since API Level 17, WebView denies access from JavaScript to Java methods not marked with @JavascriptInterface. But this feature is only enabled for apps that target API Level 17 or newer. Apps targeting previous API Levels still have access to all methods of injected Java objects enabled.

The most powerful and dangerous method exposed this way is java.lang.Object.getClass which allows JS code to execute essentially any Java code. It has been advised to block access to this method entirely, as it is should not be used anyway for regular application needs.
 
Cc: cdn@chromium.org
Labels: Cr-Security
This is essentially Enumerating Badness, which cannot really work. (Do we need to worry about Class.getClassLoader? Anything else? I know I have no hope of thinking of all the dangerous classes and methods.)

If apps target API level < 17, they are grossly vulnerable; we can't really help them much. And is it our business to? They may have their reasons.

That said, as we see from the failing tests in the CL, this is a good sanity check for us — did the tests work before because we target API level < 17 for the tests...?! Or what?

+cdn FYI
palmer@: I'm sorry, I forgot to provide a reference to the internal bug which explains   this decision -- it's b/13694467

We only worry about dangerous methods of java.lang.Object because all injected objects are inherited from it (and it's impossible not to inherit from Object). If someone inherits his object from a more powerful class, it's his own choice. If someone really needs 'getClass' exposed, he can create another method that delegates to it. Our goal here is to protect apps that didn't actually intend to expose 'getClass'.

Java bridge tests use internal functions for injecting objects, so the target API level is irrelevant. It was my fault that I didn't try running them locally, I would surely fix them before uploading the patch. The reason those test have failed is because they explicitly  use 'getClass' method. I will work around that. The fact that they were failing has just confirmed that the code actually works :)
Project Member

Comment 3 by bugdroid1@chromium.org, Apr 4 2014

------------------------------------------------------------------
r261801 | mnaganov@chromium.org | 2014-04-04T18:37:05.548470Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/java/java_bound_object.cc?r1=261801&r2=261800&pathrev=261801
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/java/java_bound_object.h?r1=261801&r2=261800&pathrev=261801
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/android/javatests/src/org/chromium/content/browser/JavaBridgeBasicsTest.java?r1=261801&r2=261800&pathrev=261801

[Android] Block access to java.lang.Object.getClass in injected Java objects

Throws a java.lang.SecurityException on Browser UI thread when an attempt is
made to execute java.lang.Object.getClass from JavaScript code via an injected
Java object.

BUG= 359528 

Review URL: https://codereview.chromium.org/213693005
-----------------------------------------------------------------
This is I think a pretty good trade-off between compatibility vs. security.
The second best trade-off would probably be exposing only the non-inherited public methods (for target level < 17). And I am still thinking if it should be the next step or not.
Status: Fixed
Re #4: This will definitely break guys who use a hierarchy of *their own* classes.

As for java.lang.Object, it doesn't have any more dangerous methods (and would it have, they can be disabled the same way).

So this proposal will increase security only for the apps which inject objects inherited from, say, java.lang.Class or Android framework classes, which isn't a good idea in the first place.

Sign in to add a comment