cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: [Android] SecureToken/NoFrak feature addition
Date Fri, 31 Jan 2014 15:14:46 GMT
On Fri, Jan 31, 2014 at 8:57 AM, Joe Bowser <bowserj@gmail.com> wrote:

> On Fri, Jan 31, 2014 at 5:14 AM, Ian Clelland <iclelland@chromium.org>
> wrote:
> > On Thu, Jan 30, 2014 at 6:16 PM, Joe Bowser <bowserj@gmail.com> wrote:
> >
> >> Anyway, I propose we do the following:
> >>
> >> * Drop support for Android 2.3.x - I don't care if it's 20% of the
> >> market, if an insecure 20% and people need to stop targeting it
> >> because of how insecure it is.  We can't fix it, and Google and
> >> handset makers have no interest in fixing it either.  It's the IE6 of
> >> Mobile, and Android 2.3.x needs to die.  (In hindsight, I feel bad for
> >> giving a friend of mine my old HTC Desire HD. :( )
> >>
> >
> > +1
> >
> >
> >> * Drop support for Cordova 2.9 - I think we're at the six month window
> >> for this already, and we've only issued one point release after 2.9.0.
> >>
> >
> > +0
> >
> > If we do this, we'll need to be very clear to the community that it's
> > unsupported, and specifically that it isn't receiving any security
> updates
> > at all from this point on.
> >
> >
>
> I think we've been pretty bad about supporting 2.x branch in general.
> At least on Android, our last commit is November 1 for 2.9.1.  We
> really made a promise that we couldn't keep in saying that we were
> going to keep supporting the 2.9.x branch, and I would like to just
> come clean about this.
>

Completely agreed. In the interest of honesty, though, we need to say
"We're not releasing any more updates, and by the way, if you don't want to
be exposed to these security issues, you need to upgrade now." 2.9 vs 3.x
used to be primarily about plugins, and giving people the option of
sticking with the old everything-bundled-together architecture. Now it's
also about security, and people need to know that.


> >> * Implement NoFrak as a configurable option for people who aren't
> >> scared of the lack of certificate pinning
> >>
> >
> > We should be clear about exactly what this means -- I'm uncomfortable
> with
> > just "implement NoFrak" as a goal; it's not a phrase that means anything.
> > I'd split this into a couple of proposals:
> >
> >   1. Remove the Cordova Whitelist (not really cool with that, especially
> on
> > other platforms -- if an app wants to do it, that's what origin="*" is
> for)
>
> NoFrak still uses the Whitelist XML and still implements *, and I'm
> glad that you're not cool with removing the whitelist.  Neither am I,
> and you'll see why very quickly.
>
> >   2. Use a shared secret to authenticate communication across the bridge
> > (this is a good idea, probably on all platforms -- I think there may be
> > better ways of doing this though)
>
> I like how NoFrak hijacks localStorage to do it.  If I didn't, I
> wouldn't recommend we use it. :P
>
> >   3. Use the <access> tags in config.xml to determine what domains get to
> > use the bridge (??? That's not what they're for)
>
> That kinda is what the access tags are for.  When you whitelist
> something, you allow it in the WebView, and it gets to use the bridge.
>  I'd like to see this be configurable, where we have classic mode
> which offers strict blocking, and "NoFrak" mode, which allows for
> untrusted code to appear in iFrames, but not have access to the
> bridge.
>
> >   4. Remove the ability for the client to choose the bridge interface
> (also
> > a good idea)
> >
> > I'm +1 on 2&4 here, -1 on 1&3.
> >
>
> Can we choose? I thought it was all about feature detection.
>

I'm thinking that we can keep the whitelist to restrict network access to
external resources -- as far as I know, that's what it's for. The issue of
what domains should be allowed to fire off cordova.exec calls should be
separate.

Maybe we just need an attribute on <access> tags to allow bridge access.
I'd be much more comfortable if the CapabilityManager were to filter all of
the access tags that have some attribute, like allow-cordova-apis="yes",
and only set up tokens for those.


> >
> >> * Remove support for addJavascriptInterface for any platform that uses
> >> NoFrak below Jellybean and force them to use prompt
> >>
> >
> > So this covers APIs 11-14 (Honeycomb 3.0 to ICS 4.0.4). Do you mean that
> we
> > remove addJavascriptInterface for all of those versions? I'm not sure
> what
> > "any platform that uses NoFrak below Jellybean" means.
> >
>
> Yes, because if someone right now does something stupid and whitelists
> everything, they could run untrusted Javascript, use Java reflection
> through JS and totally pwn your phone.  I didn't think anyone was
> stupid enough to release with this code, but after reading the report,
> people are that dumb (BTW: If you did this, you should unpublish your
> app.):
>
>
> https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterface-remote-code-execution/
>
> > I don't know enough about the reasons for the different bridges to know
> > whether this is a good idea or not.
> >
>
> This is why we can't have nice things!
>

Ouch... that's a good reason to disable that bridge completely for APIs <
17; never mind whether noFrak is enabled or not. If it's likely that
addJavascriptInterface has other holes like this, then we should talk about
removing it entirely.


>
> >
> >> Now, I started work on moving NoFrak to 3.x on my own personal fork
> >> once the PoC author signed the ICLA, and you can find the branches on
> >> my GitHub:
> >>
> >> https://github.com/infil00p/cordova-android/tree/SecureToken
> >> https://github.com/infil00p/cordova-js/tree/SecureToken
> >>
> >> If we decide to do this, I'll copy the branch over to the official
> >> cordova-android and cordova-js repos and we can work on that fork
> >> there.  Right now it builds, but that's about it.  I haven't
> >> re-written the exec method yet.  Since we're moving this from a 2.9.x
> >> based version of Cordova to the current tree, there's probably a lot
> >> of code that can be refactored and removed.  It also needs a lot of
> >> cleanup, so any help with that would be awesome.
> >>
> >> Also, we're going to need tests if we're going to add this as a
> >> feature.  This is a lot of code, but it's probably a good idea to add
> >> this.
> >>
> >> Joe
> >>
> >
> > Sorry to complicate things :)
> >
> > If we're doing this, I'm more than willing to help out; security is
> > important. Let me know what I can help you with.
> >
>
> Awesome! Thanks for responding so quickly.
>
> Joe
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message