Is the 'Secret' Chip In Intel CPUs Really That Dangerous? (networkworld.com) 245
New submitter Miche67 writes: A recent Boing Boing blog post by Damien Zammit is stirring up fears, claiming Intel's x86 processors have a secret control mechanism that no one can audit or examine. And because of that, he says it could expose systems to undetectable rootkit attacks that cannot be killed.
Blogger Andy Patrizio, after talking with an Intel spokesperson, says the developer's argument has holes and he doesn't think Zammit will persuade Intel to replace the system with a free, open source option.
Blogger Andy Patrizio, after talking with an Intel spokesperson, says the developer's argument has holes and he doesn't think Zammit will persuade Intel to replace the system with a free, open source option.
So, what we have is an open source crusader scaring the daylights out of people on a giant what-if scenario that even he admits couldn't happen in our lifetimes.
An Intel spokesperson told the publication: While the Intel Management Engine is proprietary and Intel does not share the source code, it is very secure. Intel has a defined set of policies and procedures, managed by a dedicated team, to actively monitor and respond to vulnerabilities identified in released products. In the case of the Intel Management Engine, there are mechanisms in place to address vulnerabilities should the need arise.
So .. Security by Obscurity. (Score:5, Insightful)
How nice ... Is there any history about how that has worked before?
Re: (Score:2, Insightful)
By its very nature, you never hear about the cases where "Security by Obscurity" actually works.
Re:So .. Security by Obscurity. (Score:5, Informative)
Very relevant video presented at last year's CCC
https://media.ccc.de/v/32c3-73... [media.ccc.de]
The whole model (in)security is thoroughly explained - better than on yesterday' article,
and way, way better than on this so called "rebuttal".
Re: (Score:2)
Re:So .. Security by Obscurity. (Score:4, Insightful)
While the Intel Management Engine is proprietary and Intel does not share the source code, it is very secure. Intel has a defined set of policies and procedures, managed by a dedicated team, to actively monitor and respond to vulnerabilities identified in released products. In the case of the Intel Management Engine, there are mechanisms in place to address vulnerabilities should the need arise.
That "spokesman" did learn this exact paragraph in his management college. Exact. He was told to remember it word by word.
Intel workaround divined (2 chickens and goat guts (Score:2)
1) carefully break hermetic seal of chip case in 0.15 micron clean room.
2) locate IME section on silicon under 300x microscope per diagram {secret}
3) using polygraphene pen under robotic control, connect IME die {secret} to {secret}.
4) hermetically evacuate clean room to -300 torr
5) reseal hermit chip case using {secret}
6) PROFIT!!
Re:So .. Security by Obscurity. (Score:5, Insightful)
Sure, FBI sends "National Security Letter" to Intel, demanding they open the door without telling anyone. FBI then has unrestricted access to Intel systems, worldwide, but "no, you can't see the source code, it's secure, we promise."
Re:So .. Security by Obscurity. (Score:5, Interesting)
Re:Security by obscurity works quite well. (Score:5, Insightful)
The term "security through obscurity" normally refers to the method being secret, not to secret information used to authenticate an actor within the system. More specifically, it normally refers to relying on the method being secret to make discovery of a vulnerability more difficult, rather than actually fixing the vulnerability. Clearly this is bad if an adversary becomes aware of that vulnerability anyway.
Re:Security by obscurity works quite well. (Score:5, Informative)
No, the term security by obscurity means that the method MUST be a secret, because that secret is the only thing providing security. It is entirely possible, and quite normal, to have a security system which does not REQUIRE the method to remain secret, yet still not disclose what that method is. That is NOT security by obscurity, it is additional security by obscurity, and is in no way a bad thing.
Not disclosing the method sucks from an auditability standpoint, but in no way means that the actual security is provided by obscurity.
Re: (Score:2)
[I]t normally refers to relying on the method being secret to make discovery of a vulnerability more difficult.
No, the term security by obscurity means that the method MUST be a secret, because that secret is the only thing providing security.
I'd argue that you're actually agreeing here. MUST versus relying. It's the GOP's claim that the password, private key, PIN, gesture, one time pad, etc. determines the system's obscurity—not the method itself—that you're both disagreeing with, and rightfully so.
"Security through obscurity" has a very specific meaning that the GOP is trying to invalidate by claiming that every method that requires a secret is obscure. They are trying to equate a system that uses a 2048-bit public/private key pa
Re: (Score:2)
Re: (Score:2)
The term security by obscurity does not refer to any system that relies on secrecy - it refers to schemes that are flawed by being trivially easy to compromise once a secret is revealed.
Requiring a key to unlock a door is not security by obscurity, even though the pattern of the key is the secret.
Hiding the key under the doormat is security by obscurity.
Re: (Score:2)
I agree with your examples, but I think your first sentence is inconsistent. If a system becomes trivially easy to compromise only once a secret is revealed then self-evidently that system does rely on secrecy for its security.
Re: (Score:2)
Given that I've been working in this field on and off for multiple decades, I'm reasonably sure I understand one of the most basic principles, thanks. And yes, I would agree with your example there.
Since posting earlier, I'm wondering whether I just parsed Trongy's post differently to how it was meant. If the intended point was that there exist systems that rely on secrecy but are not examples of security through obscurity, I would have agreed with that, too.
Re: (Score:3)
"Security through obscurity" is a term of art, a quick way of referring to a useful concept that anyone who works in the field understands. That meaning is surely also what the OP was referring in their post. Perhaps you weren't familiar with it, but every professional or academic working on IT security will be.
Security through obscurity is not a particularly successful technique and never has been, as you can tell from the vast number of published exploits against systems that were not actually secure base
Re: (Score:2)
Security through obscurity is not a particularly successful technique and never has been, as you can tell from the vast number of published exploits against systems that were not actually secure based on vulnerabilities that were discovered despite their obscurity.
Security through obscurity is essential in a lot situations and is highly sucessful, particularly in the systems that don't end up in a paper at some CHES conference.
Undersirable as DRM might be, it by definition is security through obscurity because everything needed to break the DRM is in the hands of the owner of the device. If there's a key, it's in the box and you need to obscure it.
Side channel protections are often security through obscurity. Again everything is in the device and is observable. Metho
Re: (Score:2)
Obscurity is a perfectly acceptable security tool.
No, it is not. Your key being blank #23 and key pattern 8442332 isn't "obscurity". But the spare key being kept under a rock by the back door is.
Re: (Score:2)
Obscurity is a perfectly acceptable security tool.
No, it is not. Your key being blank #23 and key pattern 8442332 isn't "obscurity". But the spare key being kept under a rock by the back door is.
Yes it is. Pointing out a bad example doesn't mean there aren't good obfuscation techniques.
Re: (Score:2)
So is this a manufactured clickbait story? (Score:5, Insightful)
So from what I can tell, this entire fiasco is basically some blogger who was clearly ignorant of how enterprise management features that have been present in hardware for *years* having an "OMG YOU TRANSMIT YOUR IP ADDRESS TO THE WORLD EVERY TIME YOU GO TO A WEBSITE!!" moment.
And it wasn't even that original since the same damn hissy fit gets thrown every year or so as memory serves, since this is by no means the first time I've heard the conspiracy theory.
So, either this guy is an idiot (not discounting that at all) or he managed to troll people into generating clicky clicky ad revenue by recycling conspiracy theories. Some of the people being trolled might be willing participants to boot.
Re: (Score:2)
The biggest flaw I've heard in some early remote management systems was piss-poor security.
Re: (Score:2)
That sounds about right. As best I can tell from the article they are essentially talking about the kind of stuff you can do from a DRAC/IPMI port. But there is no requirement that you plug in an Ethernet cable into the associated port if you don't want to.
Re: (Score:3)
You're going to make a comparison to IPMI?
Start reading: http://fish2.com/ipmi/ [fish2.com]
Re: (Score:2)
As best I can tell from the article they are essentially talking about the kind of stuff you can do from a DRAC/IPMI port.
And yes, don't you think a drac/ipmi functionality that had any exploitable security holes would represent a rather massive security issue?!
I know certainly do. And most PCs that aren't using these features should probably have it off by default, don't you think?
But there is no requirement that you plug in an Ethernet cable into the associated port if you don't want to.
Many boards with it only have ethernet port. Its not necessarily a physically separate port like the ones on my servers.
Re: (Score:2)
The ones that I have used all have a separate ethernet port for the management console. So by default it is off as you need to physically plug in an extra cable (and configure it in the BIOS) before any of this matters.
Show me a machine where you can't disable it in the BIOS, and where it shares the same ethernet port as the main machine, and then I will get a bit more excited.
Re: (Score:2)
All machines since 2008-2009 are "you can't disable it in the BIOS".
Re: (Score:2)
Re:So is this a manufactured clickbait story? (Score:5, Informative)
and where it shares the same ethernet port as the main machine
Seriously? How about... practically all modern intel PCs. (very very few of which have a dedicated magement port)
"The Management Engine (ME) is an isolated and protected coprocessor, embedded as a non-optional part in all current (as of 2015) Intel chipsets."
https://en.wikipedia.org/wiki/... [wikipedia.org]
So if you can find an modern Intel PC with a single ethernet port. It's got it.
where you can't disable it in the BIOS
Disabling AMT in bios, may not actually disable it, it may just disable exposing it as a device to the host operating system. There are *plenty* of posts from people who disabled AMT only to find it was still running, still picking up an address via DHCP, and still manageable via AMT management tools, even while the PC was "off".
In general there generally are ways to disable it; I can't find a cite for a system where it literally couldn't be turned off.
But.. even turning it off isn't reliable.
"A Ring -3 rootkit was demonstrated by Invisible Things Lab for the Q35 chipset. [...] The ME rootkit could be installed regardless of whether the AMT is present or enabled on the system, as the chipset always contains the ARC ME coprocessor. "
https://en.wikipedia.org/wiki/... [wikipedia.org]
So even where AMT was disabled, the co-processor is still physically there and may be reachable/exploitable.
Oh, and i forgot to mention, it works with laptops on wifi too.
"Intel AMT supports wired and wireless networks. For wireless notebooks on battery power, OOB communication is available when the system is awake and connected to the corporate network, even if the OS is down."
I certainly don't think this article does any justice to the situation. But at the same time, the management engine stuff is a giant gaping security hole that does present serious and non-trivial to mitigate risks when exploits are found.
Re: (Score:2)
If I choose the option in my BIOS to *erase* the ME firmware, does that make it any better?
Re: (Score:2)
If your BIOS has that option, I'd think so,
But the coprocessor is still physically there; and the prom space for firmware still writaeble, so the potential for a root-kit to infect the space still exists.
Although at least remote exploit is unlikely; we're now at least talking about a local root privileges exploit to get the new infected firmware loaded; same as any other rootkit... although given it infects the ME firmware, you'd have to re-flash to get rid of it; assuming you managed to detect it.
Re: (Score:2)
If I choose the option in my BIOS to *erase* the ME firmware, does that make it any better?
I was under the impression (from some of the sketchy online stuff touting it a few years back) that "erasing" the ME stuff actually consisted of erasing the configuration and returning it to factory settings.
Presuming this is true: Since factory settings consist of it waiting for anybody claiming to be its owner, and having the necessary software tools, to configure it, "erasing" it takes it from only responding to t
Re: (Score:2)
The point isn't that its on when the system is off. The point is what it can do to the host system when its on. It can read RAM. It can communicate over the network. Its completely beyond the control or purview of the host operating system.
What does it monitor when the computer's actually on? Talk to Intel.
The point being that if it can be exploited, then its at the mercy of hackers. So you can run OpenBSD or whatever you like, and if the ME is exploitable someone can remotely connect to your system, keylog it, rootkit it, read out the contents of ram...
Its fundamentally in
Re: (Score:2)
To me, the whole concept of enterprise management is broken. We managed to put a man on the moon without IT goons sniffing around to make sure you weren't using unapproved software. And operating system built into the chip so that you can access it even when it's turned off, just seems bizarre, and to add this to *every* computer is overkill. If there are a few key computers that you need to access even when they're turned off then add extra third party hardware to those computers rather than having it bu
Re: (Score:2)
talking about the kind of stuff you can do from a DRAC/IPMI port.
As far as I know it was an attempt to remove the dedicated processor that powers DRAC/iLO and relocate it to the Intel Chipset. It is a win for Intel in that it helps Dell and HP relocate management features to Intel chipsets and vendor lock in (cockblocking AMD further), while also removing expensive custom ICs that themselves were often buggy and flakey.
It does have the ability to do some things that those solutions did not have the capab
Re: (Score:2)
while also removing expensive custom ICs that themselves were often buggy and flakey.
And of course, Intel is never buggy and flaky.
Re: (Score:2)
> I guess it doesn't turn into the correct acroynm
If you say "ip-me", then it is an acronym. If you say I-P-M-I then it is an initialism. Which is it?
Re:So is this a manufactured clickbait story? (Score:5, Insightful)
It appears that you are correct that this "isn't new", but it also appears that the only answer ever received is "trust us". And while this isn't proof that the conspiracy theories are right, it isn't exactly proof that the "conspiracy theories" are wrong.
Re:So is this a manufactured clickbait story? (Score:4, Informative)
Not only "trust us," but also "oh, by the way, you have no choice because we've made implementing your own open-source firmware impossible" [libreboot.org].
Re: (Score:2)
Re: (Score:2)
Still seems to me that it could be a significant concern, if not an immediate concern.
I'd primarily be worried that if a serious vulnerability was discovered, that many systems could retain the vulnerability for many years due to the fact that motherboard BIOSes are frequently not updated for years at a time. Presumably the vulnerability could be mitigated at the OS level, but it still sounds like a potentially worrying source of attack, and I'd feel a lot better if it were made open-source.
Re: (Score:3)
So from what I can tell, this entire fiasco is basically some blogger who was clearly ignorant of how enterprise management features that have been present in hardware for *years*
It is true that this is not new. It's not clear to me how many people are aware of it however.
Intel ME has greater capabilities than I think it should have for its purpose. In fact, no one is sure of all its capabilities as it seems we'd discover a new and unexpected one every time we hit a bug (at the time, this was many times d
It has backdoor access. Authentication issue? (Score:2, Insightful)
The chip has the "power" to do many things including take secret control of a system, transfer files, read RAM, anything. No debate on that.
The "debate" is whether security through Intel obscurity (un-auditable unless you work for them) can be trusted FROM NOW ON, without checkups.
If history is any measure...
Re:It has backdoor access. Authentication issue? (Score:4, Insightful)
Who drives the need? (Score:4, Insightful)
In the case of the Intel Management Engine, there are mechanisms in place to address vulnerabilities should the need arise.
Umm, if Intel is the only holder of the keys to the kingdom, then they get to decide when the need arises. In fact, how much do you want to bet that if someone is nice enough to bring an issue to Intel's attention and Intel decides to take no action that there's a "by the way, if you so much as make a peep about this we'll bury you in an avalanche of DMCA litigation for the rest of your natural life"?
Forgive me if I'm skeptical about this. I think I'd rather have an agreement with Darth Vader. At least he doesn't pretend to be a nice guy.
Re: (Score:2)
I think I'd rather have an agreement with Darth Vader.
Are you sure about that?
https://www.youtube.com/watch?v=jsW9MlYu31g [youtube.com]
Re: (Score:2)
I think that was the point. At least Vader doesn't pretend to be trustworthy in the first place.
Re: (Score:2)
Well you could always renegotiate the deal? [youtube.com]
Re: (Score:2)
>if Intel is the only holder of the keys to the kingdom ...mighty big "if" you've got there. Seems to me that it's quite likely that from the moment this functionality was introduced, various three-letter agencies (among others) started trying to get unrestricted access to it. Maybe it's technologically bulletproof, the first such device on the planet. But even if so, you have to ask just how dedicated Intel is to keeping their keys secure. Will they refuse any and all threatening letters from the go
Re: (Score:2)
Right, because there's no way to ANONYMOUSLY post vulnerability information on the internet... Every known bug out there was submitted with the person's legal name and current address.
At some point, reality enters the equati
Stop worrying (Score:5, Insightful)
"While the Intel Management Engine is proprietary and Intel does not share the source code, it is very secure."
Well alrighty then, I feel so much better now. Because when a technology company says something is "very secure", you can take that to the bank!
Re: (Score:3)
Especially if you're an Eastern European cracker, huh?
Re: (Score:3)
Well alrighty then, I feel so much better now. Because when a technology company says something is "very secure", you can take that to the bank!
What I want is to be secure from an Intel subjected to coercion by a corrupt government.
Re: (Score:2)
Then don't give Intel, or the corrupt government in question, access into your LAN.
If the government has to gain physical access to tap into your local network so that they can possibly break into your computer via Intel AMT, well, that's just one small step from physically walking into the building and seizing your computer, anyhow, so why would they even bother with the AMT?
Re: (Score:2)
Then don't give Intel, or the corrupt government in question, access into your LAN.
Malware happens. Malicious hardware can turn a harmless attack into an effective one.
Re: (Score:2)
Except AMT malware does NOT happen.
At some point, reality enters the equation, and you just need to keep your extreme paranoia in-check. Does anybody here have ANY cases they can point to, where AMT was exploited? Wake me when 99% of computer exploits cease to be drive-by phishing, and Linux/FreeBSD/Firefox/etc. cease to have ANY bugs that can be exploited, requiring attackers to escalate to finding hardware bugs.
Always trying to lower the TC0?? (Score:2)
take that to the bank you are hitting to get an "unlisted" account from??
Odd.. (Score:3, Insightful)
This capability has existed in certain CPU/chipsets since the Intel Core processors were released yet to date no one has successfully 'hacked' into this well-advertised feature...
Did this boing-boing blogger check with anyone that, you know, is fairly current on the Intel platform before exposing this 'incredible' security issue?
Re:Odd.. (Score:4, Insightful)
> yet to date no one has successfully 'hacked' into this well-advertised feature...
Not that we know of anyway. Generally the really bad guys don't publicize what they've found, they just use it. So who knows? For all we know there might be some cool new ransomware being developed right this instant that will deploy and activate in the next 3 months that locks up most of the Intel systems on the planet.
Yes (Score:5, Informative)
Anything I cannot audit, I have to trust. I have no reason to trust Intel. So yes, it is potentially dangerous because I can neither audit nor trust it.
Re: Yes (Score:4, Informative)
Then turn it off in the BIOS.
Seriously, this is not a 'secret' function built into the CPau, it is a feature implemented in chipset and controlled by a BIOS setting.
Re: Yes (Score:5, Insightful)
That's horribly naive. Even if the interface claims that it's "off," there is no proof and no reason whatsoever to trust it.
Trust comes from being able to read the source code (all of it), compile it yourself, and load it on the device. Nothing less.
Re: (Score:2)
That's horribly naive. Even if the interface claims that it's "off," there is no proof and no reason whatsoever to trust it. Trust comes from being able to read the source code (all of it), compile it yourself, and load it on the device. Nothing less.
Without the hardware schematics and someone who can verify them there's no way to know what the hardware really does no matter what software you load on it. For example say there's a secret 1kB buffer that'll store the last 32 AES256 or 64 AES128 keys you've used with AES-NI, totally invisible. If you place the right 256-bit magic value in registers R12-R15 and call RDRAND, instead of doing its usual thing then and only then will it dump the keys out to you as "random" bits XOR'd with a second secret value.
Re: (Score:2)
It's worse than that. Even having the complete source code offers incomplete protection unless you are sure of your entire build toolchain. See Ken Thompson's hack: http://c2.com/cgi/wiki?TheKenT... [c2.com]
If you extend this to hardware, that's a whole nother layer to the crazyness.
Re: (Score:2)
once again, what guarantee do we have that port knocking won't activate the feature regardless of what's set in bios/uefi?
Re: (Score:2)
That was true for ME versions up to 6.0, but for newer intel hardware, you can't boot a system without ME involvement anymore. Quoting https://libreboot.org/faq/#int... [libreboot.org] :
ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include "ME Ingition" firmware that performs some hardware initialization and power management. If the ME's boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.
Re: (Score:2)
So then I have to trust the BIOS to actually do what it claims to do. It shifts the trust issue, but doesn't solve it.
Re: Yes (Score:2)
Re: (Score:2)
Off-the-shelves stuff is out of question: processors design at the hardware level is not something most of us can access, and I believe they also run some internal software over that, which is not accessible either. Same for the memory controller. *bridges are also out of the question. Mainline GPUs that can peek and poke through PCI, and most other extension cards almost always have some firmware parts that are closed sources.
Granted,
Re: (Score:3)
What you can do here is audit at the interface. This can be quite taxing but it is at least possible. In the end, different hardware elements still have to communicate with each other and they have to rely on documented interface specs for this, and here is where you can insert the crowbar. Yes, that can entail creating your own hardware to take a "man in the middle" kind of approach when the communication is harder to decipher. Whether you really want to invest this much into your audit is up to you, but a
Re: (Score:2)
Let's audit our system, then. First, we need to audit the CPU . . . oh, wait, do you have a tunneling electron microscope, cause I don't and we need to be sure that the actual die matches the supposed schematics. So we'll have to buy 10 CPUs from different locations, and analyse 9 of them to trust the 10th one. Yeah, the AMT is in there, but you have to get that first part of the audit done first.
Now, assuming you've gotten that far, and are willing to postpone auditing the AMT for now, it's time to audit t
Re: (Score:2)
Yeah, the trusting trust problem extends to hardware. Modern computers are so small, you need a computer to build them. But in order to build that computer, you need yet another computer.
So let intel insure it (Score:2)
If they are confident of their security, they ought to be able to get Lloyds to insure users against any break-ins or damages at the few X 100B$ level. Oh, maybe they can't convince Lloyds that it is *that* secure?
One thing that Snowdon taught us is that even the NSA cannot protect secrets. And yes, you can fault the entire program because of a single slip up.
who has the RSA private key? (Score:4, Interesting)
there is some empirical evidence - nothing concrete that can be shared publicly - which tends to suggest that the RSA private key that Intel uses is already known and in use. if nothing else, you should not be reassured that there have been no "gagging orders" that come out of the U.S. Government on a regular basis, preventing and prohibiting companies from telling anyone that "yes we have had the NSA knocking on our door and yes we were forced to give them the RSA private key because otherwise they threatened that whoops, it would be really hard to get export licenses for our processors".
this kind of threat by security services is not outside the realm of possibility: it already happens, and i have met someone who was present at a meeting (with GCHQ) in which this type of threat to destabilise their business model was actually made.
there is a really simple solution, here: don't buy systems with intel processors. that assumes of course that people are making systems for sale that don't have intel processors... and that's exactly what i'm doing. i'm not one for complaining *without* actually doing something about it, so if you'd like to sign up for the crowdfunding campaign which will launch very shortly, you can do so here - http://crowdsupply.com/eoma68 [crowdsupply.com]
Re: (Score:2, Insightful)
people are making systems for sale that don't have intel processors... and that's exactly what i'm doing. i'm not one for complaining *without* actually doing something about it
... Because you expect us to believe that Allwinner wouldn't obey the Chinese-government equivalent of a National Security Letter?
"scaring the daylights out of people..." (Score:2)
IME is defective by design (Score:3)
AMT allows anyone who can broadcast DHCP and legitimately purchase a certificate from a CA to own your system while if it isn't even turned on.
If there is a defect (as if the above isn't bad enough) they won't bother to fix their bugs once they have decided your hardware is no longer worth their time to support... same as IPMI vendors and all the rest.
Even when you turn off "AMT" in bios if you are lucky enough to even have that option which I do not... it is STILL there listening. The only way I've found to limit this unnecessary and unwanted system within a system madness is to disable the hardware virtualization feature which prevents sharing of hardware with IME and operating system.
Re: (Score:3)
Ho-hum. (Score:2)
If this latest revelation scares you, you'll go apoplectic to discover that this is SOP in IC design. Just about every IC more complicated than a 555 timer, from processors to Wi-Fi chips to you-name-it, has internal processors controlling substantially every part of their operation. It's a common technique to control every block one designs with an embedded core and a bit of code (in RAM, so that one could adjust the operation of the block after the design came back from fab by reloading RAM), making an
An Intel spokesperson told the publication (Score:4)
While the Intel Management Engine is proprietary and Intel does not share the source code, it is very secure.
I almost fell out of my chair laughing when I saw this.
Brief answer (Score:5, Interesting)
No. Obviously not and the guy stirring up trouble is either underinformed or irresponsible.
Most of the hardware in your computer isn't something you get (or could get) a gate diagram from. You'd never know if something is in there that theoretically could be triggered to do something. That's the way hardware is. This guy is fussing over a publicly known feature that people are using in the enterprise to manage systems en masse. It doesn't open some magic wormhole to the control system - it requires a clear path of access and a setup and all that fun stuff. Meaning if you want to use IME, you need to set it up on all the systems for your network environment and debug it and build tooling around it. It's not fun to get that stuff right, and often not that easy.
It's not impossible that there's a backdoor in IME, but it's just as easy to imagine a backdoor anywhere else in your system. It's hard to imagine how one could ever be confident that that's not the case. So the focus and the anger is misaimed.
Re: (Score:3)
Most other hardware doesn't have the external and CPU interfaces. A disk driver probably cannot do anything very useful with the data it sees if you use disk encryption. It can't read the data and probably doesn't have external network access.
This management system by design has low level access to the CPU and external interfaces. It is potentially a much more capable hacking tool.
Its not easy to think of a reason that there is not a local hardware disable since the management capabilities are not needed b
Nothing to see here; move along. (Score:2)
While the Intel Management Engine is proprietary and Intel does not share the source code, it is very secure. ,,, there are mechanisms in place to address vulnerabilities should the need arise.
Perhaps true, but this kind of talk makes my ass twitch.
Extra general purpose computer running firmware .. (Score:3, Insightful)
Can I replace this firmware blob with one of my own?
Can I replace the RSA key with one of my own?
Can I audit this firmware blob to see what it does?
Can I disable this ME subsystem?
Who else can access this ME subsystem?
"there are mechanisms in place to address vulnerabilities should the need arise."
So basically Intel and any designated third party can access your computer regardless of in place security mechanisms.
now that the cat is out of the bag (Score:2)
Service processor (Score:2)
It's a service processor. No big deal in itself, we had them as far back as mainframes go. The VAX-11/780 I worked on/with in college in the early 80s had a small PDP-11 (an LSI-11/23) in the bottom as a service processor. I'd be more worried about a much more direct avenue of attack: microcode updates. Every Windows system and most Linux boxes include the packages to take the latest firmware updates from Intel and AMD and download them into the CPU during system boot. If Intel wants to put something malici
They'll never guess the password (Score:2)
Holy shit, this ("nobody will guess the password") is the excuse?! I especially loved the dumbed-down "that's 2,048-bit security."
Re: (Score:2)
Its $CurrentYear (Score:2)
and you're still using Intel.
Intel's 1 paragraph response (Score:2)
Come on!! How can that even count as a "response"? The TFA just reiterate the original article, but punctuating it by the author's unexplainable hate for anything open,and at the very bottom, it quotes an "Intel Spokesman" in a few lines just saying "it is very secure".
All right! I feel safer already!
They cut it off (Score:2)
Re: (Score:2)
Oh, well, OK, if there are policies and procedures, and mechanisms, and stuff, I guess it's all cool.
The simple question is: if this is a "product" for enterprise "management", why isn't it possible to turn this godforsaken surveillance engine OFF at the hardware level?
the primary "if" (Score:3)
> namely, if it can be compromised by a rootkit
It fucking IS a rootkit.
Christ.
Re: (Score:2)
Well, Intel's view seems to be:
While the Intel Management Engine is proprietary and Intel does not share the source code, it is very secure.
I don't know about you, but I'm totally convinced and no longer worried at all.
On a totally unrelated note, does sarcasm work on the Internet?
Re: secure 'for now' (Score:2)
You really plan on running your 10 year-old i5 desktop in 2025?
Re: (Score:3)
yes, absolutely.
Re: (Score:2)
Re: (Score:2)
No, a Beowulf cluster of them!
Re: (Score:2)
Why not? Do you think it will self destruct before then?
Re: (Score:2)
I'm sure the NSA has surrounded duckduckgo with network spy stuff and knows what goes in and out.
For that matter, duckduckgo's privacy wording doesn't exclude NSA letters.