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! On Sunday, January 27, 2013 1:30:17 AM UTC+1, nnk wrote: > > > > > On Sat, Jan 26, 2013 at 4:25 PM, Nick Kralevich <[email protected]<javascript:> > > wrote: > >> 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. >> > > Sorry, forgot option 4: > 4) Accept that your application will only run on newer Android releases > and not on older releases. > > >> >> 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 >> >> On Sat, Jan 26, 2013 at 10:17 AM, Herve Sibert >> <[email protected]<javascript:> >> > wrote: >> >>> 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) >>> >>> >>> On Saturday, January 26, 2013 3:58:22 PM UTC+1, nnk wrote: >>> >>>> >>>> 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<https://android.googlesource.com/platform/bionic/+/master/libc/bionic/__strlen_chk.cpp> >>>> >>>> >>>> >>>> >>>> On Sat, Jan 26, 2013 at 4:29 AM, Herve Sibert <[email protected]>wrote: >>>> >>>>> 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é >>>>> >>>>> >>>>> On Sunday, November 18, 2012 7:01:58 PM UTC+1, Jeffrey Walton wrote: >>>>> >>>>>> Awesome job. Thanks. >>>>>> >>>>>> On Sun, Nov 18, 2012 at 10:40 AM, Nick Kralevich <[email protected]> >>>>>> wrote: >>>>>> > >>>>>> > -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/**a**bout/versions/jelly-bean.html<http://developer.android.com/about/versions/jelly-bean.html> >>>>>> > >>>>>> > >>>>>> > -- Nick >>>>>> > >>>>>> > On Sun, Nov 18, 2012 at 3:55 AM, Pau Oliva Fora <[email protected]> >>>>>> wrote: >>>>>> >> >>>>>> >> 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.**c**om/platform/bionic.git/+/**andro >>>>>> **id-4.2_r1<https://android.googlesource.com/platform/bionic.git/+/android-4.2_r1> >>>>>> >>>>>> >> >>>>>> >> Cheers, >>>>>> >> >>>>>> >> pof >>>>>> >> >>>>>> >> >>>>>> >> On 11/18/2012 11:05 AM, Jeffrey Walton wrote: >>>>>> >>> >>>>>> >>> Did Android 4.2 add support for FORTIFY_SOURCE=1? >>>>>> >>> >>>>>> >> >>>>>> >> -- >>>>>> >> 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+**unsub**[email protected]. >>>>>> >> For more options, visit this group at >>>>>> >> http://groups.google.com/**group**/android-security-**discuss?hl=* >>>>>> *en <http://groups.google.com/group/android-security-discuss?hl=en>. >>>>>> >> >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Nick Kralevich | Android Security | [email protected] | 650.214.4037 >>>>>> > >>>>>> >>>>> >>>> >>>> >>>> -- >>>> 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]<javascript:> >>> . >>> >>> To unsubscribe from this group, send email to >>> [email protected] <javascript:>. >>> Visit this group at >>> http://groups.google.com/group/android-security-discuss?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> >> >> -- >> Nick Kralevich | Android Security | [email protected] <javascript:> | >> 650.214.4037 >> > > > > -- > Nick Kralevich | Android Security | [email protected] <javascript:> | > 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]. Visit this group at http://groups.google.com/group/android-security-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
