> I run DR-DOS. in single tasking mode. no background, nothing for a
> virus running on netware to get into.
Huh? A virus running on NetWare? There are no viri running on NetWare.
You'd need a piece of code that would run in both DOS and NetWare to do any
damage, unless you're talking pure server-side viri in which case the
station OS doesn't matter. Of course, a server-side virus could do
tremendous harm, but couldn't spread too easily.
Also, a single-tasking operating system is no less vulnerable to viral
attack than a multi-tasker. As long as you have a machine executing code,
you can have a virus. Boot-sector viri - those which are loaded before the
operating system and reside in sector 0 of a disk or bootable partition,
examples being the Stoned family (New York Boot is one I've had experience
with), Disk Ogre and Roulette off the top of my header - can be in memory
constantly, infecting every disk accessed by the system. DOS is especially
vulnerable to such attacks, since it uses the underlying BIOS interfaces to
access the disks and these can be hooked with a few bytes of machine code.
Multitasking systems are *less* susceptible to such attacks, since they need
to eschew the BIOS-based drivers in favour of their own tailored code.
A lot of viri target DOS especially, since it's easy enough to hook INT 21h
and capture all file accesses. Other operating systems need a bit more work
before such things can happen - NetWare and Windows, for instance, function
around a core of exported functions which can't be trapped without resorting
to some nastiness (dirty hooks are the main way of doing this - save the
first few bytes of a function's entry point and replace them with a jump to
the viral code).
> [software timebombs and loopholes]
> You cannot do this with an 'open source' operating systems like Linux
> or DR-DOS. Every macro and subroutine are up on public display for
> programmer peer review to see what it does, and why it is there.
Yes, you can hide such code in there, although as time goes on and more
people work on the project the chance of getting away with it decreases. I
think ESR wrote an essay on the subject, in response to a hole in IIS, which
pointed out that although the code is being reviewed constantly so obvious
holes are easy to spot (viz. Borland's Interbase, which was found to contain
a security hole as a way around a development problem recently), more
devious code (especially that which was introduced very early in the
development) could lay undiscovered for years.
Just because code is readily available, doesn't mean people will take the
time and effort to fully understand every nuance of its operation.
Certainly, there are sections of the code I work on for the FreeGEM Project
which I haven't needed to investigate fully yet since we got hold of it, and
some of them are in places that I probably won't ever need to understand.
Regards,
Ben A L Jemmett.
(http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
