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. -- @ikoz 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] > <javascript:>> 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? > >> > >> Jeff > >> > >> > On Wednesday, September 10, 2014 12:05:25 PM UTC-7, Jeffrey Walton > >> > wrote: > >> >> > >> >> > Empirically speaking, I have seen zero instances of *_chk() calls > for > >> >> > code > >> >> > that should have been fortified. > >> >> > >> >> *_chk() are part of Stack Protector. If you use -fstack-protector, > >> >> then high risk objects are checked, like C-string's. Not all objects > >> >> are checked or guarded. If you don't have a high risk object, then > you > >> >> won't see *_chk(). > >> >> > >> >> -fstack-protector-all guard all vulnerable objects (with some hand > >> >> waiving). If there's no vulnerable object, then there's no stack > >> >> protector on the particular function. If the calling convention is > >> >> wrong, then there's no stack protector on the particular function. > >> >> There's a few other reasons why the function won't be guarded even > if > >> >> it has vulnerable objects. > >> >> > >> >> In both cases (-fstack-protector and -fstack-protector-all), the > >> >> optimizer might do things such that you don't get the check you > >> >> expect. So beware of the optimizer. > >> >> > >> >> FORTIFY_SOURCES is different than stack protectors. FORTIFY_SOURCES > >> >> will use safer variants of unsafe function *if* the compiler can > >> >> deduce the destination buffer size. Effectively, that means strcpy > -> > >> >> strcpy_s (in Microsoft terms) or strcpy -> strlcpy (in BSD terms). > >> >> > >> >> In the case of FORTIFY_SOURCES, I *don't* believe you will see the > >> >> actual "safer" function call. I believe the compiler will just > insert > >> >> some code. If the destination buffer size check fails, then the code > >> >> calls abort(). > >> >> > >> >> If interested, there's no "safer" variants in Linux because of > Ulrich > >> >> Drepper. Drepper called them "horribly inefficient BSD crap" [0]. He > >> >> refused to add the safer string and memory functions of ISO/IEC > >> >> TR24731-1 to the runtime. Years later, his wisdom yielded multiple > >> >> buffer overflows in uPnP, which left millions of routers, gateways, > >> >> and other embedded devices vulnerable [1]. I'm still using one of > >> >> those unpacthed junk gateways because my ISP won't upgrade it or > >> >> replace it. Many on the list are probably suffering the same. > >> >> > >> >> Jeff > >> >> > >> >> [0] PATCH: safe string copy and concatenation [sic], > >> >> http://www.sourceware.org/ml/libc-alpha/2000-08/msg00053.html > >> >> [1] Portable SDK for UPnP Devices (libupnp) contains multiple buffer > >> >> overflows in SSDP, http://www.kb.cert.org/vuls/id/922681 > -- 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.
