GAP ACL L2CAP Data Packets fragmentation over HCI in Android Bluetooth

GAP ACL L2CAP Data Packets fragmentation over HCI in Android Bluetooth

[Marcin Kozlowski]

Hi list,

Hope is ok to ask here. Can somebody give some insight when this can
happen: https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf/hci/src/packet_fragmenter.cc#220

Tried sending fragmented GAP ACL L2CAP packets via HCI, but I cannot
imagine how this condition (in packet_fragmenter.cc#220) can be met:

https://stackoverflow.com/questions/60116790/sending-gap-acl-l2cap-data-packets

Anybody knows? Can shed some more light on this?

Thanks,

Re: GAP ACL L2CAP Data Packets fragmentation over HCI in Android Bluetooth

[Marcin Kozlowski]

Hi Matias,

Thanks for your answer.

Yes, I am testing on rooted device with LineageOS ROM (without patch).
I think LOS devices generally didn't get the patch yet (wasn't patched
in the Repo as as checked it out few days ago), unfortunately ...

I guess many devices will never get the fix, unless you take it in
your own hands with custom Rom etc.

Good BT has to be on, you need to be in the proximity and BT ADDR has
to be known, I can imagine for real attacks you need to know the ROP
chains (function addresses on the device, which will vary from device
to device and builds), maybe chain attacks, use other tricks, also
Samsung Devices have KNOX/RKP etc. Recently read that Android
vulnerabilities are in high demand, higher than Apple phones, since
Android improved a lot in security. I think this will not be too easy
in practical life, but I might be wrong.

Above can be wrong :)

I am looking into this for fun and to learn new things about Android.

For me enough would be to crash the BT process.

Could be there is much to todo, many hops to jump through, asking in
this group to see, if maybe I am missing something obvious.

BT self learner. I am surely missing core knowledge about it (learnt
many thing in past 24 hrs), hence my email to this group. From briefly
looking into this, could not figure out how this:

https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf/hci/src/packet_fragmenter.cc#220

can happen, especially based on my simple tests? As I wrote in my
previous email.

Any insights, guidance will be greatly appreciated.


Thanks,

On Wed, Feb 12, 2020 at 12:20 PM Matias Karhumaa
<matias.karhumaa@gmail.com> wrote:
>
> Hi Marcin,
>
> Most obvious question first: are you testing against device that does not have the fix for this vulnerability yet?
>
> There are still huge amount of devices out there without access to the fix. This is why full technical report has not been published yet.
>
> Best regards,
> Matias Karhumaa
>
> ke 12. helmik. 2020 klo 12.38 Marcin Kozlowski <marcinguy@gmail.com> kirjoitti:
>>
>> Hi list,
>>
>> Hope is ok to ask here. Can somebody give some insight when this can
>> happen: https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf/hci/src/packet_fragmenter.cc#220
>>
>> Tried sending fragmented GAP ACL L2CAP packets via HCI, but I cannot
>> imagine how this condition (in packet_fragmenter.cc#220) can be met:
>>
>> https://stackoverflow.com/questions/60116790/sending-gap-acl-l2cap-data-packets
>>
>> Anybody knows? Can shed some more light on this?
>>
>> Thanks,

Re: GAP ACL L2CAP Data Packets fragmentation over HCI in Android Bluetooth

[Marcin Kozlowski]

OK, I think I got it the condition

Below is Mobile (Android) Bluetooth subsystem log:


02-12 22:33:26.928  2416  2461 W bt_hci_packet_fragmenter:
reassemble_and_dispatch reassemble_and_dispatch
02-12 22:33:26.928  2416  2461 W bt_hci_packet_fragmenter:
reassemble_and_dispatch partial_packet->offset 21 packet->len 683
HCI_ACL_PREAMBLE_SIZE 4
02-12 22:33:26.928  2416  2461 W bt_hci_packet_fragmenter:
reassemble_and_dispatch projected_offset 700 partial_packet->len 209
02-12 22:33:26.928  2416  2461 W bt_hci_packet_fragmenter:
reassemble_and_dispatch got packet which would exceed expected length
of 209. Truncating.
02-12 22:33:26.928  2416  2461 W bt_hci_packet_fragmenter:
reassemble_and_dispatch memcpy packet->len 188 packet->offset 4 expr
184
02-12 22:33:26.929  2416  2460 W bt_hci_packet_fragmenter:
fragment_and_dispatch fragment_and_dispatch

Still working on crashing the process, maybe this is due to memory
allocator (possibly jemalloc)

Thanks,
Marcin


On Wed, Feb 12, 2020 at 12:20 PM Matias Karhumaa
<matias.karhumaa@gmail.com> wrote:
>
> Hi Marcin,
>
> Most obvious question first: are you testing against device that does not have the fix for this vulnerability yet?
>
> There are still huge amount of devices out there without access to the fix. This is why full technical report has not been published yet.
>
> Best regards,
> Matias Karhumaa
>
> ke 12. helmik. 2020 klo 12.38 Marcin Kozlowski <marcinguy@gmail.com> kirjoitti:
>>
>> Hi list,
>>
>> Hope is ok to ask here. Can somebody give some insight when this can
>> happen: https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf/hci/src/packet_fragmenter.cc#220
>>
>> Tried sending fragmented GAP ACL L2CAP packets via HCI, but I cannot
>> imagine how this condition (in packet_fragmenter.cc#220) can be met:
>>
>> https://stackoverflow.com/questions/60116790/sending-gap-acl-l2cap-data-packets
>>
>> Anybody knows? Can shed some more light on this?
>>
>> Thanks,