TIP: Click on subject to list as thread! ANSI
echo: os2prog
to: Robert King
from: Brian May
date: 1995-01-03 11:48:16
subject: Re: Virus Alert!

RK> Brian,

 RK> #1, Writing to executing executables is simple and is in fact done 
 RK>     quite often by shareware and some comercial applications.

Maybe, but it is IMPOSSIBLE (like I previously stated) to write to a
*running*OS/2 program. The operating system keeps the file locked in deny
write mode, and won't allow any other programs to open the EXE file for
writing. The only possible way to get around this is for the EXE file to
start another program and to exit. This 2nd program can then do what is
likes with the EXE file. It is possible, but not as straight forward as
directly accessing the EXE file.

A virus could potentially infect an EXE file in this way, but there are
many more things to watch out for then in a plan DOS machine.

(Also, if an EXE file writes config information to itself, it makes it
network unfriendly)

 RK> #2, Protected mode means nothing to the virus programmer.
????

I fail to see how you can say this. This OS has full control over what
programs can access what hardware/memory. Protected mode DOES matter.

Then again, maybe a virus can infect a low level device driver. I suspect
that this wouldn't be an easy task. The many different hardware/device
driver combinations possible on a computer wouldn't make it any easier.

 RK> #3, Even a DOS based program can read/write to HPFS drives under OS/2
 RK>     just as they do in DOS. NO VIRUS uses BIOS/DOS 
 RK> calls for reads and     writes. Such operations are 
 RK> performed at the port level which, as you
 RK>     apparently aren't aware, bypasses the operating system entirely.
You seem to know very little about how OS/2 manages VDMs and virtual device
drivers. Unlike in DOS, Operations performed at port level *DO NOT* bypass
the operating system, unless there is no virtual device driver for that
port. How else can OS/2 manage running multiply DOS sessions at the same
time without major conflict. Eg, direct writes to/from screen memory/ports
are intercepted and cordinated in a way that does not effect other
processes. BIOS, CMOS, DMA, Disks, keyboard, printer are all virtualized by
virtual device drivers. I could expand on this. It is interesting to note
that OS/2 2.0 didn't emulate the port I/O interface for hard disks, and
that attempts from a dos program to do so will fail. I suspect that OS/2
2.1 and 3.0 will be similar.

 RK> #4, The OS/2 scanners that are available, DO NOT detect several virusi.
 RK>     One that I can demonstrate readily is the 
 RK> Frankenstien virus which I     have on a floppy. Not 
 RK> only do the OS/2 scanners not see it, but the DOS
 RK>     based scanners don't recognise it either when run under OS/2. And at 
 RK>     this point, the ONLY scanner I've found that DOES find that particular
 RK>     virus is Symantec's Anti-Virus for DOS/Windows.
I can't really comment on this, but maybe your virus scanner isn't up to
date??? Anyway, DOS/Windows scanners should be just as efficient at
detecting viruses on an OS/2 machine as on a DOS machine. Even new (?) OS/2
viruses should be picked up on up-to-date MS-DOS scanners, or the scanner
isn't doing its jobs properly. For best results in Virus Scanning, close
off all copys of running programs, in case the scanner can't access locked
files.

 RK>  The point I'm trying to make clear here is, OS/2 virusi may be few and
 RK> far between but, they are as real a danger as burns 
 RK> from lighting one's hair afire. And until the OS/2 
 RK> community wakes up and takes the required steps to 
 RK> prevent loss, the danger will only continue to grow.

I am  not denying that it is possible to write a virus for OS/2, I am
saying it is a lot harder for it to do any damage. Dispite the fact that a
number of weak points do exist is OS/2, I number of them could always be
fixed in latter versions of OS/2, or by add on utilities. EG, it could
always be possible to write a utility that runs at startup that locks
config.sys and other device drivers to prevent other proccesses writing to
them. It may take up slightly more system recources, but it would work.

Brian May

--- Maximus/2 2.02
* Origin: Multi - 61-3-739-7145 (3:633/363)
SEEN-BY: 12/2442 620/243 624/50 632/103 301 341 348 386 998 633/104 252 260
SEEN-BY: 633/353 363 371 373 379 634/384 635/301 502 503 636/100 638/100
SEEN-BY: 640/820 690/660 711/409 410 413 430 807 808 809 934 942 949 712/353
SEEN-BY: 712/515 713/888 800/1 7877/2809
@PATH: 633/363 260 371 635/503 632/348 711/409 808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.