ubuntu-phone team mailing list archive

[Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

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.

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.

(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)

> 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.

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

Ciao,
  Alberto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlW4jfMACgkQVLQegMXeCFIaOACbB70Oysbr5SZu818NEEqXvQth
OwoAnRNJGerWBg/h96aDdAIteiKc7uyZ
=UbCc
-----END PGP SIGNATURE-----