> Dennis Clarke wrote: >> In the article that you cite we see Ken Thompson talking about inserting >> a >> nasty bit of code into the login process. That would be a nifty trick to >> get away with but not something that would get past an open source >> project. Then again, gee, we did have that telnet issue a little while >> ago. >> >> > Sure, the nasty code would never make it into the Open Solaris code > base, however the code _could_ make it into a binary distribution by way > of an infected compiler, which I think is really to Ken's point. It > doesn't need to be in there, and yet it can still do its damage.
Okay, so let us play a little game here. Assume that the code for some binary named foo was foo.c. We also assume that there was a change to foo.c because of a change report or closed bug report ( named foo_doo_001 ) and thus we do actually expect the binary for foo to change. Indeed we can diff the sources and see that there was a change.[1] We compile foo.c and then perform the linking against the unchanged libs and we get a new foo with a new MD5 sum. All is well we think but you say that my resultant foo will have a different MD5 sig than someone elses foo because the compiler may be infected. Okay, I see the issue. Firstly we need to have some reference foo binary which is built by some controlled reference machine.[2] That foo binary and its MD5 sig ( assume we trust the process of digital signatures ) should provide some level of trust to us. No matter how I slice it I smell a rat. There are holes in this process that can allow security to be breeched. Now I see why the people at various government facilities refuse to get off their old Solaris 8 machines. Because they have them locked to a particular config and nothing gets patched or changed unless *everything* gets reviewed. Paranoia is a good thing there and there is probably a reward system for who is the most paranoid. At this point I put on my tin foil hat and switch to aes256-cbc cipher for my ssh sessions. :-) Dennis Clarke Blastwave.org [1] we have a system at Blastwave that allows us to track such things. I recently passed our new OpenSSL software packages through a battery of tests on everything from AMD64 to sun4m. Yes, I said sun4m and Solaris 8 there friend and it all works. However you still need to see that we did make some changes and we track that and publish it if you know how to use a browser : http://svn.blastwave.org/trac/changeset?old_path=csw%2Ftrunk%2Flib%2Fopenssl%2Ffiles%2Fchangelog.CSW&old=1450&new_path=csw%2Ftrunk%2Flib%2Fopenssl%2Ffiles%2Fchangelog.CSW&new=1459 or http://preview.tinyurl.com/3cxen6 or http://tinyurl.com/3cxen6 [2] I use four different reference machines at Blastwave that are either Solaris 8 or Solaris 10 with Studio 8 or Studio 10 or Studio 11 or our own build of GCC if necessary. No outside binaries are accepted. _______________________________________________ opensolaris-discuss mailing list [email protected]
