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

[Aaron Kulkis]

Ingles, Raymond wrote:
>> 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'.
> 

The Air Force never said there were aliens...it was some
nut job creating hoaxes to sell his nutty books.

>> 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.
> 

We're talking off-the-shelf Intel/AMD machines.
COTS (Commercial, off-the-shelf) equipment is specifically
prohibited from being channeled to certain vendors, as long
as they meet the specs.  That would be like telling the
Navy they can only purchase rope from one vendor.

>  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.
>

If you put a sniffer on a network, and data is being sent
out on that network for no reason at all, you KNOW you've
got a problem some place.

>>>  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?

Who knows.  But China has been pursuing cyber-network warfare
for over 10 years - I first heard about that threat back in
the mid-1990's, and at the time, I thought it to be a rather
preposterous idea.  But then I heard about the trojaned-printer
that was sent to Hussein's government, and the outbreak of
viruses, and I realized that the security I had taken for
granted on Unix and VM/CMS was far from common.
> 
>  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.

No, you don't need to make any such avoidance at all.
Since the machine has been penetrated since before an OS
was even installed on it, there's no sudden, noticeable
decrease in performance of the machine.
And besides, Disk bandwidth compared to memory bandwidth
is low... the whole reason for DMA controllers is so that
the data can be sent in burst mode, so as to free up
the memory bus.

> 
>>> *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.
>

You also buy the idea that lowering taxes improves the economy,
and increases employment, despite a few hundred years of data
which shows that it always works without fail.

>  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