This is completely wrong. Android devices will not offer the filesystem, unless you choose to do that on the phone. By default the only communication with the host is for device identification and for charging current negotiation, so the only way to do anything would be if you found a bug in those.
This is not true for the majority of the recent smartphones. First, being able to load an arbitrary image over the USB connection requires unlocking of the bootloader, which only a very small fraction of the people do. And even with an unlocked bootloader, you have the reboot the phone into a special mode before it will accept anything to be flashed, so just plugging it into a malicious usb host, while the phone is running the OS will not allow that.
The attacker does not have physical access, unless you count a cable going from device A to device B as "physical access". And if that's the case then on any wired network everybody has "physical access" to anybody else on the network. Does my ISP have "physical access" to my modem because there is a cable from their equipment to the modem?
It's entirely possible that a similar attack could happen to Android devices as well (for example, run an ADB instance and have it auto-install and execute something whenever it detects a device with debugging enabled. My phone would be vulnerable to this kind of attack, because for convenience, I've got it set up to auto-enter debugging mode whenever it plugs into a device. I'm willing to accept that risk, but I'm not an idiot that insists that the risk isn't there.)
That's why ADB is only meant to be enabled when doing development and there are clear warnings when you enable it, telling you that the mode is dangerous. If you leave it enabled when connecting to untrusted devices, then the fault is entirely with you. And most people don't ever use ADB, so this would be irrelevant for them.
Slashdot Mirror
This is completely wrong. Android devices will not offer the filesystem, unless you choose to do that on the phone. By default the only communication with the host is for device identification and for charging current negotiation, so the only way to do anything would be if you found a bug in those.
This is not true for the majority of the recent smartphones. First, being able to load an arbitrary image over the USB connection requires unlocking of the bootloader, which only a very small fraction of the people do. And even with an unlocked bootloader, you have the reboot the phone into a special mode before it will accept anything to be flashed, so just plugging it into a malicious usb host, while the phone is running the OS will not allow that.
The attacker does not have physical access, unless you count a cable going from device A to device B as "physical access". And if that's the case then on any wired network everybody has "physical access" to anybody else on the network. Does my ISP have "physical access" to my modem because there is a cable from their equipment to the modem?
It's entirely possible that a similar attack could happen to Android devices as well (for example, run an ADB instance and have it auto-install and execute something whenever it detects a device with debugging enabled. My phone would be vulnerable to this kind of attack, because for convenience, I've got it set up to auto-enter debugging mode whenever it plugs into a device. I'm willing to accept that risk, but I'm not an idiot that insists that the risk isn't there.)
That's why ADB is only meant to be enabled when doing development and there are clear warnings when you enable it, telling you that the mode is dangerous. If you leave it enabled when connecting to untrusted devices, then the fault is entirely with you. And most people don't ever use ADB, so this would be irrelevant for them.