Eric_Florack.Wbst311@xerox.com (06/24/91)
Ross says: =-=-=-= >It would appear to me that VIRx 1.4 isn't cleaning up after itself. >You guys just ran accross different bits of code because of different >ares of RAM being used to store the search strings. (Will I ever live this down? One mistake and *bingo!* all over the place. Sigh.) - -=-=-=-=-= Ha. You mean I wasn't the first? :*> You say: - -=-=-=-=" Actually, the strings are trivially "encrypted" to prevent the image out on disk from triggering who-knows-how-many other scanners out there. =-=-=- On /DISK/, yes. But consider the amount of scanners, including MAcAffee that look at RAM, as well. False trip city, as we have seen. You say: - -=-=-= The answer is simple: whatever for? The bad guys can certainly break whatever coding scheme I use, thereby using the string list just as if it were not encoded at all. =-=-= This misses the point altogether. My point was simply that without encryption of one sort or another, even in RAM, another package wil false trip. If you think that people are going to depend on your package alone for protection, this might not cause a problem. But a realitry check, ( facilitated by a quick peek at the postings in here) will prove that doesn't happen. You say: - -=-=- The signature a scanner uses is of no use to a bad guy unless he or she already has the subject virus on hand, in any case. =-=-=- Of course not. My point in this case was the person doing the altering to routre around your code being the original author. Moreover, we have seen several varieties of a particular virus around, indicating more than one person altered one person's code. This is commonplace. (Can you say 'Stoned'? Sure. I knew you could.) Obviously, virus code is being passed around, by writers of such code, like a wine bottle at a garbage can fire. Getting the original code is therefore no problem. You say: - -=-=-= >Encrypting the search strings in your code, therefore is always a good >idea, as is cleaning up the mess your program makes in RAM. VIRx, >apparently doesn't address these two points. Wrong on both counts. It is interesting, though, that about 20 beta testers did not find that problem at all.... =-=-= First point: How on earth is cleaning up RAM you've allocated with your program before the program closes to be considered a BAD idea? Diito a string encryption? As for your beta testers not finding the problem, I suggest to you that perhaps they missed a major problem. WIthout being judgemental, here, finding this problem after beta was complete would seem to call into question the validity of certain of your test results. Regards to you. E (Normal employer isolation disclaimers apply here... IE: They may or may not agree with my thoughts in this matter)
c-rossgr@microsoft.COM (06/27/91)
>From: Eric_Florack.Wbst311@xerox.com > >>Actually, the strings are trivially "encrypted" to prevent the image >>out on disk from triggering who-knows-how-many other scanners out >>there. >On /DISK/, yes. But consider the amount of scanners, including MAcAffee that >look at RAM, as well. False trip city, as we have seen. Sigh. Look, I simply didn;t remove the strings from memory. What's your point? >...[why should I bother to encrupt the strings except trivially?]... >This misses the point altogether. My point was simply that without encryption >of one sort or another, even in RAM, another package wil false trip. If you >think that people are going to depend on your package alone for protection, >this might not cause a problem. But a realitry check, ( facilitated by a quick >peek at the postings in here) will prove that doesn't happen. No, I get the point: my income depends on it. I had a bug. It's fixed in Version 1.5, released about ten minutes ago. A reality check would show that out of the thousands of people who run our code daily, about ten have complained about the interaction due to a bug that is now fixed. >My point in this case was the person doing the altering >to routre around your code being the original author. Moreover, we >have seen several varieties of a particular virus around, indicating >more than one person altered one person's code. This is commonplace. >(Can you say 'Stoned'? Sure. I knew you could.) Obviously, virus code >is being passed around, by writers of such code, like a wine bottle at >a garbage can fire. Getting the original code is therefore no problem. No matter what string is used, and no matter what the encryption routine for that string might be, it would be trivial to ascertain what that string is -- and without having to break the encryption. I know that your intentions are most likely good, sir, but you really have not stopped to consider all the issues before you post. You may think you have the solution to a non-problem, but your solution does nothing except add another area where a bug can creep in without providing anything but a *potential* feel-good- warm-fuzzy feeling. It does nothing but provide me with extra work and does not provide any benefit to the end user community. >>>Encrypting the search strings in your code, therefore is always a good >>>idea, as is cleaning up the mess your program makes in RAM. VIRx, >>>apparently doesn't address these two points. >>Wrong on both counts. It is interesting, though, that about 20 beta >>testers did not find that problem at all.... >First point: How on earth is cleaning up RAM you've allocated with >your program before the program closes to be considered a BAD idea? >Diito a string encryption? Simply becasue somebody says that encrypting the strings is a good idea does not make it a good idea. And, except for a bug that occurred in certain circumstances, the cleanup was typically done. >As for your beta testers not finding the problem, I suggest to you >that perhaps they missed a major problem. WIthout being judgemental, >here, finding this problem after beta was complete would seem to call >into question the validity of certain of your test results. Actually, it just showed that our beta testers did not run into that problem (recall that the reports I mentioned above were limited in number). This implies that they don't use one of our competitor's products. So what? There are many people who opt not to use our competitor's products. In fact, I hope to make sure that hardly anyone uses any of my competitor's products by providing better code than anybody else. And, sometimes, a minor mistake is make and is blown way out of proportion. Ross
p1@arkham.wimsey.bc.ca (Rob Slade) (06/28/91)
Eric_Florack.Wbst311@xerox.com writes: > Ross says: > - -=-=- > The signature a scanner uses is of no use to a bad guy unless he or > she already has the subject virus on hand, in any case. > =-=-=- > Of course not. My point in this case was the person doing the altering > to routre around your code being the original author. Moreover, we > have seen several varieties of a particular virus around, indicating While this arguement has some validity, I would suggest that it only serves to reinforce a point made before in this forum, and which I very strongly emphasize in my seminars and consulting. The "my scanner is better than your scanner, nyaah" school of evaluation misses a vital point: any two scanners are better than either alone. Even though I feel that Ross's product is one of the best on the market, and I use it myself for my own testing and protection, I would hate to see the day when it became the only one available. As Ross has pointed out, no matter how well strings are encrypted, eventually someone will break the code, and then it is a trivial matter to write a virus that circumvents that package. However, with a number of scanner packages on the market (and even I don't have them all), the author of a virus can never know which package his code will have to go up against. ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into (SUZY) INtegrity | turn it on." User Canada V7K 2G6 | Richards' 2nd Law Security | of Data Security