padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson) (03/09/91)
(The following is my opinion only and has nothing to do with anyone else) I think it is time stand back from the PC and take a fresh look at how protection can be placed on the system. Too many products today rely on MS-DOS and its documentation to protect PCs. Since many functions of DOS and Windows are either mis-documented or un-documented and since there exist many opportunities for malicious software to attack before DOS, this is obviously not the place to start. Consequently, I must question any protection scheme that becomes active only with CONFIG.SYS or AUTOEXEC.BAT, this is too late. This is not to say that a program that goes resident earlier is going to be a cure-all, just that it is necessary to have even a chance at being effective. Hardware, in the form of a custom BIOS or ROM-extension, is the best solution, but in many cases, may not be a cost-effective one. For most machines, software alone is probably sufficient. It may not be able to stop everything, but it should be able to at least detect an exception before MS-DOS loads and stop anything thereafter. There are a number of good products out today to fill various functions (I use several, both home-built and commercial) but as yet I know of none that do everything necessary. Quite often, complaints are made about compatability with MicroSoft products, that certain functions may be "hidden" from detection. Again, this is a problem experienced from being layered on top of DOS or Windows that goes away if operation is performed "under the rainbow" (no reference to the ex-DEC product, either express or implied, is intended). It is understood that it is somewhat more difficult to determine from a sector write request at the BIOS level, exactly what is being written to, than interception of a DOS Int 21 would require, but requires no knowlege of any windowing, multi-tasking, or networking software to do so. Even if a program has established an application interrupt (and there are many available) to handle disk functions outside of DOS, they still go through the BIOS to do so and this is both detectable and re-directable. There are simply too many ways to "get around" what is published about MS-DOS (not to mention DR-DOS and several others) for their calls to be used as a first line of detection, this must be done at the "choke point" of the BIOS. Certainly DOS or any other O/S can be used to determine the cause of an exception, once it has been determined that an exception has occurred (wish I could use italics), but the important thing is to know that something has occurred (I can't fix it if I don't know its broke). Given this, intelligence can be applied to determine if what happened was permitted or to be disallowed. It is time that some ground rules be established for any protection scenario. I tried to make a "first pass" with the model a few issues ago, but it is up to the population to decide what (if anything) the vendors will produce. Just do not accept any claim that "it cannot be done". For me, if it does not start with the BIOS, it is not enough. See you in New York folks, Padgett
PHYS169@csc.canterbury.ac.nz (Mark Aitchison, U of Canty; Physics) (03/14/91)
padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson) writes: > I think it is time stand back from the PC and take a fresh > look at how protection can be placed on the system. Too many products > today rely on MS-DOS and its documentation to protect PCs. Personally, I blame Lotus 123. Well, what I mean is: back in the early days when MSDOS could have gone the many and varied ways of CPM (and there was little need for "exact" clones of the IBM), really high performance software like Lotus 123 bypassed DOS to get at the hardware. All of a sudden, micros had to be able to run Lotus 123 (and Flight Simulator). This required such a high degree of compatibility that viruses can be written to circumvent DOS and have a high chance of working. If DOS became the sort of standard that CPM or (better) Unix is, where all manner of incompatible hardware run the same o/s, then viruses would have a tough time spreading. > Hardware, in the form of a custom BIOS or ROM-extension, is > the best solution, but in many cases, may not be a cost-effective one. This is basically a good idea, but for it to work you have to restrict some things that "good" software has come to expect. This is the problem. While you can make some areas (like the partition table) fairly well protected from change, what is there to stop a virus modifying another executable, for example? Having some combination of low-down hardware protection PLUS ties with DOS so that it understands the context in which a write is generated, is better. Now comes the tricky bit: some installation programs, and compilers, legitamately change executable files. It is difficult to automatically tell the difference between what they do and what a virus does. So a third level is required... the person using the computer. This might come in the form of an annoying pop-up window everytime you reconfigure (or recompile), or some sort of list of known-to-be-okay exceptions (which has to be *very* well protected). So a good anti-virus approach is going to consider the whole system: hardware, BIOS, DOS, applications and end-user education. That, I think, is a good idea, but you soon end up with something that looks nothing like the present PC (or Mac or whatever). > It is time that some ground rules be established for any > protection scenario. I suggest: (1) DOS includes Read/Write/Delete protection on all files at a level that cannot be circumvented without relatively LARGE areas of virus code. I like DRDOS's password protection system - good enough to stop most viruses around today (I guess - someone may like to come up with a thorough survey). Better still would be internal work areas (like the "list of lists") that are not only undocuments, but vary enormously in their location and format randomly from version to version (or even have each copy of the operating system different!) (2) An "executable" flag, that can only be set by compilers, and only be reset by operator intervention. Files with this flag cannot be openned and accessed in the normal way, and (optionally) only files with this flag can be executed. (3) All directory clusters, boot sectors, FAT, and the first cluster of each executable (what a list!) can only be written to by DOS. This is easy to do if the BIOS knows the version of DOS being used, and checks the stack to see the return address. (4) BIOS should check the partition table, boot sector and o/s files before starting up, e.g. by calculating a checksum (with each BIOS chip using a different algorithm) and comparing it with a location in CMOS that can only be changed at start-up time. (5) Compilers should produce programs with several different checksums embedded in the program, at known locations (preferrably within the first 512 bytes), and external programs should be able to check they all match. A virus might be clever enough to install itself and fudge bytes so one checksum comes out okay, but not all of them. Of course, the program itself should check one or all as it starts up, to make sure it is the same checksum that was there when it was compiled (this code, and the second copy of the checksum, would be scattered in a different place in each program, and impossible for a virus to locate in all programs it may try to infect). The aim here is to avoid you getting already-infected programs, since the above suggestions only protect files once they are on your system. The first two simply bring DOS up to the level of mini-computer operating systems, and implement a relatively hassel-free method of protection, good enough for most cases, and the cheapest solution for existing users. The next two (plus, perhaps, hardware lock-out of certain IO instructions and interrupt vector tamperring), are much more powerful, and would probably need either an add-on board, or changes to the design of new computers. Notice that now BIOS and DOS have to be designed together, to some extent. Moreover, if the changes go as far as they should, LOTS of existing sofware simply won't run (e.g. Norton's DS & NU, all disk "optimisers", many fast backup schemes, some networking software, compilers, compressors of executables, and so on). Not something people will want to see introduced over night, but if the beginnings are introduced soon, in particular into the DOS, new software can start using these features now. Notice I say that this has to go *into* DOS, not another layer above or below DOS (although these are useful as well), since it is the operating system that has the best chance of "knowing" the context of the disk write of whatever, and thus avoiding unpleasant false alarms. It also is the software that should be setting the compatibility standards, not the hardware or add-on software. What do you think? Mark Aitchison, Physics, University of Canterbury, New Zealand.