-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<https://android.googlesource.com/platform/bionic.git/+/829c089f83ddee...>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
>> 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-security-discuss@**
> googlegroups.com <android-security-discuss@googlegroups.com>.
> To unsubscribe from this group, send email to android-security-discuss+**
> unsubscribe@googlegroups.com<android-security-discuss%2Bunsubscribe@googleg roups.com>
> .
> 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 | n...@google.com | 650.214.4037
On Sun, Nov 18, 2012 at 10:40 AM, Nick Kralevich <n...@google.com> 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
>>> 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-security-discuss@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.
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)
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 <n...@google.com<javascript:>> > 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:
> >> 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 <javascript:>. > >> To unsubscribe from this group, send email to > >> android-security-discuss+unsubscribe@googlegroups.com <javascript:>. > >> For more options, visit this group at > >> http://groups.google.com/group/android-security-discuss?hl=en.
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.
> 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 <n...@google.com>
>> 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:
>> >> 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+**unsubscribe@googlegroups.com.
>> >> 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>.
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.
> On Sat, Jan 26, 2013 at 4:29 AM, Herve Sibert <herve....@gmail.com<javascript:>
> > 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 <n...@google.com> >>> 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:
>>> >> 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+**unsubscribe@googlegroups.com. >>> >> 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>.
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
On Sat, Jan 26, 2013 at 10:17 AM, Herve Sibert <herve.sib...@gmail.com>wrote:
> 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.
>> On Sat, Jan 26, 2013 at 4:29 AM, Herve Sibert <herve....@gmail.com>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 <n...@google.com>
>>>> 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:
>>>> >> 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**scribe@googlegroups.com.
>>>> >> 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>.
> --
> 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-security-discuss@googlegroups.com.
On Sat, Jan 26, 2013 at 4:25 PM, Nick Kralevich <n...@google.com> 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 <herve.sib...@gmail.com>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.
>>> On Sat, Jan 26, 2013 at 4:29 AM, Herve Sibert <herve....@gmail.com>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 <n...@google.com>
>>>>> 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:
>>>>> >> 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**scribe@googlegroups.com.
>>>>> >> 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>.
>> --
>> 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-security-discuss@googlegroups.com.
On Sunday, January 27, 2013 1:30:17 AM UTC+1, nnk wrote:
> On Sat, Jan 26, 2013 at 4:25 PM, Nick Kralevich <n...@google.com<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 <herve....@gmail.com<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.
>>>> On Sat, Jan 26, 2013 at 4:29 AM, Herve Sibert <herve....@gmail.com>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 <n...@google.com> >>>>>> 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:
>>>>>> >> 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**scribe@googlegroups.com. >>>>>> >> 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>.
>>> -- >>> 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<javascript:>
>>> .
