
Debugging mechanism in Intel CPUs allows seizing control via USB port - ivank
https://www.scmagazine.com/debugging-mechanism-in-intel-cpus-allows-seizing-control-via-usb-port/article/630480/?
======
Animats
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](https://news.ycombinator.com/item?id=12824366)
[2]
[https://plus.google.com/+BensonLeung/posts/XGLDnsF57PB](https://plus.google.com/+BensonLeung/posts/XGLDnsF57PB)

~~~
ChuckMcM
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?

~~~
semi-extrinsic
> 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>".

~~~
ATsch
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.

~~~
lsaferite
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?

------
userbinator
As much as people have tried to make it otherwise, I've long been a believer
in the "physical access = game over" line of thinking. Not letting anything
untrusted into USB ports is one of the effective defenses against this.

 _In their concluding remarks, the researchers proposed a number of protective
measures based on use of Intel 's BootGuard feature and forbidding activation
of the debugging interface._

Let's not scare ourselves too much, lest we end up in Stallman's debuggers-
are-controlled-munitions dystopia. ( [https://www.gnu.org/philosophy/right-to-
read.en.html](https://www.gnu.org/philosophy/right-to-read.en.html) )

~~~
RandomInteger4
How vital are debuggers really though? Shouldn't proper design and testing
mitigate the necessity of using a debugger? They're more akin to a crutch are
they not?

EDIT: Adding this: (
[http://www.artima.com/weblogs/viewpost.jsp?thread=23476](http://www.artima.com/weblogs/viewpost.jsp?thread=23476)
)

~~~
paulddraper
In the same way an MRI is a crutch for doctors who don't know the human body
well enough.

~~~
emsy
That's a terrible comparison. The body already lies open before you in the
form of code. A debugger should be the measure of last resort, when you can't
explain why something fails or you have strange side effects. In my experience
every programmer that relied on the debugger had difficulties understanding
his or her code in the first place.

~~~
BoorishBears
I don't know how your code can tell you the silicon is wrong (for example).
Are you're suggesting the first step of debugging a problem is to understand
your code, then every bit of code running under it, the all the code under
that _ad infinitum_ , then hardware designs under all that... and not using an
available debugger?

I can't help but feel this is an opinion only someone who has only ever worked
on _extremely_ high level (and basic) systems _and_ has simultaneously
disregarded all underlying abstractions could hold, _or_ someone who has only
worked with very low level systems which were so shallow my aforementioned
facetious approach to debugging is actually feasible. Limiting yourself to
either extreme doesn't exactly give one the most balanced view of how problems
can be solved in software

~~~
emsy
I don't think you understood what I've said. Debugging is perfectly fine when
you can't explain what's going on even though you understand the code. "The
silicon is wrong" so rarely, that it makes for nice, memorable trench stories.
Either that or you work at a really low level, which is something that is not
the default.

~~~
BoorishBears
In addition to what the other comment says:

"you can't explain what's going on even though _you understand the code_ "

If someone's working on code what's wrong with using the debugger to
understand the code better? There's all sorts of behavior defined underneath
code that people write that can be much simpler to understand through analysis
of the system in action than through code, especially when you don't have
access to what's going on underneath your code due to abstractions.

There are a lot of 1+1=3 type situations that arise from abstractions people
don't have access to the source to, or the resources to analyze at a given
moment.

~~~
emsy
It's perfectly fine to use the debugger in such situations. Please see my
other response on this topic:

[https://news.ycombinator.com/item?id=13367946](https://news.ycombinator.com/item?id=13367946)

------
xja
Here's the original CCC talk:

[https://media.ccc.de/v/33c3-8069-tapping_into_the_core](https://media.ccc.de/v/33c3-8069-tapping_into_the_core)

~~~
lorenzhs
The YouTube link in the article is to an uploader _pretending to be_ the CCC.
Some of these uploaders even participate in the YouTube advertisement
programme, profiting off other people's work, when there is an official ad-
free YouTube account as well (media.ccc.de,
[https://www.youtube.com/watch?v=2JCUrG7ERIE](https://www.youtube.com/watch?v=2JCUrG7ERIE))

See [https://events.ccc.de/2015/01/03/the-youtube-and-stream-
dump...](https://events.ccc.de/2015/01/03/the-youtube-and-stream-dump-
problem/) for a detailed explanation of the problem.

------
PinguTS
Funfact: about a year ago some semiconductor manufacturers wanted to
standardize something similar: put JTAG on CAN bus.

They explained it that way, that it would be a great benefit to debug ECUs via
the on-board diagnostics port (ODBII) and may be later even over the internet.

They tried it behind the automotive scene. But we managed to get many major
OEMs on board to prevent that standardization effort. This would have been the
greatest easter egg for all cars, it that would have been happened.

------
payne92
I am continually perplexed at how hardware designers end up with these kinds
of "features" on external ports.

Remember direct DMA attacks on FireWire, etc.?

SMH.

~~~
Animats
I tried to get that disabled in Linux. There's a register in the FireWire
interface which sets the range of addresses into which external memory access
requests can be made. By default, it was at 4GB, even on 64 bit systems.
Setting it to zero would break some external kernel debugger, though, so it
was left open.

(Firewire isn't DMA. PCI-E is DMA. Firewire is a network cable, over which
software sends packets. LAN over FireWire was sometimes done. But there's an
optional feature which recognizes special packets for doing word-size loads
and stores. This is usually used to talk to dumb slave devices, where you
write "registers" to make things happen. It's not needed on a computer, and
it's far too slow for bulk transfers. FireWire isn't inherently more
vulnerable than a LAN port.)

~~~
kalleboo
IIRC Apple's "fix" was to just disable recognition of new FireWire devices
when the computer was locked. So a nasty device could still compromise you,
but it would be one that you plugged in yourself.

~~~
mikeash
It looks like your recollection is indeed correct. See the entry for
CVE-2011-3215 here: [https://support.apple.com/en-
us/HT202348](https://support.apple.com/en-us/HT202348)

------
NKCSS
Why haven't they just created a small jumper on the Mobo to enable it when
needed? That would solve the PC issues.

On the other hand; there is a reason for the age-old adagium that once an
attacker has physical access; it's always game-over.

~~~
AstralStorm
Physical access is reasonably easy to detect though in many ways.

USB is supposed to be an interface that is exposed to the world. Using USB is
not quite the same as getting into the box and switching a microswitch.

------
campuscodi
So a security researcher using Intel-approved debugging tools has found he can
take over CPUs... isn't that the purpose of debugging modes?

~~~
throwaway7767
Yes, the story here is that new Intel platforms expose such debugging
functionality over regular USB ports. This is not what most people expect, so
it's newsworthy.

------
fn42
It sounds like this is more or less equal to android's "ADB"?

> “There are several ways someone could do this. An attacker could change the
> BIOS configuration (for example, with a use of a Flash programmator) when
> they have physical access to the equipment during manufacturing, storage or
> usage.

It has to be specifically enabled (with physical access)

~~~
debatem1
No, at least not on stock Android devices. ADB is pretty constrained (SELinux
policy, the DAC, etc). It shouldn't be possible to go from there to something
like root+unconfined on a normal user device, though of course with additional
exploits anything is possible.

If the comments above are correct this is either more like JTAG or _is_ JTAG.
That's commonly far more capable, usually providing the ability to do things
like read and write arbitrary memory without any kernel hinderance at all
(although ARM cpus can typically still protect trustzone memory).

~~~
revelation
JTAG is a protocol for testing electrical connectivity and package pins, all
the debug capability is proprietary vendor extensions. Which is to say that
for any retail product, the CPU will have had a fuse set to make it
"protected" which typically includes disabling debug JTAG functionality.

~~~
debatem1
It isn't always the case that there's a 'protected' fuse.

Manufacturers seem to have settled on a few different approaches to JTAG:

1/ Leave it open, hope nobody notices.

2/ Leave it to ARM, since modern ARM CPUs have the ability to disable normal
and secure world invasive and noninvasive debugging.

3/ Require you to scan in a secret to unlock most debugging functionality.

4/ Fuse off JTAG on production devices.

I can only speak to my experience, but my guess is that for consumer
electronics this is roughly in order of popularity with the top option being
maybe half of devices and the bottom maybe 10%.

And each of these has problems, so it's no wonder people haven't figured out
just one.

Leaving it open is terrible from a security perspective, but for some classes
of devices it's also a legal and IP headache. So this is mostly the "couldn't
be bothered" set.

Leaving it to ARM is fine as long as your trusted world is sane and the only
interesting thing on the chain is your CPU. For many devices this isn't the
case. And sometimes bootloaders etc can be made to be insane.

Scanning in secrets is just a bad idea. Provisioning per device secrets is
hard, so the "secret" often isn't. Usually it's either something simple
(1111... etc) or a serial number, or a serial number ^ a constant, or just the
constant. Even where this isn't the case, the secret checking logic is often
glitchable or has a viable timing attack. So these frequently fall into the
"annoying but possible" bucket for me.

Fusing off JTAG is a mixed bag. It's a huge PITA for manufacturing and RMA so
I understand why people don't do it. And you really have to have kind of a lot
of logic running on most devices today to get fuses working, so it isn't
always as effective as it looks in the presence of glitching attacks. But it
is still by far the best option for security and it can be gotten right.

There are also usually various levels of 'disabled', with some parts letting
you run eg mbists even in a secured configuration. Obviously, more special
cases means more ways to go wrong.

Of course some segments of the market are better about these things than
others, so YMMV on the frequency of various approaches.

~~~
revelation
That's interesting, I figured they would just disable/fuse it at the same time
that the software is flashed, and updates need to use a bootloader anyway.
What's the legal and IP issues?

2) sounds like a race condition.

~~~
debatem1
On legal and IP issues--

Some industries are under various requirements not to be user-modifiable. Some
of those requirements are uncommonly applied or are uncertain (wifi routers),
but some have serious teeth (export controlled munitions). For devices in
those classes they often can't be open without risking liability.

On the IP side, some people really care about keeping firmware proprietary.
Leaving JTAG in a mode that is meaningful for debugging that firmware will
pretty much completely destroy that. So if you super duper care, you sometimes
put clauses in your contracts holding the integrator or OEM responsible if
your firmware leaks.

Regarding a race condition, yeah. It's pretty common for devices to come up
open, then harden up-- and not just for JTAG. It's also not unique to the
register-setting approach.

------
wyager
I've said this many times before, and I'll say it many times more, but USB
needs to go back to living by its name and being a Universal Serial Bus. That
doesn't mean being a video bus, or a DMA bus, or a JTAG bus. It means being a
serial bus. You can wrap whatever video or JTAG data you want in a serial
connection without it being baked into the standard.

~~~
tbrownaw
The wonderful thing about standards is that they're, well, _standard_.

USB Video Class devices can all use the same driver, instead of every new
webcam needing it's own special software to work. USB HID devices all use the
same driver, so I don't have to know I'd my specific keyboard and mouse are
supported.

~~~
wyager
> The wonderful thing about standards is that they're, well, standard.

Nothing wrong with standards. What's wrong is trying to shove everything and
the dog into a single standard instead of appropriately separating concerns.

Now we have multiple mutually incompatible USB-C connector based video
protocols. This is the result of trying to overspecify the USB standard.

------
gm-conspiracy
Can this be enabled in the BIOS via vPro?

------
mdekkers
"debugging" mechanism....

------
richardlblair
Could there be anymore ads on that page?

