I'd very much not bet on this being the only or the last bug. See it more as a confirmation that this system is not as secure as they thought it was and that will cause a lot of people to now be encouraged to look at it closer.

> confirmation that this system is not as secure as they thought it was

I wonder if that's true. Intel has many smart security professionals working for it, and probably they expected there would be exploits; they exist on every system. I'm reading a book about Intel Management Engine (the independent subsystem on which includes AMT runs) by an Intel engineer[0], and they are clear that their model mitigates risk but nowhere do they say that it's invulnerable. In fact, they include responses to exploits in their discussion of their security process.

It's as secure as I thought it was; of course there are some vulnerabilities. The real issue to me is how effectively they mitigate it.

[0] Highly recommended to learn about ME and AMT: Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine by Xiaoyu Ruan, published by Apress (2014)

Systems like this ought to really be bullet-proof. You can do all you want to secure the other layers (the ones that you have regular access to), this one bypasses all of that and gives an attacker the equivalent of physical access to the hardware. To me that's a level above the kind of flaw that can be attributed to faulty system administration, operating system or application bugs.

It's essentially a monkey riding along on your shoulder that suddenly turns out to be malicious.

To me these systems are accidents waiting to happen. And this won't be the last bug either, you can bet that AMT and ME will receive a lot more hostile attention than they got so far in the next coming months.

Some of their competition have gone through the trouble to create or buy high-assurance security for such purposes optionally with the code written in languages like SPARK provably immune to errors hackers go after w/out runtimes. This approach goes back to the 70's-80's with modern tools super easy and cost-effective. I mean, a handful of people at ETH made the Muen separation kernel with a similar handful doing a high-assurance VPN at Navy Research Laboratory. There's companies that would do it for them with whatever mix of robust or complex they want.

They just don't give a shit. Like you said, systems like this ought to be bulletproof. I'll add it's especially true when they're in most of the products of a company making hundreds of millions to billions off them. Even small-to-midsized firms are doing medium to high assurance designs. I'm sure Intel could afford it. ;)

Do their customers want high-assurance? As I posted elsewhere, corporate IT is sophisticated enough to know the risks, and they chose to enable AMT widely. Does the level of demand make it profitable enough to justify doing? Personally I would pay a good amount for high-assurance systems - or even subsystems, as in this case - but my budget isn't unlimited. More than a small cost would be hard to sell to management, which as we all know often budgets little attention to security, much less money.

OTOH, there is a good argument that vendors know the risks much better than their customers can, and that they have a responsibility to protect their customers from dangerous options. But even that depends on the cost; everything can be made safer for greater expense. I wonder if this qualifies.

"Do their customers want high-assurance?"

Their customers prefer highly-privileged code not get hacked vs get hacked. Intel knows their dominant position with lockin to x86 code lets them ignore customers' preferences if they deliver something useful. It's an oligopoly effect.

It's actually AMD I normally suggest should compete on flexibility or security. They need the money more. ;)

> Their customers prefer ...

Sure they prefer it. I prefer a soup-to-nuts high-assurance personal laptop, or a private 747, but I'm not willing to pay for them. I know my laptop can be exploited. My point is that it's an economic question, not one of technical specifications.

> Intel knows their dominant position with lockin to x86 code lets them ignore customers' preferences if they deliver something useful. It's an oligopoly effect.

To a degree. Customer could use their TPMs for many of the same functions as ME, or get third party devices for out-of-band remote control like AMT. Intel just needs to make it good enough, but that's the 'intentional', so to speak, design of marketplaces.

I would love it if AMD took the opportunity, and security became a competitive arms race between them.

It is economic issue. Unfortunately, the incentives work against it on supply side since they maximize profit even to detriment of users. The oligopolies universally supply garbage that suits them. If it's quality or security, customers often just get used to the problems. That lowers demand side. Differentiating firms can show up but will be niche unless latching onto something big. I thought about Java, C#, or Go CPU's at one poing for application servers. Different front end with safety/security checks on top of high-performance design probably. Can't be sure on economics of it, though.

If they expected exploits, then they knowingly sold their systems with their own little private rootkit that was exploitable.

The intel management engine has and continues to be a security threat. And now everyone can see it.

> they knowingly sold their systems

Everyone who sells systems knowingly sells exploitable ones, unless the sellers are naive. Every system you and I deliver to our customers/users is exploitable.

And knowing that I'd never be naive enough to embed it in every CPU I made since 2009. Not to mention allowing AMT to exploited even when it's disabled, and not share the source code so it could be properly audited. Every decision Intel made points to either them thinking this system was bulletproof (at least at the upper decision making levels) or they're so incompetent they shouldn't be trusted with anyone's security.

Corporate IT seems to disagree. Certainly they are sophisticated enough to know the risks, and they enable and use AMT widely.

Personally, I hesitate more than most because of the technical reasons you cite, but even turning on a computer is a risk. Probably this isn't the greatest risk to a business' IT.

As somebody who consults with Corporate IT, more often then not I run into the mindset "well if every other company is taking on the same risk then it's a wash". Aka disabling SELinux is what everybody does, we aren't taking on any more risk than anybody else (and it'll make us more competitive because we can iterate faster), so why not? Very few companies think of security as a feature, because so few consumers think of security as a feature.

I agree completely, many many companies are totally fine with accepting that risk due to the trade-off for ease of manageability. But I'm really not, in no small part because the overhead to managing a few computers is totally different than a large corporation with thousands of machines. I just wish my vote counted to Intel (or AMD for that matter), and I could completely disable ME because I'd rather the more difficult management of machines over the much larger attack surface.

Of course it all seems to lead back to monopolies/duopolies being bad for the average consumer. Who knew?

I agree on all points; well-made. Thanks.

> I just wish ... I could completely disable ME

You might find this useful:

https://puri.sm/learn/avoiding-intel-amt/

I stumbled upon puri.sm in an old reddit thread talking about this, I'm very intrigued by the systems they make. Also it seems disabling ME might be possible, though risky: https://hardenedlinux.github.io/firmware/2016/11/17/neutrali...

This is exactly right. Almost every company sees security simply as a cost.

This strikes me as an odd argument. Corporate America is notorious for not taking security seriously until it is too late. If you care at all about security you shouldn't take advice from what corporate IT is doing.

Is this "the last bug?" You can't know that.

I'd wager we haven't seen the last bug yet, if ever.