pete@octopus.UUCP (Pete Holzmann) (06/30/88)
[This is a second article responding to Rich K's article about distribution worries on the net.] >While there are several ways to distinguish these, the one that I tend >to focus on first is oft-discussed notion that binaries are easily >booby-trapped, while sources are not. Actually, *postings* of *either* can be easily booby-trapped. Maybe I'm nit-picking, but we need to deal with reality here. Theoretically speaking, it is true that a booby trap can be better *hidden* in a binary than elsewhere. Practically speaking: 1) Booby traps are extremely rare. As far as I know, no posting in ANY binary or source group has ever been booby trapped. Not even a simple killer rm in a shar! Fear of computer infection may make me paranoid, but sendsys floods are a much more real problem. 2) Nobody has the time or willingness to truly analyze every program (binary OR source) posted to the net for booby traps. The best we can do is practical testing. "I've compiled and run this. It seems to work fine." That's what you see on the source groups. At least when I first get a PC binary, I run it on a system with RAM disk only, nothing else connected that can be trashed. If someone were to send a source moderator a well-hidden booby trap inside a big, supposedly safe, program, I'll bet the moderator would test it, find it 'works', post it to the net, and it could be in use in lots of places within a few months. Suppose that a new smail version were well boobied? News 3.0? A time-delay trap could be hidden in the source code, and a LOT of people could get hurt. BUT THAT'S JUST THEORETICAL. Practically speaking, I'm not too worried. >I have no particular desire to disenfranchise microcomputer users; >however, I have no particular desire to assist in the demise of >their software and data holdings by being a party to the distribution >of binary programs of a malicious nature. Please let THEM worry about that. You are not going to be held accountable if a 'malicious' posting (binary OR source) is posted to the net. If it ever happens, I'm sure that the all-out search for the offending party, and ensuing nuclear flamefest, will break all records :-). >Further, I note that >distinguishing between malicious and non-malicious binary programs >is a problem that poses difficulties even for experts in the field, >while distinguishing between malicious and non-malicious source programs >can usually be done much more easily. If somebody does something that is obviously malicious, a moderator will quickly find the problem. This is independant of source vs. binary. If somebody wants to hid their maliciousness, they will take care to make sure that a source-code-virus is well hidden. I doubt that a time-bomb malicious smail would be found by the moderator. Do any of the moderators actually read all source code they post, carefully enough to understand the subtle (potentially malicious) implications of every line of code? Of course not! Sure, in theory it is much easier to do that than to disassemble a binary and figure all its complexity out, but practically speaking, they are both monumental tasks that just aren't going to get done! >Since I have trouble making this distinction, it seems >to me to be better to avoid the unpleasant possibilities that >binary distribution raises. And my response is: these 'unpleasant possibilities' exist right now in many forms on the net. They are worries that we must all live with. The net is NOT a completely safe, secure place. Please let others live with the insecurities necessary to their technical activities. If you can't do that, then maybe you'd like to volunteer to provide end-to-end encryption of everything on the net, so that some Sun-user-with-root-access can't add a few lines of killer code to the next News source code distribution as it passes through their site :-). Personally, I feel much better about trying a new binary on my RAM-disk-only PC setup, than I do about trying a newly compiled program on my Unix box. My conclusion: malicious postings are not a practical reality on the net at this point. There is no practical way to completely protect ourselves either. We must all be watchful to avoid the obvious problems [via moderation, etc]. Beyond that, we all must live with our own feelings of insecurity. Conclusion #2: the word 'malicious' now makes my brain glaze over...I get that funny "that word doesn't look *right* any more... isn't it spelled wrong?" feeling. :-) Pete -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746
weemba@garnet.berkeley.edu (Obnoxious Math Grad Student) (07/01/88)
In article <266@octopus.UUCP>, pete@octopus (Pete Holzmann) writes: > 1) Booby traps are extremely rare. As far as I know, no posting > in ANY binary or source group has ever been booby trapped. Not quite. There was one April Fools' posting of an "unrm" that allegedly did all sorts of miracles to recover your rm-ed files. It actually moved your .login to some other place and substituted a "hahaha, you twit!" .login. > Not even a simple killer rm in a shar! Perhaps the following qualifies: The age-old "how do I remove a file with funny characters in its name?" question came up. Someone listed several standard answers, and then said, "if you *really* want to get rid of that file, `rm -rf ~' will do the trick :-)". This attempt at UNIX humor, smiley face and all, went right over one, uh, naive, user, and the sysadmin who had to deal with the mess was rather unhappy with the original joker. > 2) Nobody has the time or willingness to truly analyze every > program (binary OR source) posted to the net for booby > traps. One can, however, scan source code for inordinately complicated monkey- shines, comments that don't appear to match code, etc. I know I give a lookover to the short little sources I get. When some- one posts a 10K ELisp package that looks promising, I will give it a semiread, trying to understand what is happening. I recently grabbed two 10K Mandelbrot generators for X-windows. Again, I gave them both a semiread. "Ah yes, I know this algorithm well--hmm here's some more X nonsense, looks like other X nonsense, although to hell if I know what it means, etc." I cannot do this with *any* "short little" binaries. > Suppose that a new smail version were well > boobied? News 3.0? A time-delay trap could be hidden in > the source code, and a LOT of people could get hurt. > BUT THAT'S JUST THEORETICAL. Practically speaking, I'm > not too worried. Booby-trapped source code though refers almost certainly to someone on the net, either the author or someone who messed with his FTP archives. Booby-trapped binaries could come from anywhere, including someone to- tally innocent whose program got infected by a virus on his PC. I sometimes wonder if I should day be more paranoid or not about Gnews. When I announce a release, should I mention the exact byte count of the compressed tar file? That would be difficult for someone to tinker with. I could go further and write a simple public encryption checksum scheme that would then be nearly impossible to get past. That is, we already have tar, compress/uncompress, uuencode/uudecode, and unfortunately numerous shar/unshar. One more step would be to imple- ment a standard "verify". Perhaps the moderators of comp.sources.* will eventually include a "Key:" header. (Check out a recent comp.org.fidonet posting for a description of what's involved.) This could guarantee author's responsibility for source code funny busi- ness, but it wouldn't mean beans for binaries. ucbvax!garnet!weemba Matthew P Wiener/Brahms Gang/Berkeley CA 94720
pete@octopus.UUCP (07/01/88)
In article <11518@agate.BERKELEY.EDU> weemba@garnet.berkeley.edu writes: >[I wrote...] >> 1) Booby traps are extremely rare. As far as I know, no posting >> in ANY binary or source group has ever been booby trapped. >Not quite. [April Fools' example...] Hmmm. I guess I should have thought about April Fool's postings. You're right. Booby traps can easily show up then. Fortunately, they aren't particularly malicious! >> Not even a simple killer rm in a shar! >Perhaps the following qualifies: ['naive' user follows joke advice] I think the posting was fine. The user who goofed is the trapped booby in that case :-). Any body got a booby-remover handy? :-) :-) >> 2) Nobody has the time or willingness to truly analyze every >> program (binary OR source) posted to the net for booby >> traps. >One can, however, scan source code for inordinately complicated monkey- >shines, comments that don't appear to match code, etc. > >[Weemba quickly scans short sources he receives for any obvious > problems] > >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. 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. >Booby-trapped source code though refers almost certainly to someone on >the net, either the author or someone who messed with his FTP archives. >Booby-trapped binaries could come from anywhere, including someone to- >tally innocent whose program got infected by a virus on his PC. 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 would trust a binary validated by one of the binary moderators. It would be best to ensure that the creator of the binary is the one responsible for posting to the net, but that isn't always possible. Even so, when I see a binary posting in a moderated group, prefaced by a note from Chuck Forsberg saying "I personally grabbed this program from the author; there is no way anybody has had a chance to harm it"... I don't particularly worry about it! >I sometimes wonder if I should day be more paranoid or not about Gnews. >[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, 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!]. 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!)] Pete PS: Weemba, I must congratulate you on posting a message completely lacking obnoxiousness in this group! [There, now I've done it. Sigh. :-)] -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746
rsk@s.cc.purdue.edu (Rich Kulawiec) (07/01/88)
In article <266@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: > 1) Booby traps are extremely rare. As far as I know, no posting > in ANY binary or source group has ever been booby trapped. Not true; a shar file posted to net.sources some years ago rearranged the files in one's directory when it was unpacked. This was enough to confuse a lot of people; if it had removed them, the problem would have been far worse. Hmm, I just remembered a second instance: a game source mailed a note to its author *over the trans-Atlantic link* each and every time it was executed. Not malicious, unless you're paying the transmission costs. >>Earlier, I wrote: >>I have no particular desire to disenfranchise microcomputer users; >>however, I have no particular desire to assist in the demise of >>their software and data holdings by being a party to the distribution >>of binary programs of a malicious nature. > >Please let THEM worry about that. You are not going to be held accountable >if a 'malicious' posting (binary OR source) is posted to the net. If it ever >happens, I'm sure that the all-out search for the offending party, and >ensuing nuclear flamefest, will break all records :-). In response to the first sentence: I wouldn't be too sure about that. Frankly, I would not be at all surprised to be named in a suit for damages resulting from the execution of a binary posted to Usenet and downloaded from the news system here. I might not be held liable; but the prospect of being hauled into court does not thrill me. If, on the other hand, everyone using a program that has passed through our system is willing to sign a sworn statement to the effect that they won't hold me "accountable" for anything it does, then, and only then, will I "let THEM worry about that." For obvious reasons, I doubt that this will happen. In response to the second sentence: As I pointed out in private mail to you, there is at least one way to sabotage a binary (or, admittedly, a source, although that would be much easier to detect) that will render detection of the offender, or the offender's system, almost impossible. And even if such an offender is found, and flamed, and so on, those affected by the sabotaged program might find that of little consolation. >And my response is: these 'unpleasant possibilities' exist right now >in many forms on the net. They are worries that we must all live with. I do not agree that we "must all live with" these problems. Further, I feel that a partial solution to the problem is to stop carrying binaries. A total solution would be to stop carrying source code as well. I am unwilling to accept the loss of functionality that this latter would entail, while I am willing to accept the risk that it poses. However, in the former case (binaries), I am not willing to accept the functionality/risk tradeoff. Why, some of you might ask, do I not just shut them off locally? Well, I just may do that at some point. On the other hand, I do try to administer news here in a way that is consistent with the practices used by the rest of Usenet, and so I find that attempting to persuade others on this issue is a useful endeavor -- if the day comes that I remove those groups, I'd prefer to be doing it as the outgrowth of a consensus on the issues rather than as a unilateral action. To look at it another way: attempting to balance the competing interests of our users, our resources, our news neighbors, and Usenet as a whole is sometimes difficult. Rich
pete@octopus.UUCP (Pete Holzmann) (07/01/88)
In article <3331@s.cc.purdue.edu> rsk@s.cc.purdue.edu (Rich Kulawiec) writes: >>And my response is: these 'unpleasant possibilities' exist right now >>in many forms on the net. They are worries that we must all live with. > >I do not agree that we "must all live with" these problems. Further, I >feel that a partial solution to the problem is to stop carrying binaries. >A total solution would be to stop carrying source code as well. I am >unwilling to accept the loss of functionality that this latter would >entail, while I am willing to accept the risk that it poses. However, >in the former case (binaries), I am not willing to accept the >functionality/risk tradeoff. Ahh, now you understand. There is always a functionality/risk tradeoff. For you, who have no use for the binaries, they pose a risk without any functional usefulness. For me, binaries are often important and useful. You find source code useful enough that you are willing to read it before compiling, then live with the risk that maybe there was a gotcha after all. I find binaries useful enough that I am willing to try them out on an isolated machine, then live with the risk that there's a problem after all. And my original statement IS true. We all must live with 'unpleasant possibilities' until the day that someone finds a way to eliminate all program bugs. Practically speaking, buggy software is much more of a problem on the net than malicious software. I'm sure that software bugs have caused MUCH more aggravation than viruses ever will! Sure, a few people get trashed by a virus. How many get trashed by program bugs? How many get trashed by their own operator error? Functionality/risk tradeoffs are in the eyes of the beholder. Please put yourself in the other guy's sandals before assuming that the functionality/ risk tradeoffs he lives with are intolerable. Pete -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746
rsk@s.cc.purdue.edu (Rich Kulawiec) (07/02/88)
In article <272@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: >Ahh, now you understand. There is always a functionality/risk tradeoff. Actually, I have understood this all along, since the days when I first started using Usenet in 1980. >Functionality/risk tradeoffs are in the eyes of the beholder. Please put >yourself in the other guy's sandals before assuming that the functionality/ >risk tradeoffs he lives with are intolerable. What possible reason could you have for assuming that I would not do so? I think a fair reading of my comments would indicate that I have carefully considered the issues from several viewpionts...further, my statements clearly represent my opinion, and are labelled as such; no attempt is made to apply them to other people, or to coerce others into agreeing with them. I suggest, incidentally, that many of those using the program resources of the network, *especially* those using binary programs, are not in a position to know whether the risk tradeoffs are intolerable for themselves or not, simply because they are not aware of them. Further, in my most recent article, I spoke primarily of the risk to institutions and system administrators; this issue has not been addressed in your response. rsk
pete@octopus.UUCP (Pete Holzmann) (07/02/88)
In article <3333@s.cc.purdue.edu> rsk@s.cc.purdue.edu (Rich Kulawiec) writes: >I wrote: >>There is always a functionality/risk tradeoff. >Actually, I have understood this all along, since the days when I first >started using Usenet in 1980. Good. Then you'll understand that when I see great value in a binary posting, and am willing to risk trying it out... well, that is my decision to make! >>Functionality/risk tradeoffs are in the eyes of the beholder. Please put >>yourself in the other guy's sandals before assuming that the functionality/ >>risk tradeoffs he lives with are intolerable. >What possible reason could you have for assuming that I would not do so? By tradition, we of the net attempt to go along with the overall anarchy, only applying our personal biases to the system(s) under our own control. Obviously, we espouse our point of view with other admins on the net as well. You've been forcefully arguing for removal of binaries from the net, mostly because the functionality/risk tradeoff doesn't look so hot to you. In all honesty, I believe you can only say that because you have never been in a position to see all the positive benefits of binary availability on the net. That is why it appears to me that you haven't looked at the other point of view in depth. >I suggest, incidentally, that many of those using the program resources >of the network, *especially* those using binary programs, are not in a >position to know whether the risk tradeoffs are intolerable for themselves >or not, simply because they are not aware of them. Which is to say, there are many naive net-readers, and it is easier for a naive person to use a binary than to use source. I agree with this. >Further, in my most >recent article, I spoke primarily of the risk to institutions and system >administrators; this issue has not been addressed in your response. This issue has been hashed out many times in the past. The net continues to be at theoretical legal risk for all kinds of real or imagined offenses. If anyone actually attempts legal recourse for solving any of these problems, it is likely that a major portion of the net would die. Practically speaking, most other net-offenses are much more likely to be the cause of such legal action. Why? Because malicious postings/programs are extremely rare. Even (or especially!) on this net so full of expert flame-throwers :-)! I've now been reminded of April Fool's jokes that might be considered malicious, although they were what I would call pranks, since their effects were easily undone. None were things that any reasonable person would even *consider* filing a lawsuit over. None resulted in even a hint at legal action. Yet every week it seems we see a threat of legal action because of some libel/slander/etc due to arguments getting overheated. It is my opinion [as owner of a half-million dollar company, and S/A to boot, not that it matters a bit, mind you, especially since I'd hardly call my operation 'major' :-)] that the risk/benefit factor for binary postings on the net is far more favorable than for the political/social/ talk/etc groups. They generate much more ill-will between net-readers than the binary postings ever will. I hope I've addressed the issue more directly now! Pete -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746
weemba@garnet.berkeley.edu (Obnoxious Math Grad Student) (07/03/88)
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