[mdlug-discuss] [mdlug] [Fwd: [opensuse-offtopic] And nowtheManchurianmicrochip]

[Ingles, Raymond]

> From: Aaron Kulkis
> >  The problem is, they also allegedly have aliens at Roswell. :->
> 
> That whole hoax was started in a book written by the same guy
> who sold another book starting the "Bermuda Triangle" nonsense.

 Precisely my point. Absent evidence, we have no reason to believe the
'secret proof'.

> But generally, the DOD isn't in the business of fooling itself
> into spending a lot more for equipment than what it's currently
> paying.
> 
> If this is a lie...what's in it for the DOD?  NOTHING.

 If you'll read what I wrote, the security flaws don't need to be
anywhere near the level the article claims to still justify procuring
domestically-produced equipment for high-security needs. And, yes, there
*are* such things as conflicts of interest; many's the DoD official who
gets to 'retire' into a nice, high-paying job with a military
contractor.

 If you'll look below, I'm not saying this is the only thing going on...
but even soldiers are human, and humans are... unreliable.

> >  Like I said, a full "call home" module - particularly on multiple
> > platforms - would require nigh-miraculous levels of engineering
skill.
> 
> Or just burying it in the BIOS, and using the magic of DMA
> to move data off of the disk drive and out the network.

 Modern OS's don't *use* the BIOS for anything but initial boot. If you
make such a patch as simple as possible, and just dump RAM out the
network, you're in trouble. The machine I'm typing this on now, and my
main machine at home, have 2GB of RAM. You're going to sneak *that* out
the network, even with compression? Much less modern disks that *start*
at 120GB and can easily be as much as half a terabyte apiece?

 If you make the 'call-home module' more precise, you have to add quite
a bit more smarts to it. That means increasing both the size and the
complexity. The size makes it more difficult to hide, the complexity
makes bugs exponentially more likely, and bugs make it much more
noticeable. You also have to avoid interfering with the
currently-running OS, which makes heavy use of DMA, too.

> > *That's* what I doubt, strongly. Relatively slight fudges of
hardware to
> > defeat memory protection seem much more within the realm of
possibility,
> > and would still be of major concern. The good news is that modern
> > processors have a surprising amount of flexibility in their
microcode,
> > and can often be 'patched' to work around flaws.
> 
> You're focusing on one chip.
> What they're talking about is the entire system.

 Distributing the security flaws among several different parts of the
system makes it even worse. Let's assume the minimum set that would make
this anything *like* technically feasible - changes to the CPU, the DMA
chipset, and the NIC. That's three different components, each one of
which has to be present on the same system to make it work. Then the
changes need to be made compatible between different modules, and
*steppings* of modules. (I.e. you need to have CPU A (steppings 1,2, or
3) or CPU B (steppings 2 or 3), DMA chipsets D, E, F, or G (with
associated steppings) and NIC types H, I, or J (with associated hardware
revs). (One of your malicious changes is in the CPU's internal bus, and
the new revs the designer just sent you invalidates your work. You have
to scramble to find a compatible change you can hide, or any time
someone tries to invoke your secret module, the CPU locks up. Or what if
you've hinged your function on a previously invalid CPU state, but the
new rev makes it valid - how do you tell the other parts of the secret
system not to try any funny business?)

 Now, they all have to be present, and compatible with each other. You'd
better not make *any* mistakes or you'll crash the system, not dump the
data. You can't interfere with what the OS is doing at the same time, or
again you'll crash the system.

 Umm... no. I don't buy it.

 Not when it's simpler to put a flaw in the CPU's MMU or the DMA chipset
that, when presented with an unusual and nominally invalid input,
temporarily switches off memory protection. Then any kind of software
running on the system can jump through the magic hoop and subvert the
OS, at which point they can make the OS work for *them* and more
effectively hide their traces. They can use the OS's own information to
help filter what data is useful, and just send that, particularly when
they know there won't be other legitimate activity going on that might
be interrupted.

 Again, I'm not saying there's no threat. I *am* saying that the
specific type of threat described in the article is... questionable.

 Sincerely,

 Ray Ingles                                           (313) 227-2317

 "I would rather be exposed to the inconveniences attending too much
       liberty than those attending too small a degree of it."
                       - Thomas Jefferson
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.