Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!bruce!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.arch Subject: Re: Randomised Instruction Set Computer Keywords: viruses Message-ID: <3199@goanna.cs.rmit.oz.au> Date: 8 Jun 90 10:40:28 GMT References: <3131@goanna.cs.rmit.oz.au> <14060@burdvax.PRC.Unisys.COM> Followup-To: comp.arch Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 90 In article <14060@burdvax.PRC.Unisys.COM>, barry@PRC.Unisys.COM (Barry Traylor) writes: > In article <3131@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > >The trouble with that was that once you managed to jemmy (sic) that ^^^^^^^^^^^ I wrote "jemmy". Barry Traylor, apparently without checking a dictionary, added "(sic)". here we go: jemmy (N,Count,^tool,=crowbar) A *jemmy* is a heavy metal bar which is curved at one end and which is used as a tool especially by criminals for forcing things open; used in British English. E.g. "Any filing cabinet will yield to a jemmy and a bit of brute force." To jemmy something is to force it with a jemmy. Clearly the metaphor in "jemmy that lock" is "use special tools to break something open with criminal intent". No "(sic)" needed. > Both of these require breaking PHYSICAL security. True. But _once_ is all it took. For example, when Burroughs installed their *lovely* machines in the New Zealand Universities, they managed to leave behind at Auckland University, as a bookmark in a publically accessible manual, a punched card with the magic letters NZUP on it. "New Zealand Universities Project", I thought, _surely_ this can't be the super-user password. But it _was_. Compiled myself a little ESPOL program and the world was _wide_ open ever after. Only had to use the password once too. (Mind you, I was working at the Computer Centre at the time and told them what I was doing. Hacker yes, cracker no.) > BTW, part of our security has always seemed to rely on the relative > obscurity of our systems, although they have been strengthened to not rely > on this anymore ;->. Then there was the really fun bug (which was very promptly fixed; Burroughs were pretty prompt to warn about things like that, and we had sources) where if you knew what you were doing you could arrange for a code file to contain zeros (no privilege needed); the operating system _really_ trusted the compilers, and if you ran such a code file the operators had all the fun of rebooting (and rereading the card decks which had been put into queues but not run). > One thing you don't mention is that there is no way to > modify the in-core image of an executing code file, i.e. any modifications > to the address space cannot affect the in-core code. This turns out not to be the case. Words in the A series are tagged with 3-bit tags. Instruction words have tag 3, and no odd tag is writable by "ordinary" instructions. But in the B6700 there were special instructions one could use, and you didn't need to be in a special mode or ring or have any special privilege to use them. The system relied on the fact that the ordinary compilers (Fortran, Algol, Cobol, PL/I, Pascal, WFL, and so on) didn't generate those instructions. But ESPOL did. Several Universities had load-and-go compilers (Auckland University had a rather nice Fortran) which worked by creating a DIRECT ARRAY, filling it with code, and then calling a library routine to set the tags. After running the program, one called the library routine again to clear the tags, and Bob's your uncle. Obviously the library routine had to check who was calling it or that would have been a really fatal loophole. There's an important distinction here between what the _hardware_ can do and what the *complete* hardware/sofware system will _let_ you do. This is why it was so important for compiler privilege to be controlled. And then there were little notices "if you install compiler X with feature Y enabled [specifically, non-unity increments in DO VECTORMODE and analogues thereof] all warrantees are void". > >But even then, things like the sendmail bug could still be exploited. > >The "trust this code file" system call would presumably insert checksums > >and such into the file as well. > How is this any more secure than the A Series method? Sorry, I was thinking about the B6700 and the crash-on-zero-code-files bug; mixing up security and integrity. > >Anyway, is this idea crazy enough to work? _Can_ a virus spread when each > >program appears to use a different instruction set? > For both questions: uh... I don't think so (my personal opinion). Can't have it both ways. If a virus can't spread in such a scheme, then the scheme works. (If there is a trusted immutable kernel which enforces a code/data separation so that running programs not only can't change code, they can't see it either, then the unscrambling can be done when code pages are brought in rather than at run time, so most of the overhead vanishes, as does the need for special hardware. Oh well.) -- "A 7th class of programs, correct in every way, is believed to exist by a few computer scientists. However, no example could be found to include here."