You are correct, I didn't check the latest NDK versions. NDK r10 and r10b contain a prebuilt android-L target platform. The libc.so binaries there seem to support FORTIFY_SOURCE for all architectures. Will need to test to make sure it can now be used while building - this is not documented in NDK release notes.
@ikoz On 12 September 2014 01:06, Jeffrey Walton <[email protected]> wrote: > On Thu, Sep 11, 2014 at 7:45 PM, ikoz <[email protected]> wrote: > > FORTIFY_SOURCE is used when building the android system since 4.2. System > > libraries and binaries make use of the secure versions of these > functions. > > > > However, as far as I know, developers cannot build their applications > > against it because the NDK does not support it, it never did. No idea > why. > > > > For a quick verification, dump the symbols of libc.so from AOSP or any > > device later than 4.2. > > Then do the same with libc.so included in the NDK package - the one the > > build system uses. > > > > You will notice that the AOSP version has a bunch of __function_chk > symbols, > > corresponding to the secure alternative functions. If you dump the > symbols > > of other system libraries you will notice undefined symbols > corresponding to > > these - the libraries make use of these functions. > > > > The NDK libc.so version has none of that. > > > Does that hold for the latest versions of Android? See, for example, > "Android 4.4, undefined reference to __printf_chk", > > https://stackoverflow.com/questions/22977898/android-4-4-undefined-reference-to-printf-chk > . > > If it still holds, then why are functions like __printf_chk being linked? > > Jeff > > > > On Friday, September 12, 2014 12:19:56 AM UTC+1, Jeffrey Walton wrote: > >> > >> On Thu, Sep 11, 2014 at 6:56 PM, Edith Kan <[email protected]> > wrote: > >> > I believe it's fairly standard. If you use gcc + fortify, it'll > >> > generally > >> > call the _chk() methods. > >> > > >> > See http://fireflyblue.blogspot.com/2008/05/gcc-fortifysource.html > >> > > >> > I wonder if NDK just doesn't support this despite the many > literature(s) > >> > stating to the contrary. > >> Well, I know Android only supports FORTIFY_SOURCES=1 (and not 2). But > >> I don't know what the difference is/are (at the moment). > >> > >> I always use the highest level available. And I file a security defect > >> if I find ` -D_FORTIFY_SOURCE=0 `. > >> > >> Jeff > >> > >> > On Thursday, September 11, 2014 3:29:26 PM UTC-7, Jeffrey Walton > wrote: > >> >> > >> >> On Thu, Sep 11, 2014 at 6:22 PM, Edith Kan <[email protected]> > >> >> wrote: > >> >> > I believe stack protector injects __stack_chk_guard. Similar > naming > >> >> > but > >> >> > different. > >> >> > > >> >> > For an example of fortified memcpy() method, see this source. > >> >> > > >> >> > > >> >> > > https://android.googlesource.com/platform/bionic/+/android-4.2_r1/libc/string/__memcpy_chk.c > >> >> > > >> >> > It's defined as __memcpy_chk() so I would expect to see a call to > >> >> > this > >> >> > for > >> >> > fortified code. > >> >> Oh, that's interesting. I recall seeing the call to abort, but I > don't > >> >> recall seeing the new function name. > >> >> > >> >> Is the new function on Android only (i.e., is it an implementation > >> >> detail), or is it pretty standard on all platforms? > >> >> > -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/d/optout.
