padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) (05/24/91)
I can see that some background is going to be necessary as this looks to be
an on-going discussion.
Firstoff, starting MS-DOSs not a single file, it is a collection of files,
all of which are used yet not all of which remain resident. These include
IO.SYS, MS-DOS.SYS, and the familiar COMMAND.COM. Even in DOS 3.3, probably
the most common version, a little examination will reveal that these three
files take up around 150k bytes on the disk.
Next, if you look at the interrupt table and BIOS data structures, you will
that another 3k are occupied before DOS ever starts. Yet on a 640k machine,
there is about 595k free space left with a bare DOS loaded. This means that
only about 45k of low memory is in use when the C:\ prompt appears (& no TSRs
are loaded. Obviously this doesn't add up, where did the other 100+k go ?
Part of it is in the transient part of COMMAND.COM loaded into the TOM (top
of memory) but COMMAND.COM is only about 25k so even if all were transient,
we would still have 85k or over half of MS-DOS unaccounted for.
The answer is that while all of MS-DOS is used, part of it is only necessary
for start-up. Once these segments are complete, the memory occupied by
structures like SYSINIT is released back into the free space for re-use just
like when an application is complete, the space occupied is reuseable by the
next program. With ROM this is more difficult.
Thus, while the permanent portion of MS-DOS is ROMable, the transient half
must use one of three choices:
1) Keep on volatile disk & map in and out of RAM as is done now.
2) Place in ROM & reduce free memory space (high memory above segment C000
could be used but with the proliferation of memory managers to load
TSRs "high", for many users today this would have the same effect as to
reduce free "low" memeory. ROMed laptops generally use this technique.
3) Add circuitry to map in ROM to available address space & remap to RAM
when done ($).
The hooker is that the data areas (interrupt table, BIOS data, DOS data)
MUST remain in RAM or undergo major structural changes (2k of CMOS is
a possibility), and these are the areas that viruses generally attack.
Unfortunately, in the case of many popular applications (1-2-3, Windows,
etc.) these would also have to be rewritten to accomodate the new structure
(see Apple III, LISA, Mac 128, DEC Rainbow & DECMATE for the effects of such
changes/differences).
Additionally, as AZUSA has demonstrated, even if the data was moved to CMOS
it would still be attackable, just differently.
Another problem would occur if the ROM were to "glitch", how would maintenance
be performed ? A BIOS "switch" could be added, but we have these available in
BIOS now from a few vendors, but the general public does not demand it. Also
maintenance can take many forms: about once a week I boot from a floppy to
perform defragmentation, backup, & compression since some of the 121k of TSRs
loaded high are incompatable with this kind of operation (one of the first
additions to DISKSECURE was the ability to create a boot floppy for this
reason) and most users do not want to have to rename their CONFIG.SYS &
AUTOEXEC.BAT before rebooting.
It has been stated that ROM could be inexpensive. True, in production quantity
the cost is less than a dollar, but take a look at BIOS upgrades with much less
code than MS-DOS that are holding at about $70 for the two-chip set.
The point has been made that MBR infectors such as the STONED would become
obsolete since the MBR and supposidly the Boot Record would become mere
tables. However, in this case, the first executable becomes CONFIG.SYS instead
of the MBR. We would just see a "new" breed of infectors - like many "new"
viruses today just a few changes would be necessary.
Of course, it would depend on the implimentaion also, just to use the STONED
again, the fact that it is so widespread has nothing to with any MS-DOS
requirement: MS-DOS does not "require" hidden sectors, all versions will run
without any. Yet most MBR & Boot Record viruses depend on them because they are
usually there. If they weren't, the method used by the earlier BRAIN and
attempted by the MusicBug would be much more widespread.
Again: there is nothing basically wrong with MS-DOS (and DR-DOS) that has
caused the incredible spread of viruses other than the total lack of
integrity checking, something that can be easily corrected in the BIOS or
by a BIOS extension. Putting MS-DOS in ROM will not itself reduce the risks,
it will just transfer some holes for others while necessarily leaving most
wide open.
Warmly,
Padgett
Only a third of a good program's code is needed to accomplish its function
the other two-thirds is to accomodate user's mistakes.
ps very few viruses actually change any executable code belonging to DOS
the common ones just change pointers that must be alterable to point to
themselves or map themselves into executed volatile storage locations
by reading (or knowing) the pointers. - apppadgett%tccslr.dnet@mmc.com (Padgett Peterson) (05/30/91)
"William Walker C60223 x4570" <walker@aedc-vax.af.mil> writes: >We're writing from two different premises. Padgett is writing about >MS- DOS actually running from ROM, while I'm writing about the DOS >files, and the boot disk itself, being in ROM ( a ROM-disk, as opposed >to a RAM-disk ). ... The method of booting from >a ROM- disk ( with an infection-proof boot sector and system files ), >which I wrote about, is not implemented at this time, to the best of >my knowledge. While I follow the premise better now, what you are talking about is what I referred to in the third option - somehow swapping ROM addresses for RAM addresses or possibly a "page frame" approach such as used for expanded memory. It will take a special BIOS driver to accomodate just like a RAM-disk requires a special driver and the data areas will have to stay resident somewhere. The point is that there are a finite number of addresses available and if some are used for ROM then there are that many less for RAM unless some extra memory management scheme is used such as that used for "shadow RAM" on 386s - not difficult but requires a few extras. The point I was trying to make was that even with this type of mechanism, the same holes exist in MS-DOS as did before. Some have been moved (e.g. the first attackable point) so that specific malicious software will be thwarted, but the hole still exists and will just be exploited in the next crop. There is still NO integrity management in MS-DOS. Warmly, Padgett
jesse%altos.Altos.COM@vicom.com (Jesse Chisholm AAC-RJesseD) (06/12/91)
padgett%tccslr.dnet@mmc.com (Padgett Peterson) writes: | "William Walker C60223 x4570" <walker@aedc-vax.af.mil> writes: | | >We're writing from two different premises. Padgett is writing about | >MS- DOS actually running from ROM, while I'm writing about the DOS | >files, and the boot disk itself, being in ROM ( a ROM-disk, as opposed | >to a RAM-disk ). ... The method of booting from | >a ROM- disk ( with an infection-proof boot sector and system files ), | >which I wrote about, is not implemented at this time, to the best of | >my knowledge. Acer America in joint venture with Smith Corona has recently marketed a small 286 PC that has a ROM cartridge that is used as a ROM disk. SCC sells it as a PWP-100 (Personal Word Processor) and the software looks alot like their earlier WP machines. This is the first in a product line that has MS-DOS on ROM cartridge. Not all of DOS, just enough to boot. (IO.SYS, MSDOS.SYS, COMMAND.COM, AUTOEXEC.BAT, CONFIG.SYS, and maybe SHARE.EXE, HIMEM.SYS, ANSI.SYS, ..., and the WP software) | While I follow the premise better now, what you are talking about is | what I referred to in the third option - somehow swapping ROM | addresses for RAM addresses or possibly a "page frame" approach such | as used for expanded memory. It will take a special BIOS driver to | accomodate just like a RAM-disk requires a special driver and the data | areas will have to stay resident somewhere. The point is that there | are a finite number of addresses available and if some are used for | ROM then there are that many less for RAM unless some extra memory | management scheme is used such as that used for "shadow RAM" on 386s - | not difficult but requires a few extras. Acer's method doesn't use up RAM addresses, since the ROM card is seen as a read-only hard disk. The ROM card itself does use some IOcard address space since it is considered an expansion card by the hardware. | The point I was trying to make was that even with this type of | mechanism, the same holes exist in MS-DOS as did before. Some have | been moved (e.g. the first attackable point) so that specific | malicious software will be thwarted, but the hole still exists and | will just be exploited in the next crop. There is still NO integrity | management in MS-DOS. Sad but true. Jesse Chisholm | Disclaimer: My opinions are rarely understood, let jesse@altos86.altos.com | tel: 1-408-432-6200 | alone held, by this company. jesse@gumby.altos.com | fax: 1-408-435-8517 |----------------------------- ======== This company has officially disavowed all knowledge of my opinions. - -- "Question Authority!" -- Wallace Stegner "And that's an order!"