Debugging mechanism in Intel CPUs allows seizing control via USB port
scmagazine.com
scmagazine.com
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
No JTAG on the Pixel C either, just UARTs and SPI: https://chromium.googlesource.com/chromiumos/platform/ec/+/m...
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?
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>".
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.
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?
Plugging in USB is just as unsafe as about anything else you can use a computer for.
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.)
I guess not making it an universal bus is one of the steps for that. Also, making it either optical or magnetic should help.
Legacy Hardware.
[1] https://youtu.be/QuuTLkZFsug?list=PLOcrXzpA0W82Z49Pj0v-cehuv... [2] https://youtu.be/QuuTLkZFsug?list=PLOcrXzpA0W82Z49Pj0v-cehuv...
Edit: whoops just saw your reply that it can indeed be disabled, and that its enabled by default
Even if there's a hardware switch, it still enables two strike attacks :-/
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?
https://www.amazon.com/PortaPow-Charge-Block-Adaptor-SmartCh...
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 )
We cannot simply continue to allow it to be "game over."
If you're not interesting then physical security is less necessary because physical attacks are less likely and the consequences are lower. If you are interesting then you need physical security.
Unlock with PIN or with fingerprint? Obviously PIN is safer because we leave fingerprints everywhere. But threat modeling comes into play.
I know of a guy who got his iPhone stolen at a party and started receiving email notifications of account changes. Did the thief use NSA grade decryption techniques? No, the phone was protected with a PIN. The thief likely kept an eye on people unlocking phones and stole the one he was able to spot the PIN for. The inferior security method (fingerprint) would have prevented unlocking the phone and maybe made the theft less interesting.
It's always a tradeoff and one has to decide who's wanting to protect against.
Okay, so imagine you're in a country where homosexuality is illegal, but you still are trying to live your life as a human (the majority of which seek companionship).
"Oh sorry, not only are you ruined when they kick down your door, but everyone you've ever networked with is at risk now too maybe try not living there ha ha goodbye!" is not a story.
What's more, I just want to point out Apple and Google have been trying very hard to make devices which all but the most resourced individuals cannot break. As you implied, some access weaknesses exist to this day, but right now for desktops and laptops this "welp I guess you deserved this because you weren't careful" attitude seems to rule the discourse.
It's shortsighted, it's regressive, it's unhelpful. And while I cannot know your motivations, I know many folks who are so paranoid that Intel and AMD might have backdoors in their boot integrity verifiers that they're willing to ignore people desperate to keep secrets on that principle rather than try and make an actual best effort at security.
I lock the door of my house. Most people do. That helps against burglars, which is my threat model. It doesn't help against police with a warrant in some countries, maybe warrantless in others. If somebody wants your data so badly to kick down your door, maybe they are willing to use workarounds even less pleasant than https://xkcd.com/538/ There are techniques against that, compartmentation (is that the right word?) and others. The more farsighted is trying to change how a country works. Long and risky though.
Also, a plumber would probably invest in mechanic arms to prevent possible injury when working before it comes to preventing physical access to his/her computer.
In short, it's a question of effort and priorities.
A default setting change protects me from black hats walking around with special cables in Starbucks? Yeah, sure, why not. Me having to carry my ultrabook in a locked steel case? Not so much.
The saying is, saying you don't care about privacy because you have nothing to hide is like saying you don't care about free speech because you have nothing to say. The analogy works because they're actually analogous -- it's a private right vs. a government imposition in both cases.
This isn't that.
Doing things this way has costs. It once was that if you forgot your personal device password then you take it to a computer tech who uses "physical access=root" to reset your password or recover your files.
If you make that not practical anymore, how do we solve password recovery? "You lose all your data" is not something people want to hear. The current solution seems to be to backup everything into The Cloud. But I thought the idea was to improve security?
Meanwhile you can't actually know if a state-level attacker is able to penetrate the likes of Secure Boot until it's too late, and the chances are that they actually can. Which means interesting people still need physical security.
From the corporations' point of view, there are multiple customers to satisfy for each device shipped, not just the end user. My point being that this risk analysis is simply more complex than any single end user's needs.
Counterexample: For Unclassified and Unclassified//FOUO websites made available on the public internet by DoD/IC, you can even access them from home using a valid CAC/PKI card (smart card holding a client certificate affirming your identity). This is not just informational websites, it includes your unclassified webmail, Intelink-U (web gateway to some sites), and more. They are far more lax than many private corporations are.
Physical security is surely good to have, but your reference to military is not a great one as military and the intelligence community hedge a lot on digital security, not physical security unless the information is highly sensitive (Even then, it is in combination with very strong digital security measures regarding setup of the network, VPN, and all endpoints).
It should not be possible to break into a device simply by having it in your possession for a few minutes. Opening it up? Harder to protect against and therefore a lower priority. But some devices are glued shut and therefore more secure. (This security can be used against the user as well as by the user, but that's a whole other can of worms)
EDIT: Adding this: ( http://www.artima.com/weblogs/viewpost.jsp?thread=23476 )
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
"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.
Uh huh, because you've read the source code for your program, including all the bit someone else wrote, plus the database code, and the code for your desktop manager, and the OS code for good measure. And since it's all "open" (like say, DNA), it's clear how it runs.
As a counter claim: In my experience, programmers that don't use debuggers, are those that have difficulties understanding things. They just throw code at it until something sticks.
To understand what's wrong with my program, I need a strong understanding of the data it manipulates. Show me the data, and I can probably track down the bug. The sequence of operations shown by step-by-step debugging is important, but never helped me as much. I have invariants in mind, and I can detect invariant violations by looking at the data, not at the operations between them.
In practice it means I use Valgrind first to weed out most undefined behaviours, then printf(). Yep, printf().
Take my VM for example. Had many bugs, many of them hard to track: off-by-one errors were not detectable by Valgrind for instance, because my VM heap was a giant std::vector<Word>. The GC was wrong, the stack management was wrong, the primitives were wrong… I made errors pretty much everywhere. What saved me was a little printf() based visualization tool. I could now see every block in my heap, and if anything went wrong there, I would detect it very quickly. This became my new Valgrind.
I have no idea how gdb would have helped me there. Didn't need it anyway.
Either is fine. Most conversations about debuggers however tend to equate the debugger with something like gdb or the IDE debugging interface. People will often say the absence of such a debugger is a deal breaker for them. It feels like they forgot about printf.
When I know that memory corruption is occurring (I work in embedded C++), a debugger with watchpoints is about the only way to track down who has that stray pointer.
Sure, a debugger isn't an excuse for not thinking about what you're doing, but banning them outright is a ridiculous idea.
Of course, it requires you have deterministic logging. If you don't have that, it should be your #1 priority.
Shouldn't a debugger mitigate the necessity of overly paranoid design and testing? Testing hardware is much more expensive than testing software - to do so properly, you first have to build the damn thing. Hardware 'revisions' (builds) are more commonly measured in single digits, not the 6+ digit monsters of your local CI setup.
Another answer: In the exact same sense that bug databases, assertions, unit tests, static analysis, 'safe' programming languages, code reviews, etc. are all mitigations and crutches for the human condition.
A third answer: Crutches are useful medical devices.
A fourth answer: I routinely interact with software and hardware that hasn't undergone proper design and testing. This is a bit of a mouthful, so I generally shorten this to "software" and "hardware", respectively. Why yes, I do debug and workaround 3rd party issues - for which no amount of "proper design" or "testing" of my own stuff will help - regularly enough to need a debugger.
> EDIT: Adding this: ( http://www.artima.com/weblogs/viewpost.jsp?thread=23476 )
To quote from that:
> Once you have exhausted every other avenue of diagnosis, and have given very careful thought to just rewriting the offending code, then you may need a debugger.
Yes, even that admits you'll sometimes need a debugger. Not "want" - need. Even for software.
EDIT: Various typos.
Probably not wise to ship one enabled on production gear, I used to work on things that required some soldering to get access.
See https://events.ccc.de/2015/01/03/the-youtube-and-stream-dump... for a detailed explanation of the problem.
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.
Remember direct DMA attacks on FireWire, etc.?
SMH.
(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.)
I imagine DMA was a trade-off for speed. Security is about such trade-offs.
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.
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.
> “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)
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).
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.
2) sounds like a race condition.
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.
Typically the "sane hardware state" means enough to execute firmware instructions from somewhere and have some scratchpad RAM. Interesting approaches to this include modern x86 system which boot into state that could not be reasonably described as "sane" (no RAM, MMU preloaded with configuration that should not be normally possible...) and various RISC implementations that boot by loading initial contents of various registers and on-die caches from external serial PROM (which is essentially same way as how FPGA's are configured).
To be fair, these are generally fairly well documented for most CPU cores. For the ones that aren't documented, sniffing a proprietary debugger isn't difficult.
The other way is supposedly protected by manual installation and signing keys.
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.
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.