[NTLUG:Discuss] Hidden Malware in offshore products raises concerns

[Steve Baker]

Steve wrote:

> Since the Chinese government understands the issues, what is the U.S.
> official Linux distro and what makes it (and other domestic distros)
> more secure wrt malware than the non-official, foreign distros? Please
> tell us so we can tell our Suse and Mandrake friends why Lindows is the
> superior linux distribution if you're concerned about malware. 
> 
> What does compiling something yourself have to do with the risks of
> offshore programming? If a domestic programmer gives you customized,
> complex code with something malicious in it, and you don't have a
> process to check the code or don't want to, just compiling it yourself
> isn't going to diminish your risk profile.

What compiling it yourself does is to ensure that the binary you'll be running
corresponds to the source code you have (well - not necessarily - see below).
You could (in principle) look through all the source code for all the packages
you have to ensure that there was no nastiness in them - but if you then go and
run a binary that was *supposedly* compiled from those sources - then there is a
chance that someone at the distro manufacturer could have compiled the binaries
from a DIFFERENT set of sources.

IMHO, that's a small risk compared to the possibility that there is some
nasty code in the sources too.  With many, many millions of lines of code,
it's beyond the realms of possibility that someone could spot some cleverly
hidden virus/worm/whatever - even if it's right there in the source code.

Then, there is the possibility of a loophole like the one that Kernighan (IIRC)
proposed:

   1) Hack the sources of the C compiler so that it recognises when it is
      compiling the source code of the 'login' program - and inserts code
      at the appropriate place to allow anyone to log in as 'backdoor'
      without entering a password.

   2) Then, whenever the login program is compiled - even from legitimate,
      clean sources - it will have the backdoor hack in it.

   3) Also, change the C compiler so that it recognises when it's compiling
      itself - and inserts the hack at (1) and (3) into the compiled binary.

   4) Compile the compiler using itself - this generates a compiler which
      inserts the backdoor patches to both login and itself!

   5) Remove all the hacks from the compiler source code.

   6) Compile the clean compiler source using the binary you last generated.

   7) Ship the clean source code and the dirty binary.

 From this point onwards, the source code for the two hacks can be completely
removed from all sources everywhere - and the backdoor to 'login' will self-perpetuate.

Of course you could also put a hack like this into the file system code (whenever
you read the binary of the login program from disk - insert a backdoor - whenever
you write the binary of the file system code to disk - insert the backdoor)...how
about the kernel, the network code, etc, etc.

There is debate as to whether this has ever been tried - but the only way to be
sure that someone hasn't done this to you is to recompile the compiler (and the
filing system - and the text editor and...) using some other compiler than GCC.

So, if you could recompile your sources on (say) Microsoft Visual C - or the Intel
C compiler for Linux - you could be more assured of security - but still, there
will be a point at which you just have to trust *something*.

Are you also going to refuse to use CPU's and RAM chips not designed and manufactured
only by US citizens?   How do you know that the Taiwanese RAM chip you're using doesn't
recognise the binary pattern of the 'login' program and overwrite the code in such a way
as to insert a backdoor?  That would be a pretty simple thing to do in hardware - and you'd
NEVER find it.

For the ultra-paranoid, there is nothing short of designing your own computer, mining
your own silicon, compiling all the code by hand and keying it in on toggle switches.

>>Americans have little to no understanding of the risks and perils associated with people doing software offshore.
>
> How are these risks and perils radically different from using domestic
> programmers? Is there some consolation for being cracked by a domestic
> programmer instead of a foreign one? "Well, at least he wasn't Indian." 

Yes - like there are no idiots who are US citizens?  The place is neck-deep
in NeoNazi's, crazy religious nuts, people who believe that aliens will come
and collect them when they commit mass suicide.  You trust them to write your
code - but you don't trust me?  (I'm a British citizen).

The best security there can be is to open the source code to as many
people as possible - "Many eyes make for shallow bugs" - that works
for security too.

You cannot possibly examine all hundred million lines of code in a
typical Linux distro - you cannot possibly employ someone to do that
for you.  Your best chance is to have the 'community' continually looking
at the code in order to improve it - and hope they spot any malware
lurking in the sources while they are trying to understand it for some
other reason.

Compiling everything from source is pointless unless you are also going
to check every line of those sources.

I'm a British citizen - I guess I won't be working for OSSI anytime soon.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1 at airmail.net>    WorkEmail: <sjbaker at link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----