On Sat, Jul 7, 2012 at 12:02 PM, Jeffrey Walton <[email protected]> wrote:

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

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.


>
> > Android 2.3+
> >  * Format string vulnerability protections (-Wformat-security
> -Werror=format-security)
> I usually prefer -Wformat=2 -Wformat-security for maximum warnings.
> http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html.
>

FYI: support for the %n format specifier in Android was explicitly removed,
to stop the worst of the format string attacks.

*
https://code.google.com/p/android-source-browsing/source/browse/libc/stdio/vfprintf.c?repo=platform--bionic
(near line 560)

In Android, a format string attack will generally only get you
an information leak.


>
> > Android 4.0+
> >  * Address Space Layout Randomization (ASLR) to randomize key locations
> in memory
> Lack of runtime linker randomization meant ROP gadgets could still be
> built. This was fixed in 4.0.3.
>
> http://blog.duosecurity.com/2012/02/a-look-at-aslr-in-android-ice-cream-sandwich-4-0/
> .
>
>
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 (
http://sourceware.org/ml/binutils-cvs/2012-03/msg00067.html,
http://sourceware.org/ml/binutils-cvs/2012-03/msg00064.html). 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:
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-11/msg08325.html)
>

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

Ah, http://code.google.com/p/android/issues/detail?id=26692.  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
Android release.

-- Nick


>
> Jeff
>
> On Sat, Jul 7, 2012 at 11:20 AM, Nick Kralevich <[email protected]> wrote:
> > Hi again Antonio,
> >
> > I've updated the Android Security Overview documentation. The "memory
> > management security enhancements" section now specifies when the security
> > enhancements were added. I've also updated the documentation to account
> for
> > Android 4.1 features.
> >
> >
> http://source.android.com/tech/security/index.html#memory-management-security-enhancements
> >
> > While it may be too late for your paper, perhaps others will find it
> useful.
> >
> > -- Nick
> >
> >
> > On Sat, Jun 9, 2012 at 6:22 AM, Nick Kralevich <[email protected]> wrote:
> >>
> >> -fstack-protector was in the original Cupcake release.
> >>
> >>
> >>
> https://www.codeaurora.org/gitweb/quic/la/?p=platform/build.git;a=blob;f=core/combo/linux-arm.mk;h=fa5f67eb9a2bd66062cfbb457b394aa6024e57cb;hb=cupcake
> >> line 56.
> >>
> >> -- Nick
> >>
> >> On Sat, Jun 9, 2012 at 1:08 AM, Antonio Francesco Sardella
> >> <[email protected]> wrote:
> >>>
> >>> Hi all,
> >>> I am sorry for being insistent, but I need this information to complete
> >>> an academic paper.
> >>>
> >>> Can someone please answer my question?
> >>>
> >>>> what is the first Android/SDK version equipped with ProPolice?
> >>>
> >>>
> >>> I am pretty sure that from 2.2 "Froyo" (API level 8) on, Stack Smashing
> >>> Protector - ProPolice is present. My question is referred to older
> versions.
> >>>
> >>> Thanks in advance.
> >>>
> >>> Best regards.
> >>>
> >>> Antonio Francesco Sardella
>
> On Sat, Jul 7, 2012 at 11:20 AM, Nick Kralevich <[email protected]> wrote:
> > Hi again Antonio,
> >
> > I've updated the Android Security Overview documentation. The "memory
> > management security enhancements" section now specifies when the security
> > enhancements were added. I've also updated the documentation to account
> for
> > Android 4.1 features.
> >
> >
> http://source.android.com/tech/security/index.html#memory-management-security-enhancements
> >
> > While it may be too late for your paper, perhaps others will find it
> useful.
> >
> > -- Nick
> >
> >
> > On Sat, Jun 9, 2012 at 6:22 AM, Nick Kralevich <[email protected]> wrote:
> >>
> >> -fstack-protector was in the original Cupcake release.
> >>
> >>
> >>
> https://www.codeaurora.org/gitweb/quic/la/?p=platform/build.git;a=blob;f=core/combo/linux-arm.mk;h=fa5f67eb9a2bd66062cfbb457b394aa6024e57cb;hb=cupcake
> >> line 56.
> >>
> >> -- Nick
> >>
> >> On Sat, Jun 9, 2012 at 1:08 AM, Antonio Francesco Sardella
> >> <[email protected]> wrote:
> >>>
> >>> Hi all,
> >>> I am sorry for being insistent, but I need this information to complete
> >>> an academic paper.
> >>>
> >>> Can someone please answer my question?
> >>>
> >>>> what is the first Android/SDK version equipped with ProPolice?
> >>>
> >>>
> >>> I am pretty sure that from 2.2 "Froyo" (API level 8) on, Stack Smashing
> >>> Protector - ProPolice is present. My question is referred to older
> versions.
> >>>
> >>> Thanks in advance.
> >>>
> >>> Best regards.
> >>>
> >>> Antonio Francesco Sardella
>



-- 
Nick Kralevich | Android Security | [email protected] | 650.214.4037

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