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.
