Page MenuHomePhabricator

Stack buffer overflow overflow in _dbus_marshal_read_basic from eldbus due to wrong size of allocated buffer.
Closed, ResolvedPublic

Description

Hi!

It seems that there is an ABI incompatibility between eldbus and dbus libraries: eldbus thinks that BOOLEAN is char type, while dbus uses uint32_t type:
From src/lib/eldbus/eldbus_message_to_eina_value.c:

case 'b'://boolean
case 'y'://byte
  {
     unsigned char byte;
     while (eldbus_message_iter_get_and_next(iter, type, &byte))
       eina_value_array_append(value, byte);
     break;
  }

and from dbus/dbus-types.h:

typedef dbus_uint32_t  dbus_bool_t;

and dbus/dbus-marshal-basic.c:

case DBUS_TYPE_INT32:
case DBUS_TYPE_UINT32:
case DBUS_TYPE_BOOLEAN:
case DBUS_TYPE_UNIX_FD:
  {
  volatile dbus_uint32_t *vp = value;
  pos = _DBUS_ALIGN_VALUE (pos, 4);
  *vp = *(dbus_uint32_t *)(str_data + pos);
  if (byte_order != DBUS_COMPILER_BYTE_ORDER)
    *vp = DBUS_UINT32_SWAP_LE_BE (*vp);
  pos += 4;
  }
  break;

Thus, when we allocate a byte buffer into eldbus and read uint32_t value to it in dbus, we have a stack buffer overflow.
The issue was discovered by AddressSanitizer tool with EFL 1.13 and dbus 1.8, but looking to the current master, the issue still happens.
I'm also providing ASan report for the bug:

==1077==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xb08d2420 at pc 0xb448e045 bp 0xbeafce48 sp 0xbeafce4c
WRITE of size 4 at 0xb08d2420 thread T0
    #0 0xb448e043 in _dbus_marshal_read_basic /usr/src/debug/dbus-1.8.16/dbus/dbus-marshal-basic.c:536:0
    #1 0xb44740b5 in _dbus_type_reader_read_basic /usr/src/debug/dbus-1.8.16/dbus/dbus-marshal-recursive.c:878:0
    #2 0xb4479f73 in dbus_message_iter_get_basic /usr/src/debug/dbus-1.8.16/dbus/dbus-message.c:2330:0
    #3 0xb504391b in _message_iter_struct_to_eina_value /usr/src/debug/efl-1.13.26/src/lib/eldbus/eldbus_message_to_eina_value.c:324:0
    #4 0xb50188fd in _property_iter /usr/src/debug/efl-1.13.26/src/lib/eldbus/eldbus_proxy.c:748:0
    #5 0xb5040abd in eldbus_message_iter_dict_iterate /usr/src/debug/efl-1.13.26/src/lib/eldbus/eldbus_message_helper.c:29:0
    #6 0xb501c7b1 in _props_get_all /usr/src/debug/efl-1.13.26/src/lib/eldbus/eldbus_proxy.c:797:0
    #7 0xb50324ad in eldbus_pending_dispatch /usr/src/debug/efl-1.13.26/src/lib/eldbus/eldbus_pending.c:242:0
    #8 0xb4468a3b in complete_pending_call_and_unlock /usr/src/debug/dbus-1.8.16/dbus/dbus-connection.c:2378:0
    #9 0xb446d5eb in dbus_connection_dispatch /usr/src/debug/dbus-1.8.16/dbus/dbus-connection.c:4778:0
    #10 0xb5024e1f in eldbus_idler /usr/src/debug/efl-1.13.26/src/lib/eldbus/eldbus_core.c:774:0
    #11 0xb5d95b19 in _ecore_call_task_cb /usr/src/debug/efl-1.13.26/src/lib/ecore/ecore_private.h:331:0
    #12 0xb5d95b19 in _ecore_idler_all_call /usr/src/debug/efl-1.13.26/src/lib/ecore/ecore_idler.c:147:0
    #13 0xb5d9afb1 in _ecore_main_loop_spin_core /usr/src/debug/efl-1.13.26/src/lib/ecore/ecore_main.c:1767:0
    #14 0xb5d9b107 in _ecore_main_loop_spin_timers /usr/src/debug/efl-1.13.26/src/lib/ecore/ecore_main.c:1801:0
    #15 0xb5d9b107 in _ecore_main_loop_iterate_internal /usr/src/debug/efl-1.13.26/src/lib/ecore/ecore_main.c:1924:0
    #16 0xb5d9b853 in ecore_main_loop_begin /usr/src/debug/efl-1.13.26/src/lib/ecore/ecore_main.c:982:0
    #17 0xb69efe59 in appcore_efl_main ??:? (/usr/lib/libappcore-efl.so.1+0x4e59)
    #18 0xb6f9622b in ?? ??:? (/usr/apps/org.tizen.cbhm/bin/cbhm+0x722b)
    #19 0xb57bc4bb in __libc_start_main ??:? (/lib/libc.so.6+0x164bb)

Address 0xb08d2420 is located in stack of thread T0 at offset 32 in frame
    #0 0xb5042bd3 in _message_iter_struct_to_eina_value /usr/src/debug/efl-1.13.26/src/lib/eldbus/eldbus_message_to_eina_value.c:266:0

  This frame has 5 object(s):
    [32, 33) 'byte' <== Memory access at offset 32 partially overflows this variable
    [96, 98) 'i'
    [160, 164) 'i'
    [224, 232) 'd'
    [288, 295) 'name'
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 (/usr/lib/libdbus-1.so.3+0x3d043)
Shadow bytes around the buggy address:
  0x3611a430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3611a440: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x3611a450: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x3611a460: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x3611a470: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
=>0x3611a480: f1 f1 f1 f1[01]f4 f4 f4 f2 f2 f2 f2 02 f4 f4 f4
  0x3611a490: f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4
  0x3611a4a0: f2 f2 f2 f2 07 f4 f4 f4 f3 f3 f3 f3 00 00 00 00
  0x3611a4b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3611a4c0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x3611a4d0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  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
m.ostapenko updated the task description. (Show Details)
m.ostapenko raised the priority of this task from to Incoming Queue.
m.ostapenko added a project: efl.
m.ostapenko added a subscriber: m.ostapenko.

The obvious fix would be just using integer type for BOOLEAN in eldbus.

Huum nice catch, I will look at it better on monday.
Thanks

@m.ostapenko The application that you ran to got this error is a public one? Could you share it? If not I will write one here.
According to the trace the problem is not on the first eldbus code block but I will fix both cases.

Thanks again

@m.ostapenko The application that you ran to got this error is a public one? Could you share it? If not I will write one here.

I used a Tizen CBHM (Clipboard History Manager, Flora License) application, not sure I'm allowed attach the code here. Bit even if I could, this application is Tizen-specific and it's not easy to establish working environment for CBHM outside Tizen (frankly, I even didn't manage to launch it correctly "by hands"; some other process should establish required environment and run the manager). I'm sorry about that.

Everything looks good but could you also test before push it?
http://pastebin.com/2bPd4njE

Yes, this works fine for me.

Thanks!

zehortigoza closed this task as Resolved.Feb 1 2016, 6:54 AM

Merged thanks.