ubuntu-phone team mailing list archive

[Tyler Hicks <tyhicks@xxxxxxxxxxxxx>]

On 2015-07-29 11:25:27, Alberto Mardegan wrote:
> On 07/29/2015 07:07 AM, Tyler Hicks wrote:
> > This stage is not sufficient since there is no exec() performed
> > here. This removes the possibility of per-process address space
> > layout randomization (ASLR). All processes on the system that were
> > spawned by qml-booster will have the same memory layout, even if
> > the program authors are trying to do the right thing by building
> > with -fPIE.
> 
> Can you elaborate a bit on the risks of not having ASLR? As I
> understand it, since the process is confined, it still won't be able
> to perform any action that a malicious application wouldn't be able to
> do, right?

You're talking about an application that has had a vulnerability
exploited and is now "rogue"?

If so, then no, it can do something much worse than a malicious
application from the store. It can steal the user data associated with
the app and take advantage of any extra permissions that the user has
granted to the app through our prompting system.

Also, the "rogue" app might be a very popular app that is installed on
the majority of phones. It is hard for malicious apps to reach many
users.

> If I understand correctly, the risk associated to not having ASLR in
> the mapplauncher'ed applications could be exploited by an attacker by
> having the user run a malicious application which reads its memory
> layour and dump it over the internet to the attacker, which would then
> have to exploit a bug in another application, and at this point he
> could reliably know that this application will have the same memory
> layout than the malicious one (at least as far as preloaded libraries
> are concerned). And even in this case, the risk is mostly about the
> user data associated with the application.

First, the user data is the most valuable thing that we're trying to
secure. We can't dismiss its importance because its only the data
associated with a single application.

You described one attack vector. There are others, though.

For example, imagine an malicious app, which produces content such as
images, that wants to attack another app on the system, which happens to
display images, in order to steal the user data associated with that
app. If it knows of a vulnerability in the image parsing libraries used
by the app under attack, it can craft an image file based on its own
address space layout. Then it becomes easy to turn what would have
likely been a denial of service attack into something that executes
arbitrary code and steals data.

Another advantage that remote attackers would have is that if they're
trying to attack an app, they might be trying to carry out an attack
misjudge where a certain symbol is and crash the app. The user may think
that the app simply crashed and restart it. With the current
mapplauncherd, the address space layout is going to be the exact same so
the attacker gets to keep trying as long as the user keeps reopening the
app. If proper ASLR is available, the attacker is back to square one
after each crash because the address space layout will be randomized
every time the app is launched.

> I don't want to say that this is not an important issue, but I'm sure
> it's definitely not important for many apps. Since using mapplauncherd
> would anyway be optional, we could explain the risks of using it, and
> let developers decide.
> At least, I can imagine these risks to be rather irrelevant for most
> games and utilities, and indeed for all apps not accessing the network.

As mentioned above, if a given game is installed on nearly all of our
users phones and that game has a remote code execution flaw, we want to
make sure that we're not disabling the benefits of ASLR.

> (I'm not saying we shouldn't try to address this issue, by all means!
> -- continue reading below for an attempt.
> I'm saying that if it turns out that integrating mapplauncherd in a
> way that preserves ASLR defeats its performance gains, we should still
> have it available in the "unsecure" way, for people who want it)

I think this is a bad idea and doesn't follow the 'secure by default'
mindset that we strive for in Ubuntu. Even if we don't enable the
mapplauncherd approach by default, developers that may not understand
the benefits of ASLR will then be forced to chose between 'ASLR' or
'Faster App Launching'. 'Faster App Launching' will become the default
in practice.

> > The exec() will need to occur after special process initialization
> > such as setting rlimits, configuring cgroups, etc., but before
> > attempting to preload any libraries.
> > 
> > I've prototyped the difference with a simple proof-of-concept of a 
> > booster daemon and app program and the exec() slows down things a 
> > considerable amount. Any benchmarks should definitely include such
> > a change in order to not get any hopes up by looking at the
> > non-exec()ing benchmark numbers.
> 
> But the exec() does not necessarily need to load the application,
> right? It could happen when the user has not yet chosen which
> application to start, and instead of executing an app, it could exec()
> into a loader process which does all library preloading and
> initializing, and then (when the user launches an app) dlopen the app,
> close any unneeded file descriptors, call aa_change_profile and
> finally run main(). Then of course it would have to quit, and not be
> reused.

Yes, exactly!

> This would still preserve the ASLR, wouldn't it?

Yes. I think there will still be plenty of speed benefits. I don't think
the memory footprint benefits of the booster processes will be nearly as
good, though. My whole point is that it is worth benchmarking because I
think we'll still good performance.

Tyler

> 
> Ciao,
>   Alberto
> 
> -- 
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: Digital signature