... and embedded in ATMs with a 20 year life span.

Your comment sounds a bit dismissive of the vulnerability with an implication that it would never be a problem. If that was not what you were implying I apologize. It is critical that even "old" chips vulnerabilities be understood so that one can understand the risks. It pains me terribly every time I power up the Agilent signal analyzer in the lab and it boots Windows XP on its Pentium III chip.

I wonder if any of these chips ended up in electronic voting machines?

That is one place you don't need hacking CPUs to hack the result. Plain files vetted by no one etc etc.

I would not be surprised, it was one of the earlier low TDP but x86 compatible chips.

> ... and embedded in ATMs with a 20 year life span.

Privilege escalation is not a problem on ATMs.

> It pains me terribly every time I power up the Agilent signal analyzer in the lab and it boots Windows XP on its Pentium III chip.

Why? Just treat it as you do most hardware, under full control of whatever you attach it to. Zero security present, zero security needed.

> Privilege escalation is not a problem on ATMs.

https://vuldb.com/?id.79002

I expect that most people miss that ATM manufacturers continue to put security holes in ATMs (https://www.wired.com/2014/11/nashville/) one of the 'fixes' was to make bank access unprivileged. But wait, if I have an escalation vulnerability ...

Sigh. Okay let me rephrase. The thing normally called "privilege escalation", where software that is executing on a machine escapes a sandbox or gets into kernel mode, is not a problem on ATMs.

That page is talking about pressing keys to exploit software flaws in already-privileged software, which is an extremely separate topic.

Privilege escalations come in many shapes and sizes, it is not limited to software escaping a sandbox or to get into kernel mode, it is also explicitly used to refer to users of a system managing to leverage their normal access into a more powerful one.

But in context I was clearly talking about the former, because the topic is software exploiting CPU backdoors.

This can be combined with another exploit that allows the user to execute user code to achieve root on the ATM, so it's still troubling.

I don’t think these ATMs run a lot of untrusted code, and this is of course easily patched by clearing the bit during the boot sequence.

It would be much more of a problem if these were consumer machines running untrusted code.

I don't think minimizing the significance of the exploit should happen in the headline, but saying "x86 CPUs" instead of "Via CPUs" in the headline is very clickbaity.

"Via x86 CPUs" would be perfect. It conveys detailed information to those with detailed knowledge while still being understandable to those less familiar with tertiary cpu manufacturers.

Still, the consequences are huge. Also, how can we be sure something similar isn't implemented in modern CPUs?

This is absolutely implemented in modern CPUs, as debug or management features. Usually switched off - being able to turn it on from ring 3 would be a massive bug.