Live data from Hacker News

CPU Backdoors

danluu.com

11–20 of 51 posts

Re: CPU Backdoors

#11
post #4
post #2

Wow..light involved in the lithography process causes wear on the lenses? To what degree?

Yes - just saw that too. Anyone else able to supply more information on what is going on there? That seems un-possible, but i'm no physicist

It's not just any light, it's pretty serious deep ultraviolet lasers. (one quick google was showing 60-90W pulsed @6khz lasers @ ~200nm wavelength.)

Stuff degrades in UV light, and that laser is going to be far brighter than you would have ordinary experience with.

Re: CPU Backdoors

#12
post #9

While the main point of the article is interesting, some of the details don't really make sense. For example, it would be difficult to make an instruction like fyl2x or fadd cause a privilege level change. The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder. This unit would not have the means to communicate back information such as "change privilege level"…

> "magic values"

Actually you can make something that checks for a magic value without encoding the magic value in the microcode. Triggering a buffer overrun in software often requires very particular inputs, but those inputs are not explicitly encoded in the binary. If you were clever, you could make microcode that looks correct, but backdoors under the right conditions.

Re: CPU Backdoors

#13
An obvious place for a backdoor is in remote management CPUs embedded in the network card.

http://www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.pdf

Network cards which support RMCP/IPMI protocol are obvious points of attack. They can reboot machines, download boot images, install a new OS, patch memory, emulate a local console, and control the entire machine. CERT has some warnings:

https://www.us-cert.gov/ncas/alerts/TA13-207A

If there's a default password in a network card, that's a backdoor. Here's a list of the default passwords for many common systems:

https://community.rapid7.com/community/metasploit/blog/2013/...

"admin/admin" is popular.

The network card stores passwords in non-volatile memory. If anyone in the supply chain gets hold of the network card briefly, they can add a backdoor by plugging the card into a chassis for power, connecting a network cable, and adding a extra user/password of their own using Linux "ipmitool" running on another machine. The card, when delivered to the end user, now has a backdoor installed. If you have any servers you're responsible for, try connecting with IPMI and do a "list" command to see what users are configured. If you find any you didn't put there, big problem.

CERT warns that, if you use the same userid/password for multiple machines in your data center, discarded boards contain that password. So discarded boards must be shredded.

Re: CPU Backdoors

#14
post #9

While the main point of the article is interesting, some of the details don't really make sense. For example, it would be difficult to make an instruction like fyl2x or fadd cause a privilege level change. The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder. This unit would not have the means to communicate back information such as "change privilege level"…

The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder.

I don't think that has been true for a very long time.

If the backdoor depends on some "magic values", it would be relatively easy to spot just by looking at the microcode.

The problem with both your theory and the article's theory is that nobody outside the chip companies themselves really knows how the microcode works. This reduces both the people who could pull off such a backdoor and the people who could discover it to a very small number.

A similar thing applies to your point about changes during manufacturing.

Overall, this means that CPU backdoors are a thing to be concerned about, keeping in mind that it's probably a technique that will, for a long time, be limited to the kind of people who were responsible for Stuxnet.

Re: CPU Backdoors

#16
post #9

While the main point of the article is interesting, some of the details don't really make sense. For example, it would be difficult to make an instruction like fyl2x or fadd cause a privilege level change. The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder. This unit would not have the means to communicate back information such as "change privilege level"…

The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder. I don't think that has been true for a very long time. If the backdoor depends on some "magic values", it would be relatively easy to spot just by looking at the microcode. The problem with both your theory and the article's theory is that nobody outside the chip companies themselves really knows how the…

I don't think that has been true

In support of that: http://www.xbitlabs.com/images/news/2009-11/amd_bulldozer_sc...

Re: CPU Backdoors

#17
post #6
post #2

Wow..light involved in the lithography process causes wear on the lenses? To what degree?

This video, mentioned here, from HOPE, is amazing: https://m.youtube.com/watch?v=NGFhc8R_uO4

and here is the direct link to the part about the wear on the lenses:

http://youtu.be/NGFhc8R_uO4?t=12m32s

Re: CPU Backdoors

#18
post #4

Earlier quoted context omitted.

Yes - just saw that too. Anyone else able to supply more information on what is going on there? That seems un-possible, but i'm no physicist

It's not just any light, it's pretty serious deep ultraviolet lasers. (one quick google was showing 60-90W pulsed @6khz lasers @ ~200nm wavelength.) Stuff degrades in UV light, and that laser is going to be far brighter than you would have ordinary experience with.

[deleted]
Post reply on HN