11 ms·
Debugging mechanism in Intel CPUs allows seizing control via USB port
- xja 10y agoHere'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 10y agoThe 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-problem/ https://events.ccc.de/2015/01/03/the-youtube-and-stream-dump... for a detailed explanation of the problem.
- richardlblair 10y agoCould there be anymore ads on that page?
- payne92 10y agoI 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.
- yuhong 10y agoThe fun thing is that it is probably a very useful feature for those who know how to use it. You can debug your BIOS this way for example.
- viraptor 10y agoSure, but you should disable it before shipping the final version. It's the same with programming microcontrollers - you have full read write and debug available. But you should really flip the right fuses to disallow changes in the shipped product.
- andreyf 10y agoI'd be curious to see a list of devices which ship with this enabled. I imagine it's shorter than the article makes it sound. I imagine DMA was a trade-off for speed. Security is about such trade-offs.
- psybin 10y agoIt's a common feature for very high speed writes in hardware, DMA in firewire and thunderbolt is no mistake.
- Animats 10y agoI 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.)
- psybin 10y agoFirewire in most setups allows DMA access to the host, but only to the first 32 bits of RAM. There's tools for unlocking, reading out keys from memory while asleep, all sorts of nasties.
- Animats 10y agoIn Linux, that's a constant in the Linux driver.
- kalleboo 10y agoIIRC 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 10y agoIt 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
- deleted 10y ago[deleted]
- userbinator 10y agoAs 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 )
- KirinDave 10y agoSure, but let's not kid ourselves. For some people (of both good and bad intentions), they have to be able to resist both covert and overt physical access. We cannot simply continue to allow it to be "game over."
- ktRolster 10y agoWhen the military has secure computer needs, they take steps to ensure no physical access. Check out "SCIF"
- greglindahl 10y ago... and they also put hot glue into the usb ports, but I digress.
- wmf 10y agoSo for those of us not in the military, we should either handcuff our laptops to ourselves or just not use computers? It's so defeatist.
- AnthonyMouse 10y agoSecurity is risk management. A plumber has a different threat model than a government operative. 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.
- fn42 10y agoIt 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 10y agoNo, 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).
- AstralStorm 10y agoIt takes just one local root exploit for ADB. Which is why it has to be switched on manually on the device. The other way is supposedly protected by manual installation and signing keys.
- revelation 10y agoJTAG 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 10y agoIt 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.
- Animats 10y agoI 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 10y agoAlternatively 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?
- Animats 10y agoLooking 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-cehuvA9qCDuX9&t=650 https://youtu.be/QuuTLkZFsug?list=PLOcrXzpA0W82Z49Pj0v-cehuv... [2] https://youtu.be/QuuTLkZFsug?list=PLOcrXzpA0W82Z49Pj0v-cehuvA9qCDuX9&t=1141 https://youtu.be/QuuTLkZFsug?list=PLOcrXzpA0W82Z49Pj0v-cehuv...
- ChuckMcM 10y agoWow, time to find the special USB port and fill it with Epoxy on your system.
- wyager 10y agoI'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.
- watersb 10y agoProtocols, not pins
- tbrownaw 10y agoThe 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 10y ago> 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.
- NKCSS 10y agoWhy 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 10y agoPhysical 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.
- deleted 10y ago[deleted]
- PinguTS 10y agoFunfact: 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.
- campuscodi 10y agoSo a security researcher using Intel-approved debugging tools has found he can take over CPUs... isn't that the purpose of debugging modes?
- SixSigma 10y agoSo a security researcher using Intel-approved debugging tools has found he can take over CPUs ... and wrote an article describing the process for public consumption for benefit of people unaware of the issue, of which there are many.
- throwaway7767 10y agoYes, 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.
- mdekkers 10y ago"debugging" mechanism....
- gm-conspiracy 10y agoCan this be enabled in the BIOS via vPro?