Comment by Animats | Hacker News Reader

Comment by Animats | Hacker News Reader

Parent Full thread

I posted this 71 days ago on HN.[1] I wrote this after reading the USB-C spec:

There's a mode called "Debug Accessory Mode". This is totally different than normal operation and requires a special cable as a security measure. (In a regular cable, pins A5 and B5 are connected together and there's only one wire in the cable for them. Debug Test devices use a cable where pins A5 and B5 have their own wires and there's a voltage difference between them.) Debug Accessory Mode, once entered, is vendor-specific. It may include JTAG low-level hardware access. Look for exploits based on this. If you find an public charger with an attached USB-C cable, worry. Always use your own cable.

The "security" feature is that you need a nonstandard USB-C cable with an extra wire, and it needs to attach to something that sends JTAG signals.

The Google Pixel supports Debug Accessory Mode.[2]

[1] https://news.ycombinator.com/item?id=12824366 [2] https://plus.google.com/+BensonLeung/posts/XGLDnsF57PB

On the Pixel C debug accessory mode is gated by the hardware write protect "screw" (front camera flex cable). Enabling it requires opening up the device to the point you could attach probes and rewrite SPI flash anyway.

No JTAG on the Pixel C either, just UARTs and SPI: https://chromium.googlesource.com/chromiumos/platform/ec/+/m...

I have an issue with that still, as it means that by gaining full control of your device you are exposing yourself to a higher risk. I don't want laptops to turn into a situation like android where apps refuse to launch if you want to have full control of your device.

Alternatively all USB-C thumbdrives become a threat once they hit the market.

Given your commend it USB-C specific, and the linked article mentioned USB-3 (which has a USB-2 connector variant) what is the mechanism on those ports for detecting a debugger?

> Alternatively all USB-C thumbdrives become a threat once they hit the market.

All USB thumbdrives are already a threat. Not just from autoplay/execute, but there are malicious/pentester thumbdrives out there (like the Rubber Ducky) that emulate a USB HID keyboard; computers have absolute trust in keyboards, so you just have a script that instantly types in "Win-R cmd enter <download and run your exploit>".

I don't think these threats are equivalent. You can detect a rubber ducky doing it's thing if you look at the screen, and the rubber ducky requires your pc to be unlocked, so you can easily defend against a rubber ducky by not leaving the PC unlocked.

With direct hardware access/DMA you can just plug a small device into, let's say a locked office cubicle computer and compromize/siphon data off it that way.

Considering the speed with which that attack can happen and that the macros can background the entire processing immediately (opens cmd, creates bat, executes bat, minimizes cmd), you only have to turn your back for a few seconds and an attacker can get into your system.

Imagine, you are sitting at your desk in the county clerk office and a citizen comes to see you about something. You turn your chair around for a few seconds to get a file and they insert the drive into the back of your computer and remove it before you turn back around. Do you honestly think that anyone beyond a security export or a spook would think they could be compromised that fast?

There are also those fun thumb drives that will repeatedly bolt a couple Kilovolt into the USB port for shits and giggles.

Plugging in USB is just as unsafe as about anything else you can use a computer for.

How we ended up with an active device as our primary means of removable storage is me a puzzle...

We chose flash memory. It's a storage medium that involves a lot of tiny wires laid out in patterns going to the storage cell. We want to access these with only a few macroscopic wires connecting to a computer. This process has to be managed by a microprocessor of some sort.

Would you expect the host device to know the internal layout properties and hardware limitations of a purely passive bank of flash memory (e.g. when to mark a sector as failed)? It's possible but distributing the hardware and software to do this effectively would be a very difficult problem, and industry standardisation to mitigate it would be hard to arrive at as well, and deploying advances in flash memory would be hampered (remember when people worried about 720kb/1.44mb floppies? Imagine that for each new generation of flash memory. Is your flash drive slot MLC NAND flash capable? NOR flash? TLC? HKMG?)

Instead we live in a world where not just thumb drives, but even memory sticks and SD cards, are active devices. (This is, of course, to say nothing of the convenience of using one port for everything.)

SmartMedia and xD flash cards are notionally controller-less in the sense that the electrical interface is just parallel interface of NAND flash chip and all the FTL stuff is done by whatever device it's plugged into. one problem with that is that it requires all the devices to use same FTL logic with the standard one being NDA'd.

There ought to be some way to make a secure data transfer interface.

I guess not making it an universal bus is one of the steps for that. Also, making it either optical or magnetic should help.

facepalm

Two Words.

Legacy Hardware.

Looking at the video, Intel put in their own support for this on their standard USB-3 ports.[1] It's not USB-C hardware JTAG. It can be disabled in the BIOS settings, supposedly, and locked against further changes.[2] Apparently it ships enabled.

[1] https://youtu.be/QuuTLkZFsug?list=PLOcrXzpA0W82Z49Pj0v-cehuv... [2] https://youtu.be/QuuTLkZFsug?list=PLOcrXzpA0W82Z49Pj0v-cehuv...

Wow, time to find the special USB port and fill it with Epoxy on your system.

or put a solder bridge across the two pins.

I assume "USB Debug" option in my BIOS refers to this feature, however it did seem to be shipped "Disabled" for me.

I just looked into this on my Dell M3800 with A10 BIOS. This option derates your USB 3 ports to USB 2, so that older versions of Windows that don't support USB 3 out-of-box can still boot on the hardware. I assume once you get through the install from your USB stick, you would install drivers and disable this debug mode

Ok, a special cable as a security measure is just sad. Didn't they learn anything from the Firewire DMA issues? Intel could at least have made it so that you have to enable the "Debug Accessory Mode" via BIOS (or whatever is booting your PC these days).

Edit: whoops just saw your reply that it can indeed be disabled, and that its enabled by default

Regarding your edit, that seems even worse. They recognized the potential for trouble, put in the effort to make it configurable, and then left it on by default?

The idea may have been that it's for corporate customers who buy in bulk, who may either want the maintenance capability, or will disable it entirely during their commissioning process.

So there will be an emerging market for intermediate plugs with A5 connected to B5, passing through the other pins?

Which would be useful as long as you're not crossing a border or leaving your computer unattended.

Even if there's a hardware switch, it still enables two strike attacks :-/

> Always use your own cable.

couldn't you just create a passthrough female/male sleeve that simply internally solders A5 and B5 and use that any time you have to plug in anything untrusted?

There's a USB condom that blocks data lines for safer charging, though it's USB 2: http://int3.cc/products/usbcondoms

These work too, and have a better case than a bare PCB:

https://www.amazon.com/PortaPow-Charge-Block-Adaptor-SmartCh...

Am I right in thinking from watching the CCC talk though, that you can simply use another computer to do the debugging, as they show a debugging cable which crosses over wires.

Reply on news.ycombinator.com