erk@americ.UUCP (Erick Parsons) (09/09/89)
With all of the occasional hoopla concerning virus's that add X # bytes to random executables in your C directory why not take some VERY simple pre- cautions. Use those script bits. I've gone through my whole C directory and changed the script bits to ----r-e-. This should alert me to any phenomonem that would cause a write to those files and protect the files to boot ! I got em in one swipe using the list lformat command: cd c: list > ram:temp lformat "protect %S -wd" execute ram:temp viola the drive churned for a minute and all files were protected from being overwritten. Just to confirm I tried copying a file named list from ram: to my c dir and got the error message that c:list was protected from deletion :-) -- -- ------------------- // ---------------------------------------------------- Erick Parsons // .Knowledge is little more than knowing the questions ------------- // .erk@americ.UUCP or ..ames!pacbell!sactoh0!americ!erk Sacramento Ca \\ // .GEnie: E.PARSONS %-) Hamatuer Radio N6RZB -------------- \X/ --------------------------------------------------------
martens@ketch.cis.ohio-state.edu (Jeff Martens) (09/12/89)
In article <1894.AA1894@americ> erk@americ.UUCP (Erick Parsons) writes: >With all of the occasional hoopla concerning virus's that add X # bytes to >random executables in your C directory why not take some VERY simple pre- >cautions. Use those script bits. I've gone through my whole C directory and >changed the script bits to ----r-e-. This should alert me to any phenomonem >that would cause a write to those files and protect the files to boot ! This is probably worth doing, but note that it's only effective against viruses that go through the OS to do their I/O. Additionally, a bright virus could look to see what the protection is initially, change it to something writeable, and then restore the old protection after making its changes. -=- -- Jeff (martens@cis.ohio-state.edu) Ever seen a sparrow stall?
usenet@cps3xx.UUCP (Usenet file owner) (09/12/89)
-In article <1894.AA1894@americ> erk@americ.UUCP (Erick Parsons) writes:
->
->With all of the occasional hoopla concerning virus's that add X # bytes to
->random executables in your C directory why not take some VERY simple pre-
->cautions. Use those script bits. I've gone through my whole C directory and
->changed the script bits to ----r-e-. This should alert me to any phenomonem
->that would cause a write to those files and protect the files to boot !
->
->I got em in one swipe using the list lformat command:
This would only fool brain-dead viruses.
Any virus worth its bits would check this,
de-protect what it needed too, and then reprotect
and set-date so the only change visible would be
the size of the file.
FYI: A program can change file protection bits without using
the c:protect program.
REAL NAME: Joe Porkka jap@frith.egr.msu.edunew@udel.EDU (09/13/89)
Incidentally, on the OFS, it seems possible to expand a file without changing the size. I did this with a disk editor once, trying to reduce the size of a file. The file header block said one size, which is what LIST showed, but upon doing a copy (or presumedly anything else that read until EOF) all the trailing data would be copied because the data blocks themselves said that there was more data. (I was trying to chop off some ^Z's and did not yet have a compiler.) I would think that this would not work under FFS, as the length is only stored in one place for each file. Also, I don't remember whether such a munged file would pass the validator or not -- This was AmigaDOS 1.1, I think. I would suggest that authors of virus-catchers check for such a situation by simply reading the file and seeing that the number of bytes read matches what Examine() says it should be; otherwise, the file is suspect. -- Darren
erk@americ.UUCP (Erick Parsons) (09/13/89)
->From: usenet@cps3xx.UUCP (Usenet file owner) Message-ID: <4562@cps3xx.UUCP>
-->In article <1894.AA1894@americ> erk@americ.UUCP (Erick Parsons) writes:
-->
-->With all of the occasional hoopla concerning virus's that add X # bytes to
-->random executables in your C directory why not take some VERY simple pre-
-->cautions. Use those script bits. I've gone through my whole C directory and
-->changed the script bits to ----r-e-. This should alert me to any phenomonem
-->that would cause a write to those files and protect the files to boot !
-->
-->I got em in one swipe using the list lformat command:
->This would only fool brain-dead viruses.
->
->Any virus worth its bits would check this,
->de-protect what it needed too, and then reprotect
->and set-date so the only change visible would be
->the size of the file.
->FYI: A program can change file protection bits without using
->the c:protect program.
->REAL NAME: Joe Porkka jap@frith.egr.msu.edu
Hmmm.. Seems to me that with a simple (?) OS mod we could have some sort
of Script Bit password protection as an option. I'm not a programmer so
I may be out in left field on this but the concept seems similiar to
one that is already used on Unix systems. If it were possible would this
stand up to these killer viruses ?? .... Just wondering..
--
--
------------------- // ----------------------------------------------------
Erick Parsons // .Knowledge is little more than knowing the questions
------------- // .erk@americ.UUCP or ..ames!pacbell!sactoh0!americ!erk
Sacramento Ca \\ // .GEnie: E.PARSONS %-) Hamatuer Radio N6RZB
-------------- \X/ --------------------------------------------------------martens@ketch.cis.ohio-state.edu (Jeff Martens) (09/15/89)
In article <1934.AA1934@americ> erk@americ.UUCP (Erick Parsons) writes: >Hmmm.. Seems to me that with a simple (?) OS mod we could have some sort >of Script Bit password protection as an option. I'm not a programmer so >I may be out in left field on this but the concept seems similiar to >one that is already used on Unix systems. If it were possible would this >stand up to these killer viruses ?? .... Just wondering.. Actually, this isn't easy on the Amiga. Unlike a typical multi-user system (e.g., Unix), all tasks on the Amiga run with the same privileges. If you know Unix, that's like saying that every process is effectively superuser. Under Unix, if the super user doesn't happen to know a password, he/she just bypasses the security. A smart virus on the Amiga can execute whatever instructions it wants to, and access whatever memory or disk locations it wants to, bypassing as much of the OS as necessary. Following your suggestion, though, the virus writer would have to be a little more clever, which is good for us, but chances are he already is, which is good for him. Darn. -=- -- Jeff (martens@cis.ohio-state.edu) Ever seen a sparrow stall?
swarren@eugene.uucp (Steve Warren) (09/15/89)
In article <60786@tut.cis.ohio-state.edu> Jeff Martens <martens@cis.ohio-state.edu> writes: >In article <1934.AA1934@americ> erk@americ.UUCP (Erick Parsons) writes: > >>Hmmm.. Seems to me that with a simple (?) OS mod we could have some sort >>of Script Bit password protection as an option. I'm not a programmer so >>I may be out in left field on this but the concept seems similiar to >>one that is already used on Unix systems. If it were possible would this >>stand up to these killer viruses ?? .... Just wondering.. > >Actually, this isn't easy on the Amiga. Unlike a typical multi-user >system (e.g., Unix), all tasks on the Amiga run with the same >privileges. Well, they say that 2.0 gets to break everything. Why not add a "priviledged user" mode that must be logged into with a password. When you first get your software it always boots in priviledged mode, but once you set up the password it will always boot in "underpriviledged" mode 8). After that any attempt to do virusy things requires the password. Of course, then you have tasks that run as "root" with all the priviledges of the priviledged user. I guess the favorite way for viruses to ride into such a system would be on the backs of applications that require priviledged status to be installed. --Steve ------------------------------------------------------------------------- {uunet,sun}!convex!swarren; swarren@convex.COM
martens@ketch.cis.ohio-state.edu (Jeff Martens) (09/17/89)
In article <1773@convex.UUCP> swarren@eugene.UUCP (Steve Warren) writes:
.Well, they say that 2.0 gets to break everything. Why not add a
."priviledged user" mode that must be logged into with a password.
.When you first get your software it always boots in priviledged
.mode, but once you set up the password it will always boot in
."underpriviledged" mode 8). After that any attempt to do virusy
.things requires the password.
I'm not up on the 68000, so someone may want to check me on this, but
I don't think the 68000 supports user/supervisor mode. So you can't
add this to the OS w/o adding extra hardware.
Well, you can add a supervisor mode without extra hardware (i.e., in
software), but a malicious program can bypass it at will.
-=-
-- Jeff (martens@cis.ohio-state.edu)
Reagan had brain surgery? They didn't let Igor pick out the brain
again, did they?swarren@eugene.uucp (Steve Warren) (09/17/89)
In article <61182@tut.cis.ohio-state.edu> Jeff Martens <martens@cis.ohio-state.edu> writes: >In article <1773@convex.UUCP> swarren@eugene.UUCP (Steve Warren) writes: > >>>Well, they say that 2.0 gets to break everything. Why not add a >>"priviledged user" mode that must be logged into with a password. >>When you first get your software it always boots in priviledged >>mode, but once you set up the password it will always boot in >>"underpriviledged" mode 8). After that any attempt to do virusy >>things requires the password. >> >I'm not up on the 68000, so someone may want to check me on this, but >I don't think the 68000 supports user/supervisor mode. So you can't >add this to the OS w/o adding extra hardware. The 68000 does implement user/supervisor modes. Now I don't know much about the asm. routines that access the drives, but if any part of these routines requires super status to work then the maverick routine can be locked out. However I was just rambling when I mentioned this possibility. It is a pretty obvious thing to do for security, so I am sure that if it is possible then someone is already working on it. I am not knowledgeable enough to say that it is definitely possible. --Steve ------------------------------------------------------------------------- {uunet,sun}!convex!swarren; swarren@convex.COM
a3@mindlink.UUCP (Dave Allen) (09/17/89)
Many thanks to Erick Parsons for his protection scheme on the C: directory. I
grabbed it with Snipit and put it right in my alternate CLI and it worked like
a charm. I would recommend it!
Here it is again for those that missed it.
cd c:
list > ram:temp lformat "protect %S -wd"
execute ram:temp
--
RSI-where WEDGES come from ||| Please note our new Address and Phone
and VCR Streamer Soon Too...|X| Number .....
1695 West 7th Ave ||| Old Name: Dave Allen
Vancouver B.C. Canada |||/// New Phone Number: (604) 737-7930
V6J 1S4 |||//
UseNet - uunet!van-bc!rsoft!mindlink!Dave_Allen
or - Dave_Allen@mindlink.UUCP
V/