Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDK doesn't capture stack buffer overflow #3983

Open
philipphofmann opened this issue May 14, 2024 · 1 comment
Open

SDK doesn't capture stack buffer overflow #3983

philipphofmann opened this issue May 14, 2024 · 1 comment

Comments

@philipphofmann
Copy link
Member

philipphofmann commented May 14, 2024

Description

The SDK doesn't capture a crash report for a stack buffer overflow:

char buffer[10];
// Intentionally write beyond the buffer's boundary
for (int i = 0; i < 20; i++) {
    buffer[i] = 'a' + i;
}
// This access causes a crash due to stack buffer overflow
printf("Buffer content: %s\n", buffer);
@philipphofmann philipphofmann changed the title SentrySDK.crash doesn't work in debug SDK doesn't capture stack buffer overflow May 15, 2024
@philipphofmann
Copy link
Member Author

philipphofmann commented May 15, 2024

It seems like iOS and macOS immediately terminate the program when there is a stack buffer overflow. The Xcode crash reports show that the code above triggers a SIGSEGV on iOS and a SIGABRT on macOS, which our signal handler usually captures.

iOS

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes: 0x0000000000000001, 0x0000000000000000
VM Region Info: 0 is not in any region.  Bytes before following region: 4335435776
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                      102698000-102700000    [  416K] r-x/r-x SM=COW  /Users/USER/Library/Developer/CoreSimulator/Devices/F3AD65DB-4549-4036-87D8-DC669C54D884/data/Containers/Bundle/Application/9B3A4195-2201-40E1-BE33-8164FC73BF08/iOS-Swift.app/iOS-Swift
Termination Reason: SIGNAL 11 Segmentation fault: 11
Terminating Process: exc handler [82237]

macOS

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process:   macOS-Swift [8814]

Application Specific Information:
stack buffer overflow

Because we can't really debug our signal monitor SentryCrashMonitor_Signal.c and the mach exception monitor SentryCrashMonitor_MachException.c, I enabled logging for SentryCrash by adding SentryCrashLogger_Level=TRACE to the GCC_PREPROCESSOR_DEFINITIONS. The logs show that we neither receive a signal or a mach message. The logs stop after printing the buffer

Buffer content: abcdefghijklmnopqrst\317o�

When triggering a crash with SentrySDK.crash the logs show messages of the mach exception handler

DEBUG: SentryCrashMonitor_MachException.c (327): void *handleExceptions(void *const): Trapped mach exception code 0x1, subcode 0x0
DEBUG: SentryCrashMachineContext.c (159): void sentrycrashmc_suspendEnvironment_upToMaxSupportedThreads(thread_act_array_t *, mach_msg_type_number_t *, mach_msg_type_number_t): Suspending environment.
// ...

As the Xcode crash report of macOS mentions System Integrity Protection and buffer overflows are a security risk I assume that iOS and macOS immediately terminate the program without sending any signals or mach messages to SentryCrash to avoid potential security issues. We can investigate this further, but I believe there isn't anything we can do, except to check if MetricKit would surface such crashes.

@armcknight, do you maybe have any thoughts on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Needs Discussion
Development

No branches or pull requests

2 participants