Skip to content

Address Sanitizer fails to intercept function in shared library opened with RTLD_DEEPBIND #611

Open

Description

@Keno

I just found out that if an application opens a shared library (both built with address sanitizer) using RTLD_DEEPBIND, address sanitizer will fail to intercept the functions called from the so opened shared library. In my particular case, this manifested itself as a strdup which, though originally skipping any interceptors and going into libc, would eventually call asan's allocator. However the same did not happen for free (since it went straight into glibc's free), so it failed to intercept free (or rather there was an allocator mismatch). I am not familiar enough with glibc to say whether this can be fixed or not, but perhaps we could drop the RTLD_DEEPBIND flag in our dlopen interceptor and issue a warning to the user.

Activity

  1. eugenis commented on Oct 12, 2015

    @eugenis
    Contributor

    Interesting. I think this has no chance of working with static-libasan, so we should either remove DEEPBIND or complain about it or both. It works with -shared-libasan with clang but not with gcc, because gcc does not add DT_NEEDED for libasan to shared libraries.

  2. kcc commented on Oct 12, 2015

    @kcc
    Contributor

    On Mon, Oct 12, 2015 at 9:30 AM, Evgeniy Stepanov notifications@github.com
    wrote:

    Interesting. I think this has no chance of working with static-libasan, so
    we should either remove DEEPBIND or complain

    I'd say we need to complain and exit.
    (We may of course, have a flag to guard the logic here, but that's on
    overkill)

    about it or both. It works with -shared-libasan with clang but not with
    gcc, because gcc does not add DT_NEEDED for libasan to shared libraries.

    —
    Reply to this email directly or view it on GitHub
    #611 (comment).

  3. added a commit that references this issue on Feb 3, 2017
  4. yugr commented on Feb 15, 2017

    @yugr

    Does this boil down to detecting RTLD_DEEPBIND in dlopen interceptor?

  5. kcc commented on Feb 16, 2017

    @kcc
    Contributor

    I'd guess so.

  6. added a commit that references this issue on Nov 14, 2017
  7. added a commit that references this issue on Nov 28, 2017
  8. FerCampos commented on Feb 26, 2018

    @FerCampos

    Hi!
    I have an environment in which I am using an external SDK. This SDK consist of a shared library I link with, and which makes use of dlopen to open other libX.so with RTLD_DEEPBIND flag. I'm not interested at all on sanitize the SDK, I only want to sanitize my own code.

    How should I proceed? I'm confused about the different -shared-libasan/-static-libasan options.
    As far as I understand, compiling with -static-libasan (GCC6) should inject all the sanitizer code in my binary and should have no effects on non-sanitized SDK, but I get an error on SDK trying to dlopen the .so:
    Couldn't load libXXX.so: System error code(-2): libXXX.so: cannot open shared object file: No such file or directory

    Using LD_LIBRARY_PATH to allow the SDK finding its libXXX.so I get the famous _int_free SEGV ASAN error. Seems like the SDK is redefining any alloc/free function, so there is a mismatch on symbol resolution (SDK vs Asan).

    Looks like linking with -fsanitize=address changes the order of symbols lookup/LD_PATH. I would need to isolate the SDK so it remains using libc or its own implementation (I don't know how internally works and I don't have access to source code neither).

    I want this behavior #871 (comment), but I'm not able to make the SDK run when my binary is using asan.

    I am open to use blacklist, suppression list, attribute((no_sanitize("address"))) or any other option, but I would like to understand the problem.

    Any hints?
    Thanks

  9. kcc commented on Mar 16, 2018

    @kcc
    Contributor

    Frankly, your best choice is to contact the vendor for the SDK and request that they support asan
    in whatever environment this SDK is being used.
    We've seen cases in the past when a closed-source SDK did something extremely asan-hostile
    and there is very little we could do there.

    If you can provide a small reproducer, where you replace the SDK with a tiny mock library,
    please file a separate bug and we'll take a look (but no promises, such problems are often hard to solve)

  10. added a commit that references this issue on Mar 9, 2019
  11. added a commit that references this issue on Mar 21, 2019
  12. 49 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions