

Intel processor microcode security update - sehugg
http://lists.debian.org/debian-user/2013/09/msg00126.html

======
GICodeWarrior
Intel releases new microcode relatively frequently.

There appear to be about 13 microcode updates for the i7 since launch.

[https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&...](https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Processors&ProductLine=Desktop&ProductProduct=Intel%C2%AE+Core%E2%84%A2+i7+Desktop+Processor&ProdId=3426&LineId=3004&FamilyId=24)

If I understand correctly, most of the updates are designed to fix bugs
related to surrounding hardware (motherboards, memory).

If you look at the BIOS updates for your computer/motherboard, you might
notice notes about microcode updates. The BIOS can apply these just as easily
as the OS, and when they are hardware compatibility issues, that is the only
way for it to work.

Not every update makes it into a BIOS version for every board, and not every
version makes it into a Windows update (AFAIK).

~~~
zurn
This addesses a real vuln though, "classified by Intel as a security issue,
that affects any server running 32-bit VMs in PAE mode"

------
comex
What I'd give to see a textual diff of the source code to that microcode
update (which is, for the record, encrypted and signed).

~~~
4ad
The microassembly means nothing unless you have the full schematics of the
CPU.

------
sounds
More information about the bug:

[https://launchpad.net/debian/+source/intel-
microcode/1.20130...](https://launchpad.net/debian/+source/intel-
microcode/1.20130808.2)

[https://bugs.launchpad.net/intel/+bug/1212497](https://bugs.launchpad.net/intel/+bug/1212497)

Intel.com link for downloading the raw microcode update:
[https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&Dwnl...](https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23082)

------
superkuh
[http://inertiawar.com/microcode/](http://inertiawar.com/microcode/) provides
a good background summary of microcode on AMD/Intel CPU in general.

------
oakwhiz
I don't understand why this would be the case:

    
    
      3. It recently came to my attention that this microcode update might forbid
      unsupported (by Intel) overclocking on 4th gen Core "K" processors installed
      on motherboards that lack a Z-series chipset.

~~~
simcop2387
Following some of the links in the mail thread[1] it sounds like intel only
allows it on the Z series chipsets for various reasons. And some mother board
manufacturers have been enabling it on the sly to let people without them to
do some amount of overclocking.

[1] [http://www.bit-tech.net/news/hardware/2013/07/25/intel-
overc...](http://www.bit-tech.net/news/hardware/2013/07/25/intel-overclocking-
block/1)

~~~
yuhong
I wonder how does it detect the chipset being used.

~~~
4ad
It's in the CPU which is connected to the physical memory. Detecting the
chipset is as trivial as reading a few bytes from the memory.

------
ck2
I wonder if this will make it to Redhat/CentOS and how long it will take.

~~~
BuildTheRobots
I got a CentOS announcement this morning in my email, so it should already be
there:

[https://rhn.redhat.com/errata/RHEA-2013-1202.html](https://rhn.redhat.com/errata/RHEA-2013-1202.html)

------
andyzweb
>implying this isn't a new patch from the NSA

~~~
bastawhiz
The NSA would have to be damn slick to fit any kind of spying tool into a CPU
bitcode update. The CPU doesn't know what the code that it's running does or
what the data that it's handling is. It would need to set aside memory to do
pattern matching on the code/data being processed to introduce any kind of
back door. Then, it would need to hide the back door so nobody notices, which
would potentially involve huge amounts of code to disguise the fact that the
data has been modified.

An example of an attack would be for the NSA to muck with random number
generation to bias it towards certain values in a very subtle way. That would
mean that encryption would be less strong, since the total number of possible
values needed to brute force is lower. This would be difficult to hide: if
they attacked say, RdRand, anyone using/researching RdRand would be able to
see that it's no longer NIST/FIPS/ANSI compliant. They would need to attack it
such that the back door was only open when nobody was looking (when there's
not a very large number of those commands being run, or when the command is
part of a larger piece of code). Even then, anyone studying the final output
from the affected code could potentially determine that the random number
source was biased.

Either way, I'd think that an attack like this would be pretty damn hard to
pull off, and Intel has very little reason to help the NSA with that. Can you
imagine if it was found out that Intel was helping the NSA by weakening
encryption? Everyone would go out and buy an AMD machine.

~~~
Someone
Would it be that hard? I would think of:

\- snoop the instructions being read.

\- continuously compute a CRC from those bytes, resetting the CRC to zero when
encountering a magic value, say when encountering a jump instruction.

\- whenever the CRC hits some magic number, shortcut the random number
generator to return a few hundred zeroes.

Alternatively, one can have a similar circuit attempting to detect the
password checking code, and have the first code set a 'please let the next
password comparison instruction succeed' flag. The two circuits even could be
the same: for a given sequence of 'check password' instructions, it is easy to
make the hardware or microcode handle some special password as a universal
key.

And yes, that is 'for a given sequence of instructions', but those won't
change that often in popular OSes, and you can always issue a microcode update
if, say, a service pack, security update or compiler change changes that
sequence.

Tinfoil hat of: I think Intel could easily do something like that, but I doubt
they do. Some day, somebody will reverse engineer that CPU, notice a small,
weirdly connected part and get curious as to what it is doing.

~~~
bastawhiz
I realize I'm a bit late on the reply, but a few thoughts:

\- CRC would easily encounter a collision within the first few minutes (at the
most) of running any arbitrary code (your operating system, for instance).
You'd need something much longer and less prone to errors, like SHA. Otherwise
you'd be getting lots of weird problems as the CPU triggers the backdoor
constantly. \- More complex hashing would take more memory and lots of CPU
time, something that would doubtfully be available to at the microcode level.
If every instruction computed a non-trivial hash, someone would quickly notice
performance issues ;) \- Shorting the RNG would produce some very suspicious
results, and anyone looking at any kind of fuzzed tests, testing encryption
strength, or running tests against something like OpenSSL would quickly
discover the backdoor. \- Any kind of "the next comparison is always true"
would easily trip even the most basic of unit tests, and it would happen every
time. Making it only happen randomly might help, but would likely still be
found relatively quickly.

------
RachelF
So what bug has Intel fixed?

~~~
adestefan
Did you read the link?

1\. It fixes a critical erratum, classified by Intel as a security issue, that
affects any server running 32-bit VMs in PAE mode.

    
    
        Erratum AAK167/BT248: "If a logical processor has EPT (Extended Page
        Tables) enabled, is using 32-bit PAE paging, and accesses the
        virtual-APIC page then a complex sequence of internal processor
        micro-architectural events may cause an incorrect address translation or
        machine check on either logical processor.  This erratum may result in
        unexpected faults, an uncorrectable TLB error logged in
        IA32_MCI_STATUS.MCACOD bits [15:0], a guest or hypervisor crash, or
        other unpredictable system behavior"

