Eric_Florack.Wbst311@xerox.com (06/20/91)
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. I state this obvious point, to make a point. This would seem slopy code on two points: One that VIRx doesn't clean up after itself, allowing other programs to find it's code fragments, is of course a major concern to the users of the program. (Should also be of great concern to the authors, but no matter for that for now..) The second point is that it's a security problem for all computer users. Consider: It's simplicity itself for someone who can write a virus to tear apart the non-encrypted VIRx code and determine the search strings used in VIRx. Now, this in itself wouldn't be a problem, I guess, but consider that what SCAN saw, were the search strings that VIRx was using.... meaning they're using the SAME strings. Based on this info, anyone who wanted to, could, in theory, modify the virus enough that the string would no longer bee caught by the current search strings. 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.
c-rossgr@microsoft.COM (06/21/91)
>From: Eric_Florack.Wbst311@xerox.com > >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.) >The second point is that it's a security problem for all computer >users. Consider: It's simplicity itself for someone who can write a >virus to tear apart the non-encrypted VIRx code and determine the >search strings used in VIRx. Actually, the strings are trivially "encrypted" to prevent the image out on disk from triggering who-knows-how-many other scanners out there. The image I left in memory is *after* the decryption. Why, you might wonder, don't I use a more complex en/de-cryption scheme? 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. Since it is trivial to make a program that can determine what string a scanner is using, using complex schemes serves no purpose except to a)give more areas for weird bugs to show up, b)a tad of time spent by *every* user in the decrypt routine. 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. >Now, this in itself wouldn't be a problem, I guess, but consider that >what SCAN saw, were the search strings that VIRx was using.... meaning >they're using the SAME strings. Based on this info, anyone who wanted >to, could, in theory, modify the virus enough that the string would no >longer bee caught by the current search strings. In many viruses (virii?) there is only a small area that you can use to figure out a decent signature. Two scanners using a similar area should not be considered unusual. One of my favorite areas to use is the "Are you there?" call most resident viruses use: I assume most others use it, too. For viruses that I don't have on hand, I use the Virus Bulletin list: I would presume that the bad guys have as much access to that list as McAfee's scanner programmers do, too.... >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.... One of the interesting things: Microcom, the people who publish and market my code, is expressly forbidden from using McAfee products by the vendor itself. This is interesting since Microcom was, until recently, a member of the so-called CVIA, paying their dues and getting *absolutely* none of the privs supposedly associated with that membership. Ross