jorgelo, kerrnel, can you take a look and see if there's anything to be done here? This sounds to me like a feature request so I'm inclined to remove security labels, but let me know if you disagree.

What stops an attacker from just changing the hardware ID of the attack device?

FWIW: PoisonTap was previously filed as  Issue 673105 .

Nothing prevents a determined attacker from spoofing USB hardware ID, however a hardware ID blacklist or whitelist policy is an additional granular layer of security that is appreciated by enterprise IT security teams. It would at least frustrate the unskilled bad actors, e.g. people following instructions they found online. 

Also consider that this is being portrayed (dishonestly in my opinion) by Microsoft marketing as a security weakness of ChromeOS.

FWIW, the only realistic meaningful mitigation that I can see is to disable or prompt for classes of devices (i.e. not specific vendor/device IDs). E.g. give the user (or more realistically, admins on enterprise devices) the ability to say "disallow" or "prompt user" before loading drivers for USB network devices, USB input devices, etc. (the latter only makes sense for devices with built-in input devices obviously).

Agree with the assessment that this is working as intended, so not a security bug but a feature request. Relabeling accordingly.

FWIW, we already do have a policy to block external storage media, which this may fit in with. Over to dskaram@ to prioritize from the Enterprise side.