Path: utzoo!attcan!uunet!husc6!bloom-beacon!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!ucsdhub!sdcsvax!ucsd!ucbvax!agate!garnet!weemba From: weemba@garnet.berkeley.edu (Obnoxious Math Grad Student) Newsgroups: news.admin Subject: Re: Malicious posting worries Message-ID: <11589@agate.BERKELEY.EDU> Date: 2 Jul 88 17:14:35 GMT References: <266@octopus.UUCP> <11518@agate.BERKELEY.EDU> <271@octopus.UUCP> Sender: usenet@agate.BERKELEY.EDU Reply-To: weemba@garnet.berkeley.edu (Obnoxious Math Grad Student) Organization: Brahms Gang Posting Central Lines: 89 In-reply-to: pete@octopus.UUCP (Pete Holzmann) I really have no opinion about binaries on the net. Nor am I trying to lecture Pete on what risks *he* should take. Just trying to clarify certain legitimate differences. In article <271@octopus.UUCP>, pete@octopus (Pete Holzmann) writes: >>One can, however, scan source code for inordinately complicated monkey- >>shines, comments that don't appear to match code, etc. >>I cannot do this with *any* "short little" binaries. > >I certainly can! The equivalent to quickly scanning a source program, >is to try out a binary in a controlled environment. That's not much of an equivalent. The quick scans I referred to were not trivially quick; I can read C or ELisp as if they were almost natural languages when the code is well-written, and without too much difficulty in general. A more accurate comparison would be between binaries and the Obfuscated C contest entries. I even had a RISKS submission on this: the Makefile I received was buggy, so I had to fix it, and as they were producing bi- naries named after the winners, I had Larry Wall's entry create "wall". As in wall(1). > Your example illustrates >my point perfectly: the best we (even experienced, careful people) do with >source code, is to take a quick look, then trust. And if the code is too >big to scan completely, we base our trust on the origins of the program. You are correct that trust must enter the system somewhere. Ritchie's famous Turing award lecture--the one about Trojan horses in a compiler binary that always compiles itself back in--demonstrated this. I have mucho faith in AT&T and UCB and SUN as basically trustworthy sources --they have so much at stake, and have proven reliable in the past. They may make mistakes, and release software that bad guys can use to violate security with, but their software is not directly hostile. What I don't trust are the Joe Blows on the net whom I've never heard of, with a neat-o sounding little programs. >They *could* come from anywhere, but they shouldn't. Just as you would >trust a source program tested and posted by one of the net's esteemed >source code moderators, I do, but I still give such things a semi-read-through before using. Again, most of the stuff I personally grab is *small*: 1K-30K. I can verify these to my heart's content. I cannot do this with a *small* binary. >>[suggests giving byte count of compressed tar file for major source >> postings, perhaps in concert with public encryption. Maybe standardized >> "Key:" headers on postings] >>This could guarantee author's responsibility for source code funny busi- >>ness, but it wouldn't mean beans for binaries. >Why not? The exact same argument applies to binaries, No!! If Billy Binary compiles his binary with an infected compiler, a virus could spread via Usenet, without Billy's knowledge or intent. En- crypting won't protect him. What happens with source is that the risk of infection from bad compilers rests squarely with the end user. > and I like the >concept in general: discouraging people from playing around with compressed >tar files is *exactly* the same problem as discouraging people from playing >with compressed binary files [except it is harder for people to modify a >posted binary!]. Note that while tar and compress could have a virus in them--say to tar in an extra something--yet such would have to produce something notice- able in the end *source* product. >And ensuring "author's responsibility" is entirely appropriate for binary >postings, as it is with source code. This is a rule that makes sense for >the net. [I don't mean responsibility in a legal sense. Just that we >need trustworthy assurances that we are getting what the author intended >we get, and we know where to find the author if something is wrong (or >right!)] How about "author's reliability"? >PS: Weemba, I must congratulate you on posting a message completely lacking > obnoxiousness in this group! [There, now I've done it. Sigh. :-)] Heck, mistakes happen. I'm not exactly perfect. ucbvax!garnet!weemba Matthew P Wiener/Brahms Gang/Berkeley CA 94720