False positive with use of longjmp in an external library and FORTIFY_SOURCE

[Lekensteyn]

According to the FAQ, -D_FORTIFY_SOURCE is not completely supported (see also #247). False negatives are not ideal, but understandable.

However, I ran into a different problem. My application (built with ASAN) somehow reports a seemingly arbitrary stack-buffer-overflow. It turns out that a third-party (non-ASAN instrumented Lua) library used longjmp (actually _longjmp). Normally this will unpoison the stack, but because -D_FORTIFY_SOURCE was used for that application, it got replaced by __longjmp_chk (a glibc function).

The __longjmp_chk function does not invoke longjmp and is therefore missed by the interceptors for longjmp. This prevents the redzones on the stack from being unpoisoned. Subsequent use of this stack address by an ASAN-instrumented function causes a false stack-buffer-overflow report.

On Arch Linux all packages are built with -D_FORTIFY_SOURCE by default.

Suggestion

Add interceptor for __longjmp_chk. If there is support for this I could also try to prepare a patch for this.

Reproducer

Conditions:

• External library used setjmp and calls ASAN-instrumented function.
• ASAN-instrumented function invokes the external library again which triggers longjmp.
• External library passes its stack address (overlapping with the redzone) to ASAN-instrumented code (interceptor).

Implementation:

user.c

#include <stdio.h>
#include <string.h>

extern void external_callme(void (*callback)(void));
extern void external_check(void);
extern void external_stack_user(void);

static void setmsg(char *msg)
{
    strcpy(msg, "never called");
    puts(msg);
}

static void callback(void)
{
    /* Note: this triggers addition of a redzone. */
    char msg[16];
    external_check();

    /* assumption: due to longjmp, this part is never called */
    setmsg(msg);
}

int main()
{
    external_callme(callback);
    external_stack_user();
    return 0;
}

external.c

#include <setjmp.h>
#include <stdio.h>
#include <string.h>

jmp_buf jenv;

void external_callme(void (*callback)(void))
{
    if (setjmp(jenv) == 0) {
        puts("callback");
        callback();
        puts("callback returned?!");
    } else {
        puts("callback longjumped");
    }
}

void external_check(void)
{
    puts("longjmp");
    longjmp(jenv, 1);
}

void external_stack_user(void)
{
    char buf[128] = "";
    char buf2[128] = "";

    /* This will trigger the ASAN interceptor which detects an invalid stack address. */
    if (!memcmp(buf, buf2, sizeof(buf))) {
        puts("bogus");
    }
}

Makefile

CFLAGS := -g -O2
# Important: triggers use of __longjmp_chk
CFLAGS_external += -D_FORTIFY_SOURCE=2

check: user
    LD_LIBRARY_PATH=. ./user

user: user.c libexternal.so
    $(CC) $(CFLAGS) -fsanitize=address -o $@ $< -L. -lexternal

libexternal.so: external.c
    $(CC) $(CFLAGS) $(CFLAGS_external) -o $@ $< -shared -fPIC

clean:
    rm -f user libexternal.so

.PHONY: clean check

[sitsofe]

This is part of the whole "sanitizers don't support FORTIFY_SOURCE" issue. At the moment the FAQ says two things:

Q: Why didn't ASan report an obviously invalid memory access in my code?
A3: The fortify source compiler feature can mask errors that ASan is able to detect. On some systems (Ubuntu, Gentoo) fortify source is enabled by default, you can make sure it's disabled by passing -U_FORTIFY_SOURCE in your compiler flags.
Q: I've compiled my code with -D_FORTIFY_SOURCE flag and ASan, but I've got strange errors in runtime. What goes wrong?
A: Currently ASan (and other sanitizers) doesn't support source fortification, see #247

I will also note there's an effort to simply warn users that they shouldn't use FORTIFY_SOURCE and the sanitizers at the same time over on https://sourceware.org/bugzilla/show_bug.cgi?id=20422 .

[eugenis]

The thing is, rebuilding libc should not be a requirement to use sanitizers.
I agree that an interceptor for __longjmp_chk is the right solution.

[Lekensteyn]

@sitsofe I have seen those entries and linked to them, but believe that the issue is different.

Q: Why didn't ASan report an obviously invalid memory access in my code?

Does not apply here, there is no invalid memory access and thus there are no false negatives. There is a false positive issue here.

Q: I've compiled my code with -D_FORTIFY_SOURCE flag and ASan, but I've got strange errors in runtime. What goes wrong?

My code is not compiled with -D_FORTIFY_SOURCE. Instead, all external system libraries are compiled with this flag. One option is to print a clear warning that a stack-buffer-overflow (underflow) might be a false positive in this situtation. Another option is to add interceptors for __longjmp_chk.

Function __longjmp_chk is implemented in assembly and does not invoke longjmp so @kcc's suggestion in #247 to intercept foo instead of foo_chk will not help here.

@eugenis libc (glibc since 2.11) just provides __longjmp_chk (for all of longjmp, _longjmp and siglongjmp). Recompilation of libc is not needed to fix this issue (the system library I am having issues with is Lua).

[sitsofe]

@Lekensteyn : My mistake - you're right the problem stems from the system library rather than from the code you wrote.

[yugr]

FYI we try to fix this in Glibc (https://sourceware.org/ml/libc-alpha/2016-09/msg00074.html).

[Lekensteyn]

@yugr That unfortunately does not help in this case because there are three parts involved:

• system-provided glibc
• system-provided Lua (compiled with _FORTIFY_SOURCE)
• application in development (compiled without _FORTIFY_SOURCE, but with ASAN).

A workaround is to intercept longjmp via LD_PRELOAD:

#include <setjmp.h>
void __longjmp_chk(jmp_buf env, int val) {
    longjmp(env, val);
}

[yugr]

@Lekensteyn RIght, longjmp is probably the only one that really needs to be intercepted. Would you mind adding an interceptor to libasan and sending patch?

[Lekensteyn]

@yugr Sure, I was just polling for the opinion whether it is the right approach before moving forward. Given that glibc + _FORTIFY_SOURCE is quite common, I think it is. Will try to prepare a patch.

[Lekensteyn]

Proposed patch + tests: https://reviews.llvm.org/D32408

Additional information:

• macOS (checked Libc-1158.50.2) and FreeBSD support _FORTIFY_SOURCE, but only for stdio and string. longjmp has no special treatment like glibc.
• The Linux manual page feature_test_macros(7) mentions the macro and notes glibc 2.3.4 and GCC 4.0.
• glibc header showing redirections: setjmp/bits/setjmp2.h

[Lekensteyn]

Fixed in trunk, thank you @eugenis for review!

(If I did something wrong in the commit process, please LMK)