
Gmail smartphone app hacked by researchers - erlendfh
http://www.bbc.com/news/technology-28895304
======
Someone1234
> A Google spokeswoman said the technology giant welcomed the research.
> "Third-party research is one of the ways Android is made stronger and more
> secure," she said.

That's a really great response and attitude. Nice to see and gives me hope
that Android will be something we can look to for security and privacy at some
stage in the not too distant future.

I wonder if a permissions overhaul is in the works? The recent change to
categorized permissions seems both like a step backwards but also like it is
showing off how flawed Android's permissions system really is. If Google
really want Android to be "stronger and more secure" this would be a good
place to start.

------
sjf
There's not many details, it looks a failure of JVM sandboxing?

Ok, the actual paper describes the problem "popular GUI frameworks by design
can potentially reveal every UI state change through a newly-discovered public
side channel — shared memory".

The attack works by watching the size of shared memory in use in /proc,
detecting UI events by allocations of shared memory, and then pre-empting the
new screen with a phishing screen.

~~~
fidotron
Sounds to me like it detects the activity to activity transition (which on
Android creates an Intent which is passed to the system and back via shared
memory) and then does something else, i.e. display a fake password entry
screen when the transition is detected.

It sounds like the actual Intent contents remain secure, however, the creation
of an Intent while a particular app is in the foreground and using a
particular amount of memory might be the kind of trigger they'd be looking
for.

An OS level patch to get around this could involve preallocating shared memory
for each application so that differences in it during the app lifecycle do not
actually occur. Modern systems have enough RAM, and there are low enough
limits on what is flying around, that this shouldn't be a problem.

~~~
giovannibajo1
or just remove /proc access from apps, which is totally useless.

~~~
fidotron
Actually it's not, and it would break enough that they wouldn't be able to do
that without complaints. See the entire permission system for another case.

Therein lies Google's problem, as once anything is usable in public it does
get used/abused. There are certain VM behaviours in compatibility mode which
are like this, where outright bugs have to be preserved in later versions for
the benefit of apps which aren't going to receive timely updates.

~~~
sjf
I would actually like to know what apps want in /proc that they can't get
through the API.

~~~
void-star
Well... how do you suppose the API gets at all the things? (not everything is
done across IPC/binder, much is in process)

~~~
giovannibajo1
The permission model in Android goes through the APIs. If you can bypass the
API to go lower-level, then you're effectively giving up the security, and
just waiting for some cool researcher (or attacker) to find ways to exploit
them.

The above makes sense if you want to assume that you need /proc at least at
some permission level. If you don't (which I think you don't), then it should
simply be unmounted in the sandbox.

IPC is the standard way to get out of the sandbox, and should be used also for
whatever features the APIs need /proc for.

