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.
