stack-based bufferoverflow

[RootUp]

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==ABORTING

Almost similar to #81 except we have used notification in this case.