Hey Dianne,

Thanks for that great explanation on how backdoors could be possible
in the Android Apps.

I am still looking into some possible weaknesses that I think I have
found.

Anyways thanks for explaining it to us. :P

God Bless & Thanks again,
Eric

On Aug 26, 10:33 pm, Tauren <[email protected]> wrote:
> An excellent response and helpful to me for my own reasons.  Thanks
> very much for the information.
>
> On Aug 26, 6:16 pm, Dianne Hackborn <[email protected]> wrote:
>
>
>
> > On Thu, Aug 26, 2010 at 10:18 AM, Tauren <[email protected]> wrote:
> > > Apps are thoroughly reviewed (supposedly) and
> > > request what kind of permissions are in use.
>
> > Permission enforcement doesn't not require review, it is done at runtime by
> > the platform.
>
> > >  Sandboxing is not
> > > unbeatable as proven by existing exploits, for example the Iphones
> > > jail break me escaped the sandbox of the browser after a PDF was
> > > rendered and used a kernel vulnerability to run its "jail break code"
> > > this could easily have been "Pwn me" code and it would have been done
> > > with.
>
> > Browser sandboxing is actually very different than the sandboxing that
> > Android uses.  A browser sandbox is a large amount of code implementing the
> > HTML/JavaScript/etc that prevents it from doing anything malicious.  Because
> > this code is so complicated, the browser sandbox is notoriously porous as
> > new bugs are discovered in the code.  (Same thing applies to code that
> > handles media codecs.)
>
> > In addition, PDF is not inside of the "browser sandbox."  PDF is its own
> > thing, implementing its own sandbox as part of interpreting PDF code.
>
> > Traditionally on a desktop the browser runs as you, and can do anything you
> > can.  You are protected from malicious web sites by the browser preventing
> > them from directly running code in its implementation.  Likewise a PDF
> > viewer, flash, etc.  If someone finds a bug somewhere in that code to escape
> > the sandbox, then it has as much access to the computer as you do...  which
> > is a lot.
>
> > On Android in addition to the browser's sandbox, the platform implements a
> > sandbox for each app.  App's don't run as you, they run as their own user
> > which can only do the things they are allowed by the permissions they
> > request.  So if someone escapes the browser's sandbox, they are still
> > contained within the platform's app sandbox, so they can only get access to
> > the browser app itself (its cookies, history, etc) and the few things it is
> > allowed to do with the outside world:
>
> >     <uses-permission
> > android:name="android.permission.ACCESS_COARSE_LOCATION"/>
> >     <uses-permission
> > android:name="android.permission.ACCESS_DOWNLOAD_MANAGER"/>
> >     <uses-permission
> > android:name="android.permission.ACCESS_FINE_LOCATION"/>
> >     <uses-permission
> > android:name="android.permission.ACCESS_NETWORK_STATE"/>
> >     <uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
> >     <uses-permission
> > android:name="com.android.launcher.permission.INSTALL_SHORTCUT"/>
> >     <uses-permission android:name="android.permission.INTERNET" />
> >     <uses-permission android:name="android.permission.SET_WALLPAPER" />
> >     <uses-permission android:name="android.permission.WAKE_LOCK"/>
> >     <uses-permission
> > android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
> >     <uses-permission
> > android:name="com.android.browser.permission.READ_HISTORY_BOOKMARKS"/>
> >     <uses-permission
> > android:name="com.android.browser.permission.WRITE_HISTORY_BOOKMARKS"/>
> >     <uses-permission
> > android:name="android.permission.SEND_DOWNLOAD_COMPLETED_INTENTS" />
>
> > This same rule applies to other things -- media codecs run under a different
> > user with their own set of limited permissions, etc.
>
> > This is somewhat like Chrome's process sandboxing, but applied to the entire
> > platform.
>
> > Of course there will sometimes be bugs in the platform's sandboxing (there
> > are always bugs).  Having multiple layers of security however makes it less
> > easy to do damage.
>
> > --
> > Dianne Hackborn
> > Android framework engineer
> > [email protected]
>
> > Note: please don't send private questions to me, as I don't have time to
> > provide private support, and so won't reply to such e-mails.  All such
> > questions should be posted on public forums, where I and others can see and
> > answer them.

-- 
You received this message because you are subscribed to the Google Groups 
"Android Security Discussions" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/android-security-discuss?hl=en.

Reply via email to