> 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 On Wed, Sep 10, 2014 at 2:30 PM, Edith Kan <[email protected]> wrote: > I agree that all the literature and discussion out there states that Fortify > support was added for 4.2 (for gcc) and 4.4 (for clang). > - NDK GCC Support for Fortify - > https://developer.android.com/about/versions/jelly-bean.html#android-42. > - NDK Clang Support for Fortify - > http://source.android.com/devices/tech/security/enhancements44.html > > I guess I was questioning whether the compiler flag actually did anything in > NDK context. > > Did anyone actually dump the symbol table of the compiled binary to verify > the flag is NOT a no-op? > > Empirically speaking, I have seen zero instances of *_chk() calls for code > that should have been fortified. -- 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.
