On Sat, Jul 7, 2012 at 12:02 PM, Jeffrey Walton <noloa...
> Hi Nick,
> That list is very good. Its helpful for those who want to follow
> Google's posture and verify the platform security measures. A few
> comments and questions...
> > Android 1.5+
> > * ProPolice to prevent stack buffer overruns (-fstack-protector)
> Why not all functions with -fstack-protector-all? I know the DoD has
> some interesting stack based attacks, and I try to make it as
> uncomfortable/difficult as possible even for [seemingly] safe function
Last time I tried enabling -fstack-protector-all, Android refused to boot,
with segfaults in libc. I haven't had time to dig into this further. I'm
happy to review contributions if someone wants to make this change.
FYI: support for the %n format specifier in Android was explicitly removed,
to stop the worst of the format string attacks.
(near line 560)
In Android, a format string attack will generally only get you
an information leak.
Library and mmap() randomization is in 4.0+. Heap randomization is in
4.0.3+. Linker and executable (PIE) randomization is in 4.1+.
> Android 4.1+
> > * Read-only relocations / immediate binding (-Wl,-z,relro -Wl,-z,now)
> I was surprised Full RELO was not added immediately after Gingerbreak
> (or before).
Relro was more complicated to implement. Android's dynamic linker didn't
have relro support at all, and it needed to be written from scratch. The
static linker used on Android, GOLD, had bugs in it's relro handling (
). And various
bugs were revealed when relro was enabled. All of these changes take time
to work through.
> I also prefer -Wl,-z,nodlopen and -Wl,-z,nodldump to try and make it
> as uncomfortable/difficult as possible on an attacker. Plus, I don't
> like plugin architectures since I don't want programs loading any
> binary in a directory. Google essentially takes the same position with
> DEX files.
At first glance, this sounds like a good idea. I'd need to investigate it
more to see if it's feasible in Android.
> I tried to track this down some time ago, but had a hard time with the
> modified build system: Are -Wall, -Wextra, -Wconversion,
> -Wstrict-overflow and other aggresive warnings enabled? GCC has some
> very good static analysis capabilities. Its a shame they are not used
> more often (and even belittled at times:
I'm away from my build environment right now, so I can't verify which
options are enabled...
> I know there are problems in the kernel with GCC alias violations in
> random.c and prng.c. I believe GCC should have warned about the
> problems. The files were duplicated four times for platforms in
> Android, so Android suffers the problems 4x. The files are also a bit
> fragile on their buffer handling (if particular changes are made,
> there will be stack problems). Finally, the zeroizers are subject to
> dead code removal by the optimizers.
. I believe
upstream is aware of this.
> I also know GCC *lacks* warnings for unsafe string functions such as
> strcpy and strcat (I was not successful in a GCC feature request). Is
> there a policy/procedure in place to actively hunt them down and
> replace them with BSD's safer functions, such as lstrcpy and lstrcat?
> If not, it would probably be a good idea since bionic does not have
> Glibc's FORTIFY_SOURCE feature (IIRC).
There's no prohibition on strcpy / strcat per-se, but for obvious reasons,
their use is discouraged. We try to avoid programming in native code if at
all possible, preferring memory safe languages such as java. Our
per-application sandbox also protects against the compromise of an
individual application, so a simple buffer overflow on Android doesn't have
the same severity compared to desktop operating systems.
bionic support for -D_FORTIFY_SOURCE=1 will be available in a future
Nick Kralevich | Android Security | n...
@google.com | 650.214.4037