RADAI@HUJIVMS.BITNET (Y. Radai) (05/28/91)
Ross Greenberg writes in response to my posting: > To paraphrase your past arguments for the readership, I believe you > commented that FSP's installation was such a pain in the butt that few >people used the integrity checking feature FSP includes. Well yes, I was referring to that ... plus the fact that after three years of existence FSP still has no provision for checking the partition record (master boot record) ... plus the fact that for any given file, FSP gives the same checksum for all users, which (imho) is a security hole. (At least, these were true the last time I looked.) But just to show that I don't think your integrity checking is *all* bad :-) , I found that FSP was faster than any program based on a CRC over the entire file. I gladly accept your suggestion to continue the discussion on these points at the Virus Bulletin conference. (In fact, part of my lecture will deal with weaknesses like the above even if I don't specifically mention FSP.) But in my last posting I was concerned with FSP not in itself, but merely as an *example*: Since the vast majority of users don't check for weaknesses like these before they buy a program like FSP, high sales figures do not prove that the software is good. I don't deny that quality of software has *some* relevance to sales volume. The question is *how much?*. You didn't react to my statement that if the correlation were high, "we could completely dispense with all the quality comparisons that are continually being made in the literature, and simply quote sales figures." Is that what you're suggesting? Anyone else in this forum have an opinion on how high the correla- tion is between quality of software and sales volume (for products in the same price range)? Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL
padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) (05/29/91)
>From: Y. Radai <RADAI@HUJIVMS.BITNET> > Anyone else in this forum have an opinion on how high the correla- >tion is between quality of software and sales volume (for products in >the same price range)? a) price seems to have nothing to do with software quality unless you count documentation - its prettier with the high-priced ones. b) no complete package starts at the BIOS level yet therefore I don't give any a passing grade. (quantum economics).
c-rossgr@uunet.uu.net (05/29/91)
>From: Y. Radai <RADAI@HUJIVMS.BITNET> >... after three >years of existence FSP still has no provision for checking the >partition record (master boot record) ... Well, yeah: you're right, there. I've been busy with Virex-PC, but it probably *is* time for that feature to be added. > plus the fact that for any >given file, FSP gives the same checksum for all users, which (imho) is >a security hole. (At least, these were true the last time I looked.) Well, it is a single user system, after all....:-) No, I know what you mean and that you feel it should give different "seeds" for each system. I recall that discussion and that I felt (and still feel!) it's a good idea, but a tech support nightmare. > Since the vast majority of users >don't check for weaknesses like these before they buy a program like >FSP, high sales figures do not prove that the software is good. Actually, I think that very high sales figures causes inertia in a product: I really can't simply change the functionality of FLU_SHOT+ (or of Virex-PC) without pissing off a lot of people or adding in extra layers of backwards compatability. There are a buynch of things I'd love to change in each of the programs to make them far better programs, but that would break > 75K current users of the products. > You didn't react to my >statement that if the correlation were high, "we could completely >dispense with all the quality comparisons that are continually being >made in the literature, and simply quote sales figures." Is that what >you're suggesting? Not quite. However, a real dog of a product that simply doesn't work is, eventually, gonna be found out and will have zero sales volume. So, it would be safe to say that -- after enough time has passed -- sales volume would indicate that a bunch of people are happy with the program, and that this *may* be an indication that the product is of high quality (Hmmm, maybe this is turning into a submission for RISKS...) It's tough to decide on what determines the relative quality of a product, though: if a scanner does 500 viruses and scans your disk in two minutes and another scanner does 600 viruses and scans your disk in three minutes, which one is a "better" product? Does making it pretty, with a cool/spiffy GUI make it a "better" product? I would think that using the sales volume of a product along with *other* factors could help to decide what products to take a look at. But the quality *comparative* reviews are what makes a product's quality easy to see -- and relative to boot. It is this relativeity that changes, making quality a moving target. High sales figures indicates that what somebody is offering, somebody is buying. This must be taken into account in the equation, no? Ross
padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) (05/29/91)
>From: microsoft!c-rossgr@uunet.uu.net >... it should give different >"seeds" for each system. I recall that discussion and that I felt >(and still feel!) it's a good idea, but a tech support nightmare. Doesn't have to be, Enigma-Logic's product uses a different "seed" for each machine that is entered once by the user at installation time & is never encountered by either user or tech again. Also, about a year ago, we discussed a matrix method for a sinple checksum algorithm to be produced on the fly. >Not quite. However, a real dog of a product that simply doesn't work >is, eventually, gonna be found out and will have zero sales volume. The hooker here is "eventually". Besides, few products don't work at all and the first indication the poor sap who bought it may not come until he gets hit by something that is not caught or a manager finds out what it costs to update the software periodically on 5000 PCs. Anti-Viral software should now be in its third generation: 1) Initial design 2) Take care of exceptions & annoyances 3) Make it "user-friendly" but, except for those who are very deep into the subject, it is difficult to determine the "exception" cases and which products have the third generation look but skipped the second. I know of at least five software packages and several BIOSes & disk controllers that will give a good integrity checker fits (second generation problems) but have not seen any advertising by anti-viral products that give me a "warm" feeling. In the last month, I have returned two different Windows word processors to their respective manufacturers, one because it thought WordStar 4.0 was the last version (5.0 came out in 1988), another because the driver I had to use for my Panasonic printers (Windows doesn't list any Panasonics) caused the second to produce pure gibberish on the screen. These are second generation problems. >It's tough to decide on what determines the relative quality of a >product, though: if a scanner does 500 viruses and scans your disk in >two minutes and another scanner does 600 viruses and scans your disk >in three minutes, which one is a "better" product? Does making it >pretty, with a cool/spiffy GUI make it a "better" product? Consider quantum economics: first the process must be "good enough". Then linear comparisons become important. A minute is lost in the noise to a tech checking out a problem. If it occurs every time a user loads a file, it is liable to be noticed. To me "good enough" is a product that will detect any change to a system or authenticated file that is unauthorized without flagging. At the same time actions that are authorized for a product will be passed without challenge. I haven't seen any yet though some come close. I will make a stab at some targets: 1) Simple to install - should only give user opeions that are based on the machine in question. 2) Should recognize incompatable products 3) Should be robust enough not to require program updates unless new features are added. Simple data files updates of new signature strings should be all that is necessary 4) Each machine should have a different algorithm if only a unique seed. 5) Must make provision for routine mainenance (defrag, etc.) while maintaining functionality 6) Must be easy to remove for troubleshooting 7) Must recognize ANY change and be smart enough not to bombard the user with notices when authorized. Wish list: program privilege (e.g. rwe) interpreted and enforced by the program manager. Unknown programs have no privilege. Disk access enforcement is easy. Memory access enforcement is more difficult (but possible with 386 or good memory manager hardware). We will probably not be there until every new program is distributed on non-volatile media (e.g. notchless floppies) with authentication documentation, certification that what was received was what the manufacturer meant to send out, and a list of specific permissions the package requires. Unfortunately, I know of many mainframe packages that do not meet these criteria.
c-rossgr@uunet.uu.net (05/31/91)
>From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) >>... it should give different >>"seeds" for each system. I recall that discussion and that I felt >>(and still feel!) it's a good idea, but a tech support nightmare. >Doesn't have to be, Enigma-Logic's product uses a different "seed" for >each machine that is entered once by the user at installation time & >is never encountered by either user or tech again. >Also, about a year ago, we discussed a matrix method for a sinple checksum >algorithm to be produced on the fly. If the seed is entered by the user, then there might well be problems of getting "pre-installed" copies within an organization that al share the same seed. Just as an example: one site license on FLU_SHOT+ pre-installed it on about 300 machines. Just by chance the installer was running DOS 4.01 on his machine, everybody else was running DOS 3.3. Obviously, the checksums on the system files and COMMAND.COM were different and I got umpteen tech support calls on the "problem". Now, this was a major problem because of installation done beforehand. Imagine my problem if each checksum was altered slightly with a different seed? Unless they tell me the seed (or I play games to derive the seed), I have a major tech support problem. And if they have the seed stored on the system anywhere -- sorta required in order for it to work! -- then the bad guy can find it just as easily as my own code can. It buys the end user nothing, in my opinion, but causes a major support headache. Hey! Didn't I say that on the other side of the album or last year? >Anti-Viral software should now be in its third generation: >1) Initial design >2) Take care of exceptions & annoyances >3) Make it "user-friendly" Actually, I think each of those phases are sorta endless loops. Lots of changes in the next cut of my code due to enduser feedback, responding to competitors, etc. >To me "good enough" is a product that will detect any change to a system >or authenticated file that is unauthorized without flagging. At the same time >actions that are authorized for a product will be passed without challenge. >I haven't seen any yet though some come close. If you want RACF on a PC, you'll have to change operating system, I think. It looks like you're speaking of authenticity and access control -- these must be considered important *parts* of an anti-viral package. But not the whole thing. >I will make a stab at some targets: Forgive me if I "stab" you back? <g> > 1) Simple to install - should only give user opeions that are based on > the machine in question. Pre-installed products will have a problem as mentioned above. Many sites don't want to install each package individually on individual machines. > 2) Should recognize incompatable products Once advised, sure. Until then...how does one know? This will always be a one-version-off problem. > 3) Should be robust enough not to require program updates unless new > features are added. Simple data files updates of new signature strings > should be all that is necessary See the compatability problem you mention above. A bug has to be fixed and not all compatability problems can be determined at release time. As for virus scanners: my first product in the arena used a brute force method of scanning, back when I had about 50 strings. I have about 500 now. The same technique would have you waiting ten times longer. One method was quite appropriate a year ago, a different one now. Once DOS 2.x ruled the earth, but lots of dinosaurs get extinct. Upgrades are required in many cases, says this mammal. > 4) Each machine should have a different algorithm if only a unique seed. See above. > 5) Must make provision for routine mainenance (defrag, etc.) while > maintaining functionality Difficult to maintain system integrity there while doing "dangerous" things, though. But agreed. > 6) Must be easy to remove for troubleshooting Hey, *my* code never needs to be removed! <grin> > 7) Must recognize ANY change and be smart enough not to bombard the user > with notices when authorized. Should be user selectable, allowing a sys admin (even on a PC!) to determine just how "loud" an alert should be. >Unfortunately, I know of many mainframe packages that do not meet these >criteria. Yeah, RACF. Remember: this is not your father's Oldsmobile... Ross
padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) (05/31/91)
>From: microsoft!c-rossgr@uunet.uu.net >If the seed is entered by the user, then there might well be problems >of getting "pre-installed" copies within an organization that al share >the same seed. Ross: we seem to be cross communicating. In our shop we do not use "pre- installed" copies, no two machines are alike anyway & we are running everything from DOS 2.0 up. On installation, the package we use takes 3-5 minutes to take a "snapshot" of the PC and record every executable on it during installation. >And if they have the seed stored on the system anywhere -- sorta >required in order for it to work! -- then the bad guy can find it just >as easily as my own code can. Only if the "bad guy" knows where it is stored and if the offsets are the same on every machine - one of the drawbacks to "pre-installation". If you cannot ensure the physical integrity of the machine all bets are off. It would take a complex and specifically targetted piece of software to be able to determin that you were there (and not some other routine) and bypass it - not for an amateur. One of the problems is that at present there is a single criteria for judging PC protection programs: the number of viruses it detects. In actuality, this is one of the lesser threats that a full package should take care of. >If you want RACF on a PC, you'll have to change operating system, I >think. It looks like you're speaking of authenticity and access >control -- these must be considered important *parts* of an anti-viral >package. But not the whole thing. a) RACF is the only product that I have seen that will tell a user where its holes are (LISTDSD command). b) I am but authentication of the system/programs, not of the user. c) Thats what I said - see multilayer "model" of a few months ago. The points made should still be targets, possible but not necessarily easy. BTW all my cars are Pontiacs. Warmly, Padgett
c-rossgr@uunet.uu.net (06/19/91)
>From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) (Sorry for the delay...off line for a while) >Ross: we seem to be cross communicating. In our shop we do not use "pre- >installed" copies, no two machines are alike anyway & we are running >everything from DOS 2.0 up. On installation, the package we use takes >3-5 minutes to take a "snapshot" of the PC and record every executable >on it during installation. So, then, you have to install the program on each machine. Taking that "snapshot" is a good idea, but still has problems if you use a)a new seed on each machine and b) store that seed someplace where it can be seen by "the bad guy". If someone is going to subvert the code, they're gonna subvert the code and there's nothing we can do about it. It's not as if DOS were a real operating system -- it provides no real protection and simply putting more and more layers of "feel-good-and-warm-and-fuzzy" dressing on DOS simply makes a person *feel* better, but provides them with nothing. If somebody wanted to mcreate a virus that gets around my stuff and the code of everybody else out there, they probably could. Targetting my code is sorta silly: it's too easy to simply go right out to the disk controller if you really needed to. >Only if the "bad guy" knows where it is stored and if the offsets are >the same on every machine - one of the drawbacks to >"pre-installation". If you cannot ensure the physical integrity of the >machine all bets are off. It would take a complex and specifically >targetted piece of software to be able to determin that you were there >(and not some other routine) and bypass it - not for an amateur. Right. So, if they're targetting my code, no protection will suffice, if they are not targetting my code, why bother making things more complex. Your mileage may, of course, vary. > One >of the problems is that at present there is a single criteria for >judging PC protection programs: the number of viruses it detects. In >actuality, this is one of the lesser threats that a full package >should take care of. Well, the efficiency of a package in stopping viral infections has yet to have any scale to measure it by. When such a scale exists, all the vendors will be climbing to the top of that heap, too. Ross (My views, not Microsoft's)