First
Let's go hack the x86 world.
Positive Technologies, which in September said it has a way to drill into Intel's secretive Management Engine technology buried deep in its chipsets, has dropped more details on how it pulled off the infiltration. The biz has already promised to demonstrate a so-called God-mode hack this December, saying they've found a way …
....."The design choice of putting a secretive, unmodifiable management chip in every computer was terrible, and leaving their customers exposed to these risks without an opt-out is an act of extreme irresponsibility," (EFF)...
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
In years past it would be tin-foil hat territory and it can be equally well assigned to incompetence, but it would seem to be awfully convenient for the various 3 letter agencies out there. More-so if it had been kept under wraps. Will this spell the end of such dual controls or will the World just quietly ignore it whilst updating their status?
I imagine that there *are* people (say, in Russia or China) who *are* now asking whether there is a trusted source of x86-compatible CPUs. And if not, whether there ought to be.
If these people *aren't* asking that question, they aren't doing their job properly.
Actually, Russian government asked this question several years back, passed protectionist legislation, and is now turning to its own CPU designers and fabricators for their systems.
I can only imagine, China being China, it has already done this several years back.
I do use a separate computer for my privacy needs. It's built with an Intel Pentium 4 511 2.80GHz 533 and a 915GEV motherboard. Actually it's surprisingly fast for what is 12 year old technology. It makes me think that for most use cases, there's not much gain in running the latest CPUs.
Apple's secure enclave runs the L4 microkernel, which has been formally verified. Intel's supposedly-secure management engine runs a 30 year old OS used for teaching that has never had any sort of security evaluation.
Yeah, that makes sense. I would have assumed it ran some sort of microkernel that's at least been designed for embedded use!
This post has been deleted by its author
The bit at the end is the important part. It says earlier versions of MINIX were designed for education, later versions for availability, and none were designed for "military grade security".
Intel took a copy of an earlier version. The creator of MINIX hopes that Intel did security hardening on it in addition to the changes that Intel asked him to make to the source code.
What is the fascination with formally verified software all of a sudden? It means nothing in the real world. Many commercial TCP/IP stacks have been formally verified, almost all have suffered serious security issues (many found by Michal Zalewski). WPA2 was also formally verified, and we now see how that worked out in the real world. Lots of software also happens to fully pass their test suites, before we start exploiting it. ;-) Save your money, skip the formal verification, and focus on simplicity.
well, there's now a linux version that disables it [so they say].
I expect that requiring physical access to the machine is enough, for the moment, but I'm still concerned about any on-board network adaptor being connected in ANY way to the outside world.
Keep in mind, IPv6 exposes EVERYONE to the intarwebs, because (virtually) all IPv6 addresses are *PUBLIC* and therefore any unfirewalled listening ports are also PUBLIC. If your NIC can be cracked using an exposed port, in ANY way, because of the "management engine", we are all in one huge sorry state as far as security goes...
I am not aware as to whether Intel's "management protocol" can withstand intarweb routing. Most likely it can withstand WIFI routing, and possibly a spoof of some layered protocol if you're using a VPN. Sniffing any kind of SSL would be extremely difficult, but not impossible, especially if your network is being monitored. The odds of this crack being successful WITHOUT physical machine access is PROBABLY small. HOWEVER, I wouldn't trust it anyway, so maybe I should stick with "the earlier architecture".
...all IPv6 addresses are *PUBLIC* and therefore any unfirewalled listening ports are also PUBLIC
Ahem. You might want to look into IPv6 link-local and IPv6 unique-local addresses (not the deprecated site-local as I originally wrote).
Firewalling networks is also (as you imply) generally a good idea. IPv6 capable IoT devices directly connected to the Internet need to handle things differently, which is a whole other story.
Note that all IPv4 addresses are public, that is, they are all known, it's just that some are defined by the rules as unroutable on the public Internet, and most ISPs enforce that by filtering. IPv6 local addresses are similarly defined as unroutable on the public Internet, but unlike IPv4 non-routable addresses, IPv6 local addresses have the capability of having good chance of being globally unique, unlike, say 192.168.1.1 or 169.254.1.1.
> Note that all IPv4 addresses are public ...
Bombastic Bob is probably talking about home routers generally using NAT for IPv4, which didn't originally have an equivalent for IPv6. Most home routers offering IPv6 still seem to just expose the plain IPv6 address directly anyway. Not fantastic.
> You just need the firewall, and I don't recall firewalls going away with IPv6, not even on home routers, unless you can prove otherwise.
It would be great if it was that simple. :)
Home routers are often used by people with no real knowledge of computers/IT. They have no understanding of TCP, let alone what the heck a "port" is. So getting them to (correctly) configure a firewall for their new something-they-just-plugged-into-the-network isn't really practical.
Some home routers have a GUI which lets people select a protocol (eg HTTPS) for a device, and can build a basic firewall based on that. That definitely helps. But it's not a real solution to the problem, as many devices use non-standard ports, and the end user won't have a clue what to do.
NAT in the IPv4 world was a "good enough" solution to that problem. Not because it expanded the address space, but instead because it (incidentally) hid users end devices from external things being able to reach them. That seems to be what Bombastic Bob is talking about.
Home router issues don't go away with IPv6. That's why uPnP exists for better or worse because the computer illiterate want to use their stuff, the Internet is not built around hand-holding, and the security/ease-of-use dichotomy prevents a happy medium. You simply can't fix Stupid, but Stupid outvotes you, so you can't tell them to stay off the Internet.
Simple. To talk to an IPv6 Internet, you need an IPv6 stack, period. There's just no physical way to cram 128 bits into 32 bits of space without something giving. Since you'll already have the IPV6 stack...
You have heard of tunneling IPv6 over IPv4, haven't you? ;)
Around these parts, we've already had to deal with blocking that as muppets discovered it and were using it to get around blocks, rules and regulations.
NAT in the IPv4 world was a "good enough" solution to that problem. Not because it expanded the address space, but instead because it (incidentally) hid users end devices from external things being able to reach them. That seems to be what Bombastic Bob is talking about.
this! i wish i could give you more thumbs-ups but...
You don't need NAT for IPv6. Heck, it's generally not needed given the address space.
It isn't a matter of needing NAT. It is a matter of being no one's business how many systems we have connected to our networks and using services on/over the Internet. NAT allows for multiple systems to use the connection of one system without exposing their private parts to the world+dog. IPv6, by design, leaves your privates exposed for any dog to come sniffing about.
"generally using NAT for IPv4"
yes (and the rest, mostly yes).
Sure, there's a spec for IPv6 NAT somewhere, but I'm not aware of it actually being used. I rely on a firewall blocking 'incoming' traffic from "teh intarwebs" on specific ports that are well known, like 139, 445, 6000, yotta yotta and those ports that Winders machines INSIST on listening on "*" to... [because the coders were TOO LAZY to bind it to localhost]
"Most home routers offering IPv6 still seem to just expose the plain IPv6 address directly anyway. Not fantastic."
As long as they apply the _same_ firewalling rules on IPv6 as on IPv4 (ie, all incoming blocked by default, etc) then there's no major issue.
There are of home routers which mirror the IPv4 rules to IPv6 by default.
It always makes me laugh the amount of downvotes for questioning the default security implications of IPv6, it's like going into a group of knife jugglers and saying "it's a bit dangerous" and getting "of course it's not dangerous we are all professionals!!".
IPv6 for the average user is less secure than 4 for the simple reason very few people had their PC on a public v4 IP or relied solely on the internal firewall, in fact must internet users couldn't tell you if they are running a correctly configured firewall or have ever allowed software to drill through that.
I like a router with a firewall, blacklist, whitelist, maybe a bit of traffic shaping, logging etc and you bunch of knife jugglers can do as you please, blindfolded.
Ooh I mentioned the downvote, we know what comes next! frankly I couldn't give a shit and have just about forgotten what I used to come to this site for...
what's a good consumer-grade router than comes, or can take, the better open source router OSs?*
* skipping on DD-WRT - DD-WRT itself is really nice, but their website is utterly confusing as to what build might be expected not to be brick your particular router. I'll confess a lack of comfort at playing around blindly with something that controls your internet access - even if it's not permanently damaged, googling how to fix your corrupted router can be problematic.
Loads of great reasons for this little beauty to exist... some extinction level event the Overlords didn't want anyone to know about like an impending asteroid strike, discovery of a real alien invasion, to stop rogue AIs using CPUs like neurons to take over the world, or to rewrite history to their liking...
I just read Wikipedia's entry on the ME.
The thing can execute Java as well.
I found this video particularly enlightening/scary; https://www.youtube.com/watch?v=iffTJ1vPCSo
TLDW;
IME is the tip of the iceberg, AMD isn't safe either, extensible firmware is the wrong way forward, you need to shred your motherboard and buy something with open source Linux firmware.
You can try and neuter ME but you might need a hardware programmer see me_cleaner for details https://github.com/corna/me_cleaner
Bleeping computer gives a bit more info, together with a response from Intel when a very similar issue was raised in January:
Intel CPUs Can Be Pwned via USB Port and Debugging Interface
I think the news is that some of restrictions mentioned in January have now been worked around. My guess, because I don't read Russian, is that they've managed to avoid needing a key from Intel to turn on the DCI capability.
For those who don't linke shortened URLs, the blog is here at habrahabr.ru.
Ahh yes - a swift bit of Google translate and it seems that if DCI is not blocked in BIOS (which is true for many PCs, apparently), then it can be enabled 'on the fly'. They give a mitigation:
As a protection against such attacks, we recommend activating Boot Guard, checking the DCI activation bit and prohibiting debugging in the IA32_DEBUG_INTERFACE register.
What could be interesting is if you can execute code on the main processor which could then communicate in a debug session via the XHCI controller with the ME . That would likely have interesting consequences, as it would bypass the need to physically plug something into a USB port. I would imagine some thought has been put in by Intel to prevent precisely that.
Me too! Obviously a few commentards of a certain age on here.
I often think Andrew Tannenbaum is one of the most overlooked pioneers in computing history and deserves a lot more credit than he gets. IIRC correctly, he never really "got" the open source thing until much too late and MINIX had been eclipsed by Linux.
Anyway, I'll raise a glass to him
It's all very well promoting FOSS as less likely to have holes because of plain sight oversight. But unless and until you have verified every underlying component - including the logic gates bakes into the silicon - you are still placing your trust in Somebody Elses Work.
When I was cautioning about trusting CPUs, I envisaged the odd dodgy or undocumented opcode that could escalate privilege, or access processes.
I have to admit, that cynical as I am, I didn't imagine a hidden OS in the CPU.
So, how many other chips have hidden depths then ?
Might want to capitalize 'you' there as unless YOU have personally verified every underlying component you are placing your trust in somebody else's work. I think Apple's secure enclave is far more secure than Intel's ME, for a variety of reasons. But I'm still trusting Apple has implemented it in the way they say they have, and Apple is probably trusting the team who formally verified the L4 microkernel they're using (i.e. I doubt they rechecked the verification themselves)
The world is several centuries past the point where it was possible for someone to verify everything they have or know. Maybe DaVinci was the last who might have. What we instead must trust is that someone will discover when trust is misplaced. It took a while, but someone has discovered that any trust in Intel that the ME was secure was misplaced.
Hopefully that puts pressure on Intel to fix what has been found, do their own investigation to find/fix things before more are discovered by outsiders and they look even worse, and to consider security as the #1 requirement for the ME going forward. Even if that means revisiting their IMHO terrible ideas of using Minix for it, leaving JTAG connected in production shipments, etc. I think the overall design is so broken they need to start from scratch and design ME v2.0.
"Hopefully that puts pressure on Intel to fix what has been found, do their own investigation to find/fix things before more are discovered by outsiders and they look even worse, and to consider security as the #1 requirement for the ME going forward. Even if that means revisiting their IMHO terrible ideas of using Minix for it, leaving JTAG connected in production shipments, etc. I think the overall design is so broken they need to start from scratch and design ME v2.0."
I don't think it's possible for security to come first in the IME, simply due to client demands. Remote management is paramount. That's why it's called a management engine. In this case, security gets in the way of management, and there's likely no way to achieve both, and lack of management affects the bottom line more directly than security in this case.
The FAQ link to the licence on the Minix site, http://www.minix3.org/license.html returns 404 and, according to archive.org has done so for some years. Going back to an older version it is, as the FAQ states, a fairly standard BSD link which requires that binary distributions credit the origin in the documentation. I wonder if Intel do that and if so how conspicuously. A very quick search through the generation 8 datasheet failed to find anything and Tanenbaum himself has recently said that it would have been nice if they'd let him know. Does Intel's use actually abide by the terms of the licence?
"Does Intel's use actually abide by the terms of the licence?"
not unless it's a true "creative commons" license. BSD-like and MIT-like licenses usually have copyright requirements where you acknowledge the owner of the original source for your copied or derived work.
So yeah, it COULD be a license violation, if we had license text to prove it.
"So yeah, it COULD be a license violation, if we had license text to prove it."
Put the link I gave into the Wayback mackine, go back a few years and you can read it. The problem isn't finding the licence, the problem's working through the Intel document mountain to see if they do acknowledge it.
It's the old thing that if you have physical access which now includes to the machine's USB ports the machine is open.
The other thing that's got completely out of hand is browsers. They are more complicated than operating systems were not long ago. If you run a browser it is best to assume that anything the user running the browser has access to is compromised. (See recent item about ads redirecting the user.)
As for hypervisors and relying on their relatively shiny CPU features don't get me started.
"At its inception in 2006, the ME was reportedly located on the MCH (northbridge), but when that became integrated into the CPU beginning with Nehalem, ME was moved to the PCH (current-day “southbridge”). "
http://www.tomshardware.com/news/google-removing-minix-management-engine-intel,35876.html
Worldwide kill/modify switch?
Wait when it was reveled that linux could be hacked via USB people here said it's no big deal because you had to have physical access. So why is it that people are not comming to the support of intel since you need physical access to the USB port ?
https://forums.theregister.co.uk/forum/1/2017/11/07/linux_usb_security_bugs/
I think it is great. If you favorite hat color is black.
Think about the possibilities.
1. Malicious website uses social engineering tricks to let user grant it WebUSB access.
2. Using said access, it hacks into a piece of hardware which communicates over USB protocol but which may even be a physical part of your computer (e.g. laptop keyboard or touchpad). So nice try that you filled your USB ports with epoxy but it didn't help.
3. From the compromised device it now hacks back into your computer using the IME vulnerability.
It doesn't even matter anymore if you run Windows, macOs or Linux!
Yeah. I'm just wondering that myself. If you have USB access you can probably also reach the power button, in which case - short of full disk encryption - you're pwned anyway.
Not sure I buy the hacking model of distributing USB disks with rootkits on them - yes, I've seen Mr Robot - I know that it's possible, but it's a bit specialised and doesn't scale well. Plus, I presume the stick has to be in the drive when the machine boots, no? It's not like if you plug in a USB stick claiming to be a JTAG interface it will somehow magically bypass the OS USB stack and go straight to the lights-out chip. That might fly with firewire but USB has only a single master.
In short, nice hack and Intel deserve a kick up the arse, but I don't see this being a major risk - unless it works without booting the machine, and with the software-simulated USB over XHCI as someone posited above. Then we're all fucked.
Imagine if someone could get malware on a USB device that's commonly plugged into computers. Like say an Android phone...
Or the old standby of getting them to plug a USB key in their computer. Imagine if you knew where a lot of Intel employees went during lunch hour, and dropping a USB key in the parking lot marked "AMD confidential, if found please destroy". Don't think anyone would be dumb enough to check it out?
BadUSB (and by extension, the hypothetical rooted android device) both create a dodgy USB device which interacts with the OS to do bad things. I know about that (I've built quite a few USB devices myself). They don't "attack the baseline controller", but act as a keyboard, disk - all normal devices that the OS would expect to see, but programmed in a way to attack the target computer by sending malicious keystrokes etc.
But this hack requires the USB device to interact with the Intel lights-out chip, not the OS. That was the point I was making: while the OS is running, the OS is in control of all USB communications and would (I believe) have to explicitly allow the device to communicate with the lights out chip. This is because USB is a single-master design, so you cannot have two USB controllers acting on the bus at the same time.
USB devices report themselves by vendor and product ID, so it's possible that the Intel management chip would intercept any USB devices of a certain type (the described JTAG-to-USB device) and not report them to the OS. Then, this attack would work against a running computer. But that's not what was reported.
Urrr
I still have a box of blue 768Mb floppies. 28 of them. And a blue and white binder. With 600 and change pages of source code & commentaries. Cut my teeth on that stuff with an 80286 4.77Mhz from Commodore Canada.
Thanks Mom.
(It was a christmas gift. She was building a TI/(something) from a kit she'd bought).
So it seems I have a decent start on hacking some servers ... I just have to get the floppies copied over to a virtual disk and spin it up in kvm.....