Re: A quote from Crypto-Gram

From: David Eather (eather_at_tpg.com.au)
Date: 08/22/04 

Date: Sun, 22 Aug 2004 22:41:42 +1000

Joris Dobbelsteen wrote:
> "David Eather" <eather@tpg.com.au> wrote in message
> news:412562d7@dnews.tpgi.com.au...
>> Tim Smith wrote:
>>> On 2004-08-19, David Eather <eather@tpg.com.au> wrote:
>>>>> How about a backdoor that lets an application read/write any
>>>>> memory location? Or that lets it access any I/O port?
>>>>
>>>> It *can't* be done. It seems that the role and scope of microcode
>>>> is The most you could do is write a malicious instruction. For
>>>> example one
>>>
>>> Yeah, like a malicious instruction that allows peeking at arbitrary
>>> physical memory without any access checks, or a malicious
>>> instruction that switches from user mode to kernel mode.
>>>
>>> ...
>>>> Even so, having succeeded in creating such an instruction you can't
>>>> deliver your "payload" - as no main boards provide the necessary
>>>> hardware support to update the CPU microcode.
>>>
>>> Pentium Pro, PII, PIII, P4, Celeron, Xeon, etc., all provide the
>>> necessary support for updating microcode. Same for modern AMD
>>> processors. No main board support is needed.
>>
>> I don't think that can be correct . It is very normal for
>> programming modes to controlled by a hardware input.
>
> The eZ8 laying here and the can be programmed through the hardware or
> using software. Both ways use the same circuitry, better the hardware
> (on-chip debugger) can write to the hardware same as the software
> would do.
>
>> The alternative, which you suggest, is to allow programming after the
>> correct software instruction. There is only one company this
>> irresponsible and they do not make microprocessors. Controlling
>> programming by software only means every random event or power
>> fluctuation, pulse, spike or dropout could trigger your PC into
>> programming mode and ruin the CPU - that this doesn't happen is
>> testimony that "software control" is not the case.
>
> This is based on nothing. I don't believe you have the proper
> knowledge of hardware to assume this, or do you?
>
> Even cheap microprocessors like Microchip's PIC and Zilog's have good
> protection against this (brown-out protection and startup delays).
> How else would you be able to start a circuit in a predefined state?
>
> Besides, when you look at a PC, there is a lot of work into preventing
> voltage drops (ever noticed the growing number of capacitors?), even
> your power supply has some buffers to keep the voltage level correct.
>
>> Also, does anyone think it would take 10 years for malicious
>> hackers/virus makers to realise that they could drop a destructive
>> payload on Pentium Pro or PII processors. It took only a mater of
>> months for them to work out that flash upgradeable BIOS was
>> vulnerable.
>
> Don't bet on that, everybody knows. Its only out of reach for a common
> hacker/virus maker to begin altering the microcode. They don't have
> access to the sources that allow this. Large companies and goverments
> have that power, but they don't spill it for fun...
>
> Of course, the BIOS demanded only simple means that are widely
> accessible and documented. Everybody had access on how to program a
> BIOS (or you just look at the program you get supplied).
> Why you think all those DVD drives have their firmware patched.
>
>> I'll eat my words if you can show me a data book that says you can
>> reprogram microcode in i86 or AMD processors via software only but
>> the odds are stacked against you.
>
> Please check out
> Intel document 25366813
> "IA-32 Intel® Architecture Software Developer's Manual, Volume 3:
> System Programming Guide"
> ftp://download.intel.com/design/Pentium4/manuals/25366814.pdf
> (2.55 MB, .pdf)
>
> Check out chapter 9.11 "Microcode Update Facilities".
> The update is triggered by a WRMSR (Write Machine-Specific Register),
> with the correct parameters (MSR register and pointer to update
> structure).
>
> It is a priviledges instruction (so you must be the kernel/driver or
> before the kernel).
>
> - Joris

Humble pie is difficult to eat - thank you for your patience.

You are fully correct and I am wrong. "The update is triggered by a WRMSR
(Write Machine-Specific Register)" - no external hardware involved. Intel
has made microcode updateable with software only. Perhaps this was is a
knee jerk reaction to the recall costs and bad publicity of the floating
point division error in early Pentiums?

The link you gave (
ftp://download.intel.com/design/Pentium4/manuals/25366814.pdf ) also answers
some questions (section 9) on the file format of this update "facility" and
section 9.11.6.1 mentions that the update is kept in ram and lost after a
hard reset (for P4's).

As an open question does anyone have an estimate of how nasty this
vulnerability could be?

Is the worst that could be done is to replace the microcode data (random
data would do if the encryption proves effective), crash the computer and
perhaps damage the CPU? A major step up in cyber vandalism and perhaps a
worst case scenario if implemented with an effective virus or worm.

David Eather

There was also a thread where their was speculation I had "fallen of my
tricycle". No, but I had an old data definition. "Microcode" meant the
hardware/firmware that defined the function and execution of the machine
level code. Calling a "microcode patch" or "microcode update" just
"microcode" did not pass the correct meaning to me - a split hair perhaps,
but no one calls a "BIOS flash update" (or similar) the "BIOS", or "cipher
text" the "plain text", even though they are related things. You can see
why with that definition "microcode" can't be meaningfully encrypted - it is
inside the CPU. Of course any file containing data for download could be
encrypted if the CPU supports the decryption - Xilink does this with its
FPGA.

Thanks

Relevant Pages

  • Re: A quote from Crypto-Gram
    ... >> physical memory without any access checks, or a malicious instruction ... The eZ8 laying here and the can be programmed through the hardware or using ... Controlling programming by software ... hacker/virus maker to begin altering the microcode. ...
    (sci.crypt)
  • Re: A quote from Crypto-Gram
    ... >> programming modes to controlled by a hardware input. ... Controlling ... the BIOS demanded only simple means that are widely ...
    (sci.crypt)
  • Re: Update: The use of the SX processor instead of a Basic Stamp
    ... a custom game based on the same hardware. ... guys went through with the custom AC/DC project. ... leave the computer for programming:). ...
    (rec.games.pinball)
  • Re: brain thoughts
    ... in clever programming. ... algorithms, ... re-building physical hardware. ... simple logic circuits anymore and make then run as fast. ...
    (comp.ai.philosophy)
  • Re: Open Source Enhancement
    ... Perhaps high-level programming markup language? ... crappy software that requires new hardware that then requires more ... time to integrate, create drivers for, etc., just so people can write ... writing drivers for hardware from companies that release no hardware ...
    (comp.unix.bsd.openbsd.misc)