201–210 of 337 posts
Isn’t this vulnerability based on AMT, which is based on ME but disabled by default? Even then, every setup I’ve seen have AMT (a separate Ethernet interface) behind a firewall and is only accessible via local network. The outrage is hardly justified.
Isn’t this vulnerability based on AMT, which is based on ME but disabled by default? Even then, every setup I’ve seen have AMT (a separate Ethernet interface) behind a firewall and is only accessible via local network. The outrage is hardly justified.
There are close to 5,000 devices exposing their Intel AMT to the Internet: https://www.shodan.io/report/j3cFHOzs
And again, this is not the main point I’m arguing. What I’m saying is that supposedly “this is something that’s enabled by default on consumer devices” is verifiably wrong.
Earlier quoted context omitted.
More like 5 years, or even longer, where I work. We have some 7 year old Dell servers that are still chugging along, performing their duties as well as ever.
Usually the amortization of such systems is ~ 4 years. But many smaller companies choose to stay with the old systems a little longer, 5, or even 6 years lately. Simply because there is no push performance wise. The main motivation for upgrade is software support (usually for the OS, driven by Microsoft), or failure rates for the older systems. And that's for the desktop side. For servers they tend to be taken out of…
Edit: a quick search yields a common core or division at Intel behind the ME and SPS, so that makes a bit of sense. There has been at least 1 exploit in the wild for that SPS, it also lists TXT and ME, so I guess it's a shared (MINIX?) kernel that had the bug.
Earlier quoted context omitted.
There are close to 5,000 devices exposing their Intel AMT to the Internet: https://www.shodan.io/report/j3cFHOzs
There are X thousand redis servers exposed to the Internet too. This is hardly intel’s fault (having the ports exposed, not the vulnerability). And again, this is not the main point I’m arguing. What I’m saying is that supposedly “this is something that’s enabled by default on consumer devices” is verifiably wrong.
And I was trying to address this point:
> Even then, every setup I’ve seen have AMT (a separate Ethernet interface) behind a firewall and is only accessible via local network.
In the past, manufacturers used that defense when a security researcher approached them about a problem and they justified the lack of patching by saying things like "nobody would put this on the Internet". There are simple things a manufacturer can do to encourage good security by the end-user (ex. showing a warning). I don't believe that blaming the end-user is a viable path to fixing the problem. This issue isn't specific to Intel but I would prefer it if the vendor implemented more security safeguards to prevent users from inadvertently increasing their attack surface.
I wonder, who ever uses these "management engines," let alone put them open on WANs? When first news of IME being compromised, I was surprised that Shodan showed such a small number of machines.
Earlier quoted context omitted.
More like 5 years, or even longer, where I work. We have some 7 year old Dell servers that are still chugging along, performing their duties as well as ever.
Usually the amortization of such systems is ~ 4 years. But many smaller companies choose to stay with the old systems a little longer, 5, or even 6 years lately. Simply because there is no push performance wise. The main motivation for upgrade is software support (usually for the OS, driven by Microsoft), or failure rates for the older systems. And that's for the desktop side. For servers they tend to be taken out of…
Or when the service contract expires or is too expensive to extend. You can't run a server of any importance without a service contract; it can be the difference between all the server's users and services being down for hours or a more than a week, and between IT management keeping their job for hours or longer.
I don't want a patch. I don't use that thing for anything. I want them to disable that thing by default! Leaving those backdoors open in older products should lead to a recall because the flaw was there all along.
As I understand it, ME is used to remotely control the processor like in a datacenter. If a datacenter is buying hundreds of thousands of these it makes sense to have it on by default so their people don't have to go in and turn anything on. As much as I recognize it as a vulnerability (to the extreme), it doesn't make sense to have it off by default. They should certainly support a way to _permanently_ disable it. I…
It's used to remotely manage almost all aspects of the computer; it's a parallel, out-of-band subsystem, complete with its own processor, memory and OS.
It's very useful for managing computers at scale and at physical distances. Imagine making changes to thousands of computers; manual, one-at-a-time, hands-on solutions are very inefficient and error-prone. Imagine a campus or office building where the average distance from the IT support office to the computer is 20 minutes. Staff can spend most of their time in transit: 20 minutes there, 10 minute fix, 20 minutes back. 80% of the IT labor budget is paying people to walk.
But I agree; there's no reason the computer's owners shouldn't have the power to disable it if they choose.
Earlier quoted context omitted.
Maybe someone could clarify some things, because I think the impression that I got from reading about this vulnerability is completely wrong. Isn't vPro just something in server hardware? At least the CPU, Mainboard and NIC all need to be certified/from Intel to support this? You could get the impression that every single computer with a Intel CPU is vulnerable to be hacked over the network. Which I really doubt. > I…
vPro/AMT is the "consumer"/workstation version, the server implementation is based on IPMI, but the ME is present on all systems, even those without vPro at all.