sean@ms.uky.edu (Sean Casey) (01/04/88)
The designers at Commodore Amiga should have never made it possible to
install a virus in such a way. One *cannot* rely on ignorance as
protection against programmers with bad intentions.
This is another example of where some behaviour of a machine has been
kept secret, and people have suffered for it. If something is well
documented, it is subject to more scrutiny, and is more likely to be
noticed as a problem or security bug.
I suggest to the CATS people that a future version of kickstart specifically
clear out the auto-boot vector or whatever it is you call that magic memory
location that can give the machine to a program after warm boot and
before workbench.
I suggest that people stop flaming the virus people. It's a waste of
bandwidth, and it makes them happy because they know they did their job
right. It's not going to help one bit. As a matter of fact, it's just
showing potential virus writers how infamous their programs can be.
Sean
--
-- Sean Casey sean@ms.uky.edu, sean@UKMA.BITNET
-- (the Empire guy) {rutgers,uunet,cbosgd}!ukma!sean
-- University of Kentucky in Lexington Kentucky, USA
-- "Inconceivable!"jim@coplex.UUCP (Jim Sewell) (01/04/88)
In article <7967@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: > >The designers at Commodore Amiga should have never made it possible to >install a virus in such a way. One *cannot* rely on ignorance as >protection against programmers with bad intentions. > Interesting how you put the blame off on the developers of the Amiga! I am sure that if you studied aspects of development and MAINTENANCE of a computer system you would find quite a good reason to put in the gap in the boot sector of the disk. It has to do with improvements to the computer's operating system without totally rewriting the whole thing. This allows us to run 1.1 programs on our 1.2 kickstart systems. The guys did all they could within reason and I for one think they deserve a hats-off instead of "it's all your fault." attitudes. >I suggest that people stop flaming the virus people. It's a waste of >bandwidth, and it makes them happy because they know they did their job >right. It's not going to help one bit. As a matter of fact, it's just >showing potential virus writers how infamous their programs can be. > Shhhh! If flaming the virus writers will make them happy, what do you think flaming C-A will do for their egos? If you want a conversation to die, just sit back and watch it; don't add to it. I have no desires for the conversation to stop about the viruses, but also would like to see the flames die a bit. >Sean > >-- >-- Sean Casey sean@ms.uky.edu, sean@UKMA.BITNET >-- (the Empire guy) {rutgers,uunet,cbosgd}!ukma!sean >-- University of Kentucky in Lexington Kentucky, USA >-- "Inconceivable!" Jim Sewell "Make knowledge free!" mit-eddie!bloom-beacon!jim
sean@ms.uky.edu (Sean Casey) (01/05/88)
In article <265@coplex.UUCP> jim@coplex.UUCP (Jim Sewell) writes: >In article <7967@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >> >>The designers at Commodore Amiga should have never made it possible to >>install a virus in such a way. One *cannot* rely on ignorance as >>protection against programmers with bad intentions. >> > Interesting how you put the blame off on the developers of the Amiga! >I am sure that if you studied aspects of development and MAINTENANCE of a >computer system I not only have studied it. It's my job. That's how I pay the rent. >you would find quite a good reason to put in the gap in the >boot sector of the disk. It has to do with improvements to the computer's >operating system without totally rewriting the whole thing. This allows us >to run 1.1 programs on our 1.2 kickstart systems. The guys did all they could >within reason and I for one think they deserve a hats-off instead of "it's all >your fault." attitudes. You missed the point entirely. The complaint was *not* about the gap in the boot sector on the disk. That really has nothing to do with it. The complaint was that they made it possible for a program to grab control of the machine after warm boot and before workbench (reread my article carefully, I *hate* being misinterpreted). I assume the point of this was to allow a hook for some kind of debugger. Now quite frankly, I like the idea. But, as I pointed out earlier, it is a horrible security bug. Commodore knew this, and elected to keep the information secret as a means of protection. My other point was that one cannot rely on secrecy as protection against malicious programmers. This was a mistake, but one that can be cleared up. Commodore could release a "more secure" kickstart that would not pass control to the hook address. If one really wanted a hook available, perhaps holding down a mouse key during reboot would enable the hook. It's really a trivial solution, but it does require a new release of Kickstart, which is a royal pain for everyone. The question is: When will the viruses become such a problem that they overshadow the difficulty involved in a new Kickstart? Finally, remember that most Amigans don't have Usenet access. Most of them probably don't even read Amiga magazines. What will they do when their disks are suddenly being erased? Sean -- -- Sean Casey sean@ms.uky.edu, sean@UKMA.BITNET -- (the Empire guy) {rutgers,uunet,cbosgd}!ukma!sean -- University of Kentucky in Lexington Kentucky, USA -- "My feet are wet."
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (01/05/88)
In article <7967@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >The designers at Commodore Amiga should have never made it possible to >install a virus in such a way. [ ... ] > >I suggest to the CATS people that a future version of kickstart specifically >clear out the auto-boot vector or whatever it is you call that magic memory >location that can give the machine to a program after warm boot and >before workbench. > This won't work. I refer you to Bart Whitebook's (or was it Bob Burns?) little hack called "Oreo". This installs a new library using the romtags-in-RAM facility, which is initialized at boot time. The program's function was to, at random intervals, pop up a system requester asking for a cookie. C-A is not about to remove this feature, since it is how new libraries are installed, and how old libraries are replaced. In fact, this is probably how many ROMmed users will receive many 1.2.1 and 1.3 enhancements; the libraries will be loaded into RAM, locked in, and preserved across reboots. An Amiguy may be able to provide more details. Incidentally, I've restricted distribution on this to North America. No sense in giving anything away to whoever's listening.... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
cmcmanis%pepper@Sun.COM (Chuck McManis) (01/05/88)
In article <7967@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >The designers at Commodore Amiga should have never made it possible to >install a virus in such a way. One *cannot* rely on ignorance as >protection against programmers with bad intentions. Sean, let's not cut off our nose to spite our face shall we? The 'features' that make viruses possible are the same ones that make it possible to run MINIX on your Amiga, notably, when you have a ROM based OS and want to boot something different than what is in the ROM. This also makes disk based updates to the ROM software possible. I think the features of this system far outweigh the potential for abuse. The solution to the whole thing is fairly simple and has other benefits as well... First, rewrite install (or get Bryce's for free) so that it writes predictable data to the boot blocks. Then calculate the appropriate CRC for that data and make it available too. Then write a simple program that runs at boot time that checks the CRC of the bootblock before booting, it should also check the Read() and Write() addresses for the trackdisk.device (their in ROM so they shouldn't change until a new release comes out.) Finally, the program should check the CoolCapture vectors and see if they have changed (again they normally point to ROM so they too are constant). Finally, if any of these three checks fail you should put up either a system requester (or better an Alert) and warn the user but give them the option of continuing or aborting the boot. (You probably want to check the SysRequest Vectors as well. Note that they could be hard coded because they are in ROM again. This is very bad programming (using hard numbers like this) but could be modified for new ROM releases easily (hell it could read in a text file for each ROM release) and would be a pretty effective cure for the lingering virus. >I suggest that people stop flaming the virus people. It's a waste of >bandwidth, and it makes them happy because they know they did their job >right. It's not going to help one bit. As a matter of fact, it's just >showing potential virus writers how infamous their programs can be. This is very true. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
ain@s.cc.purdue.edu (Patrick White) (01/06/88)
>release a "more secure" kickstart that would not pass control to the
How about a patch for all us that have stuck with kickstart on disk?
CATS? Bryce? anybody?
-- Pat White
UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421
U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906markv@uoregon.UUCP (Mark VandeWettering) (01/06/88)
In article <7977@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >>>The designers at Commodore Amiga should have never made it possible to >>>install a virus in such a way. One *cannot* rely on ignorance as >>>protection against programmers with bad intentions. >The complaint was that they made it possible for a program to grab >control of the machine after warm boot and before workbench (reread my >article carefully, I *hate* being misinterpreted). I assume the point >of this was to allow a hook for some kind of debugger. Now quite >frankly, I like the idea. But, as I pointed out earlier, it is a >horrible security bug. Commodore knew this, and elected to keep the >information secret as a means of protection. My other point was that >one cannot rely on secrecy as protection against malicious >programmers. The entire concept of security in a personal computer is kind of silly. I have protection on computers at work, and accept it because I like to be protected against other people making havoc out of the computer. When I come home, I want a computer that I can modify/hack/destroy willy nilly. The ability to install a debugger/virus/whatever is a NEAT idea, not (necessarily) a harmful one. >This was a mistake, but one that can be cleared up. Commodore could >release a "more secure" kickstart that would not pass control to the >hook address. If one really wanted a hook available, perhaps holding >down a mouse key during reboot would enable the hook. Not a bad solution, I would accept something like that. As for commodore's use of "secrecy" to prevent virus's from being created, if true, I think they found out that a. People are quite clever b. They probably should have told everyone about it so they could be prepared. markv
andy@cbmvax.UUCP (Andy Finkel) (01/06/88)
In article <1401@uoregon.UUCP> markv@drizzle.UUCP (Mark VandeWettering) writes: >In article <7977@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >>>>The designers at Commodore Amiga should have never made it possible to >>>>install a virus in such a way. One *cannot* rely on ignorance as >>>>protection against programmers with bad intentions. >As for commodore's use of "secrecy" to prevent virus's from being >created, if true, I think they found out that > > a. People are quite clever > b. They probably should have told everyone about it so they > could be prepared. Uh, guys ? Look in the RM Kernal manual , Appendix L in the white ones, (not sure where in the A-W ones, but its there) , called Disk Format information. Look at the first section, called The Boot Process. This is not quite what I'd call a secret. -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Any sufficiently advanced technology is indistinguishable from a rigged demo." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
sean@ms.uky.edu (Sean Casey) (01/07/88)
In article <3091@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: (Regarding the "boot vector" that allows a program to take over the machine before the workbench boot code can...) >Uh, guys ? Look in the RM Kernal manual , Appendix L in the white >ones, (not sure where in the A-W ones, but its there) >, called Disk Format information. Look at the first section, called >The Boot Process. This is not quite what I'd call a secret. I've got the Addison Wesley "Amiga ROM Kernel Reference Manual: Exec" manual on my lap. On page C-8 begins a section called "THE BOOT PROCESS". This section describes what happens once the ROM kernel starts reading in the boot sectors off disk. I see no mention whatsoever of a memory location that execution can be optionally handed to before it starts reading the disk. Perhaps someone can enlighten me as to exactly where in this section the memory location is documented. Sean -- -- Sean Casey sean@ms.uky.edu, sean@UKMA.BITNET -- (the Empire guy) {rutgers,uunet,cbosgd}!ukma!sean -- University of Kentucky in Lexington Kentucky, USA -- "My feet are wet."
andy@cbmvax.UUCP (Andy Finkel) (01/08/88)
In article <7993@g.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >In article <3091@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >I've got the Addison Wesley "Amiga ROM Kernel Reference Manual: Exec" >manual on my lap. On page C-8 begins a section called "THE BOOT PROCESS". > >This section describes what happens once the ROM kernel starts reading >in the boot sectors off disk. I see no mention whatsoever of a memory >location that execution can be optionally handed to before it starts >reading the disk. Who said anything about a memory location ? That has nothing to do with it. Read the first 4 words of the second paragraph carefully. (In my copy, its "The code is called") If its not clear from this, then rejoice, for you will be writing no boot virus programs :-) -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Any sufficiently advanced technology is indistinguishable from a rigged demo." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
sean@ms.uky.edu (Sean Casey) (01/08/88)
In article <3104@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: [regarding the "auto-boot vector" or whatever it is called...] >Who said anything about a memory location ? That has nothing to >do with it. Read the first 4 words of the second paragraph >carefully. (In my copy, its "The code is called") Ah, but from what has been told to me, it has everything to do with it. If I have the virus in my machine, and I warm boot with a clean, write enabled workbench disk, the clean boot sector gets loaded and I have no problems. Right? Wrong. The way it was explained to me is that the virus gets hold of the machine before the boot sector can be read in, and in fact corrupts the good boot sector. If what was described in "THE BOOT PROCESS" was all there was to it, then warm booting with a secure disk would be safe. Sean -- -- Sean Casey sean@ms.uky.edu, sean@UKMA.BITNET -- (the Empire guy) {rutgers,uunet,cbosgd}!ukma!sean -- University of Kentucky in Lexington Kentucky, USA -- "My feet are wet."
louie@trantor.umd.edu (Louis A. Mamakos) (01/09/88)
Stop all of the speculating on what the SCA virus does, and what it doesn't.
Take the UUENCODED virus which was posted a little while ago, kermit it
down to your amiga and disassemble it.
The easiest way to do this is to write a program that just loads the thing
in memory, and then us Manx DB to disassemble it. Happily, the SCA virus
is written using PC relative references (in most places), so it is easy to
disassemble.
Something like:
main() {
char *where;
FILE *f;
where = malloc(1024);
f = fopen("virus", "r");
fread(where, 1024, 1, f);
printf("Virus loaded at %lx\n", where);
getchar();
fclose(f);
exit(0);
}
In one evening, I disassembed and commented the thing, except for the
diddling around it does to put up the message where it fools with the
RastPort and Bitmap structures.
It is actually quite instructive to see how the boot process works, and how
the various vectors in the system are used.
Before you ask, no I won't post the disassembled version of the virus to the
net. No point in making it any easier to modify it and create yet another
version. If you really want to know what it does, look into it! Let's try
to reduce the clutter in this newsgroup on this subject. It is getting boring
and tiresome.
If you want to feel safe and have that fuzzy warm feeling, don't run j-random
binaries or boot disks of stuff that you don't have the sources to. I only
run stuff on my machine that has been purchased or that I've compiled from
source code. Just wait until the first virus comes out that is installed
from just *running* a program, rather than booting a disk.
Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programmingmp1u+@andrew.cmu.edu (Michael Portuesi) (01/09/88)
sean@ms.uky.edu (Sean Casey) writes: > If I have the virus in my machine, and I warm boot with a clean, write > enabled workbench disk, the clean boot sector gets loaded and I have > no problems. Right? Wrong. The way it was explained to me is that > the virus gets hold of the machine before the boot sector can be read in, > and in fact corrupts the good boot sector. > > If what was described in "THE BOOT PROCESS" was all there was to it, then > warm booting with a secure disk would be safe. So, if you boot with a foreign disk, make sure you cold start the machine before you insert your normal boot material. There are PD programs that let you do a coldstart without powering the machine down. But don't blame the people at Commodore for making it "easy" to produce a virus. As other members of the net have pointed out, there are other possible schemes for making an Amiga virus, and designing the system to be safe from every conceivable scheme is about equivalent to solving the halting problem (something I *don't* expect the Commodore engineers to do). VCheck says my Amiga is clean, and I wear condoms when I compute :-). --M -- Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "little things remind me of you...cheap cologne and that damn song too!" --The Flirts, "Jukebox"
jim@coplex.UUCP (Jim Sewell) (01/09/88)
In article <7977@g.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) writes: > > You missed the point entirely. The complaint was *not* about the gap > in the boot sector on the disk. That really has nothing to do with it. > > The complaint was that they made it possible for a program to grab > control of the machine after warm boot and before workbench (reread my > article carefully, I *hate* being misinterpreted). I assume the point "Sincere apologies to you, Sean," he said while removing foot from mouth. Sorry for misinterpreting you. > > Finally, remember that most Amigans don't have Usenet access. Most of > them probably don't even read Amiga magazines. What will they do when > their disks are suddenly being erased? > Just today I looked at our Amiga Society of Kentucky (ASK) PD software disk and noticed a version of vcheck1.0 and a notice from a guy in Switzerland saying that the virus was not harmful, etc... I commend our PD librarian on getting us many great PD programs, but have to wonder what affect his delay in getting Usenet feeds will have on the membership. "I'd like to change the world, but don't know what to do." Actually, I'd like to see a public Usenet site, but understand the problems and costs with doing such. Does anyone have any idea of how to provide this info to the "public-at-large"? I welcome any e-mail responses and will summarize them if I get enough. ============================================================================== Jim Sewell "Make knowledge free!"