At the start of 2018, the Bluetooth SIG disclosed vulnerabilities in the way Bluetooth devices (think your phone and some headphones) get paired, whereby an attacker could step into the procedure and gain access to data traffic. Obviously, they wouldn't get anything from a media accessory, but they could get the crypto keys for your phone and then push links and other content to it without hindrance. Happily, whatever you might read about these vulnerabilities in the press, Microsoft Windows, on phones or tablets, 'isn't affected', presumably because the Bluetooth stack in the OS was written better to validate security keys right through the pairing process.

Thus, after, 20 years of Windows being ridiculed for being 'bug-ridden', we're at the stage now where it's one of the least buggy and vulnerable platforms. Phew. I guess this is what comes OF those 20 years of hammering - the code gets 'hardened'!

Anyway, for completeness, from the Bluetooth SIG:

The researchers identified that the Bluetooth specification recommends, but does not require, that a device supporting the Secure Simple Pairing or LE Secure Connections features validate the public key received over the air when pairing with a new device. It is possible that some vendors may have developed Bluetooth products that support those features but do not perform public key validation during the pairing procedure. In such cases, connections between those devices could be vulnerable to a man-in-the-middle attack that would allow for the monitoring or manipulation of traffic. For an attack to be successful, an attacking device would need to be within wireless range of two vulnerable Bluetooth devices that were going through a pairing procedure. The attacking device would need to intercept the public key exchange by blocking each transmission, sending an acknowledgement to the sending device, and then injecting the malicious packet to the receiving device within a narrow time window. If only one device had the vulnerability, the attack would not be successful.

To remedy the vulnerability, the Bluetooth SIG has now updated the Bluetooth specification to require products to validate any public key received as part of public key-based security procedures. In addition, the Bluetooth SIG has added testing for this vulnerability within our Bluetooth Qualification Program.

And there's more detail at CERT:

CWE-325: Missing Required Cryptographic Step - CVE-2018-5383

Bluetooth utilizes a device pairing mechanism based on elliptic-curve Diffie-Hellman (ECDH) key exchange to allow encrypted communication between devices. The ECDH key pair consists of a private and a public key, and the public keys are exchanged to produce a shared pairing key. The devices must also agree on the elliptic curve parameters being used. Previous work on the "Invalid Curve Attack" showed that the ECDH parameters are not always validated before being used in computing the resulted shared key, which reduces attacker effort to obtain the private key of the device under attack if the implementation does not validate all of the parameters before computing the shared key.

In some implementations, the elliptic curve parameters are not all validated by the cryptographic algorithm implementation, which may allow a remote attacker within wireless range to inject an invalid public key to determine the session key with high probability. Such an attacker can then passively intercept and decrypt all device messages, and/or forge and inject malicious messages.

Both Bluetooth low energy (LE) implementations of Secure Connections Pairing in operating system software and BR/EDR implementations of Secure Simple Pairing in device firmware may be affected. Bluetooth device users are encouraged to consult with their device vendor for further information.

An unauthenticated, remote attacker within range may be able to utilize a man-in-the-middle network position to determine the cryptographic keys used by the device. The attacker can then intercept and decrypt and/or forge and inject device messages.

Vendor	Status	Date Notified	Date Updated
Apple	Affected	18 Jan 2018	23 Jul 2018
Broadcom	Affected	18 Jan 2018	19 Jun 2018
Intel	Affected	18 Jan 2018	23 Jul 2018
QUALCOMM Incorporated	Affected	18 Jan 2018	06 Feb 2018
Microsoft	Not Affected	06 Feb 2018	20 Jul 2018
Android Open Source Project	Unknown	18 Jan 2018	18 Jan 2018
Bluetooth SIG	Unknown	06 Feb 2018	06 Feb 2018
Google	Unknown	19 Mar 2018	19 Mar 2018
Linux Kernel	Unknown	05 Mar 2018	05 Mar 2018

Good to know. Because of the physical proximity needed and the rarity of pairing new devices, this vulnerability in Bluetooth is of low impact anyway, but hey, as a Windows (including phone) user don't need to worry about it at all.