Android 4.2 and FORTIFY_SOURCE

Showing 1-10 of 10 messages
Android 4.2 and FORTIFY_SOURCE Jeffrey Walton 11/18/12 2:05 AM
Did Android 4.2 add support for FORTIFY_SOURCE=1?
Re: [android-security-discuss] Android 4.2 and FORTIFY_SOURCE pof 11/18/12 3:55 AM
I believe yes, but not sure if support is completed.

You can check through the git commits for tag android-4.2_r1 here:

https://android.googlesource.com/platform/bionic.git/+/android-4.2_r1

Cheers,

        pof
Re: [android-security-discuss] Android 4.2 and FORTIFY_SOURCE nnk 11/18/12 7:40 AM

-D_FORTIFY_SOURCE=1 protections were added in Android in 4.2, and almost all programs on 4.2 are compiled with FORTIFY_SOURCE enabled.

Some implementation notes, for those curious:
  • FORTIFY_SOURCE protections are only enabled for applications compiled with gcc. In particiular, llvm does not support the gnu_inline function attribute necessary for FORTIFY_SOURCE to work.
  • FORTIFY_SOURCE protections are only enabled on ARM based systems. MIPS and x86 Android systems do not currently have it enabled.
The following Android libc functions are fortified:
  • bzero
  • memcpy
  • memmove
  • strcpy
  • strncpy
  • strcat
  • strncat
  • memset
  • strlcpy (not in GLIBC)
  • strlcat (not in GLIBC)
  • strlen (bionic FORTIFY_SOURCE extension. Detect strlen calls on non-null terminated character arrays.)
  • umask (bionic FORTIFY_SOURCE extension. Detect invalid umask calls. For example: umask(777) instead of  umask(0777))
  • open
  • openat
  • vsnprintf
  • vsprintf
  • snprintf
  • sprintf
  • fgets
FORTIFY_SOURCE was just one of the security hardening measures added in 4.2. A more complete list can be found at http://developer.android.com/about/versions/jelly-bean.html

-- Nick

--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To post to this group, send email to android-secu...@googlegroups.com.
To unsubscribe from this group, send email to android-security-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.




--
Nick Kralevich | Android Security | n...@google.com | 650.214.4037

Re: [android-security-discuss] Android 4.2 and FORTIFY_SOURCE Jeffrey Walton 11/18/12 10:01 AM
Awesome job. Thanks.
Re: [android-security-discuss] Android 4.2 and FORTIFY_SOURCE Herve Sibert 1/26/13 4:29 AM
Hi,

It seems that the latest NDK version does not support this, as building a native app using the NDK and shared libs from an Android 4.2 device (i.e. compiled with FORTIFY_SOURCE enabled) fails, mentioning undef references to some of the related functions (e.g. __strlen_chk).

Do you confirm this, and if so when will there be an Android NDK that is compatible with FORTIFY_SOURCE (I can always replace the original libs of the NDK with those I got from the device, but that's rather a temporary fix)

Cheers
Hervé
Re: [android-security-discuss] Android 4.2 and FORTIFY_SOURCE nnk 1/26/13 6:58 AM

You're running into a couple of different problems here.

1) AFAIK, FORTIFY_SOURCE support isn't in the NDK yet.
2) Some of the FORTIFY_SOURCE extensions (i.e., fortified strlen(), strchr(), strrchr(), maybe umask()) were committed after the code freeze for the 4.2* series.  They'll be available in a future Android release.

To hack around your problem, you can supply your own implementation of __strlen_chk() in your code.  Android's implementation can be found at https://android.googlesource.com/platform/bionic/+/master/libc/bionic/__strlen_chk.cpp


Re: [android-security-discuss] Android 4.2 and FORTIFY_SOURCE Herve Sibert 1/26/13 10:17 AM
Thank you, that's working as well.

The additional shared lib I use from an Android 4.2 build (call it libext.so) has undef deps on the libc functionsit uses, but now this includes __strlen_chk , __strcat_chk and __strncpy_chk, which are indeed in libc.so from my 4.2, but not in the NDK.

I'm wondering why libext.so does not have undefs on strlen, strcat and strncpy instead (as they are those that are finally called). Does it have to do with the inlining used in fortifying? Ie. is it normal that shared libs built with the toolchain have direct dependencies on the fortified functions, or is my libext.so wrongly built?

Just trying out to figure a clean workaround (e.g. how to mix this libext.so with *any* NDK version)
Re: [android-security-discuss] Android 4.2 and FORTIFY_SOURCE nnk 1/26/13 4:25 PM
Your library is built correctly.  FORTIFY_SOURCE works by substituting, at compile time, different versions of libc functions depending on whether or not the compiler knows the size of the buffer you're dealing with.  The implementation of those functions continues to be in libc.

Consider the following code:

1: int main(int argc, char ** argv) {
2:   char buf[10];
3:   memcpy(buf, "0123456789", sizeof(buf));
4:   // The next line will segfault with Android's FORTIFY_SOURCE extensions
5:   size_t buf_len = strlen(buf);
6:   size_t argv0_len = strlen(argv[0]);
7:   printf("%d %d\n", buf_len, argv0_len);
8:   return 0;
9: }

When -D_FORTIFY_SOURCE=1 is enabled, the code essentially gets rewritten to:

1: int main(int argc, char ** argv) {
2:   char buf[10];
3:   memcpy(buf, "0123456789", sizeof(buf));
4:   // The next line will segfault with Android's FORTIFY_SOURCE extensions
5:   size_t buf_len = __strlen_chk(buf, sizeof(buf));
6:   size_t argv0_len = strlen(argv[0]);
7:   printf("%d %d\n", buf_len, argv0_len);
8:   return 0;
9: }

Note the substitution on line 5, but not on line 6.  That's because, on line 5, we know the length of the buffer we're dealing with, whereas line 6 has no compile time information about the size of argv[0].

Because the implementation of these functions remains in libc, attempting to run programs compiled with FORTIFY_SOURCE on older Android releases will result in dynamic linking errors.  Older Android libc versions just don't implement the various __*_chk functions. This isn't a problem for binaries that ship with the platform, but is problematic for developers looking to create binaries that work across all Android releases.

You have a few options:

1) Don't use FORTIFY_SOURCE.
2) Statically link a copy of libc into your libext.so
3) Supply an implementation of the various __*_chk methods in your code.

In theory, it might be possible to implement FORTIFY_SOURCE entirely as inline functions, so that there's no need for __*_chk functions in libc.  Neither Android's libc nor GNU's libc have taken that route.

Hope this helps.

-- Nick

For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Nick Kralevich | Android Security | n...@google.com | 650.214.4037
Re: [android-security-discuss] Android 4.2 and FORTIFY_SOURCE nnk 1/26/13 4:30 PM



Sorry, forgot option 4:
4) Accept that your application will only run on newer Android releases and not on older releases.
Re: [android-security-discuss] Android 4.2 and FORTIFY_SOURCE Herve Sibert 1/26/13 6:59 PM
I guess "allowing people to use libext.so with the NDK without giving them specific advice" means going for options 1 or 2.

Thank you for the comprehensive list of options, definitely helps!