diff --git a/device/bluetooth/bluetooth_service_record_win_unittest.cc b/device/bluetooth/bluetooth_service_record_win_unittest.cc index 0000000..0000000 100644 --- a/device/bluetooth/bluetooth_service_record_win_unittest.cc +++ b/device/bluetooth/bluetooth_service_record_win_unittest.cc @@ -24,6 +24,24 @@ const char kTestRfcommSdpBytes[] = const device::BluetoothUUID kTestRfcommSdpUuid("1112"); const int kTestRfcommChannel = 11; +// Malicious record: attributes 0x0001 and 0x0004 are encoded as UINT128 +// (header byte 0x0C) instead of the spec-mandated SEQUENCE. +// BluetoothSdpGetAttributeValue() returns type=SDP_TYPE_UINT and stores the +// 16 attacker bytes in data.uint128, which on x64 overlays +// data.sequence.value (LPBYTE @ offset 0) and data.sequence.length +// (ULONG @ offset 8). ExtractChannels()/ExtractUuid() then call +// BluetoothSdpGetContainerElementData(value, length, ...) without checking +// .type, dereferencing the attacker-controlled pointer. +// +// The 16 payload bytes encode VA 0x4141414141414141 (non-canonical -> #GP) +// and length 0x1000. Generated by gen_malicious_sdp.py. +const char kTypeConfusedSdpBytes[] = + "3538" + "0900000a00010001" + "0900010c00000000000010004141414141414141" + "0900040c00000000000010004141414141414141" + "0901002503504f43"; + } // namespace namespace device { @@ -64,4 +82,24 @@ TEST_F(BluetoothServiceRecordWinTest, BthAddr) { EXPECT_EQ(1108152553632ull, service_record.device_bth_addr()); } +// POC: demonstrates the SDP_ELEMENT_DATA union type-confusion. With the +// vulnerable code this test triggers an access violation inside +// bthprops.cpl!BluetoothSdpGetContainerElementData reading address +// 0x4141414141414141 (ASAN: "unknown-crash on unknown address +// 0x4141414141414141"). With the bandaid fix applied the constructor +// rejects the non-SEQUENCE attribute and the test passes. +TEST_F(BluetoothServiceRecordWinTest, TypeConfusedProtocolDescriptorList) { + std::vector sdp_bytes_array; + ConvertSdpBytes(kTypeConfusedSdpBytes, &sdp_bytes_array); + // The SDP blob is exactly what a malicious paired BT Classic peer can + // place in the Windows SDP cache; BluetoothTaskManagerWin copies the raw + // blob byte-for-byte from WSALookupServiceNext (see + // bluetooth_task_manager_win.cc DiscoverClassicDeviceServicesWorker). + BluetoothServiceRecordWin service_record( + "01:02:03:0A:10:A0", "TypeConfused", sdp_bytes_array, BluetoothUUID()); + // Reaching here means the type guard rejected the malformed attribute. + EXPECT_FALSE(service_record.SupportsRfcomm()); + EXPECT_FALSE(service_record.uuid().IsValid()); +} + } // namespace device