Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA21552; Thu, 7 Jun 90 15:30:45 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA15367; Thu, 7 Jun 90 15:30:43 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA09338; Thu, 7 Jun 90 15:30:21 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa21316; 7 Jun 90 17:41 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Thu, 07 Jun 90 15:31:16 BST Message-Id: <$TGVGDBVHFKTK at UMPA> Subject: Virus-L vol 0 issue #0705 Virus-L Digest Tue, 5 Jul 88, Volume 0 : Issue #0705 Today's Topics stupid question Over the weekend problems with LISTSERV forwarded comments on OS/2 from David M. Chess Bill Murray's fears intro to CRC in 1,000 words... Receiving multiple files under VM/SP 5 ------------------------------ Date: Tue, 5 Jul 88 09:10:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Shawn V. Hernan" Subject: stupid question Can someone please tell me what CRC protection is? I don't know much about this sort of thing, and I just want to learn. Shawn Hernan, University of Pittsburgh please mail ( don't post) to valentin@pittvms.bitnet -------------------- Date: Tue, 5 Jul 88 09:35:22 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Over the weekend problems with LISTSERV Dear readers: Over the long (Fourth of July) weekend, our LISTSERV ran out of disk space for the VIRUS-L archive files, and subsequently stopped sending out any submissions. The problem has been fixed, but some submissions were held over the weekend, and some users may have had difficulties accessing the archive files. I do not believe that any submissions were lost, however. Once the LISTSERV was re-started this morning, all of the held submissions were then sent out to the list. I apologize for any inconveniences that this may have caused. Ken Kenneth R. van Wyk Hobbes: Wow, buried treasure right User Services Senior Consultant where you said it'd be! A Lehigh University Computing Center wallet full of money! Internet: Calvin: Yeah, it's Dad's. I buried it BITNET: here last week! -------------------- Date: Tue, 5 Jul 88 09:52:46 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded comments on OS/2 from David M. Chess Date: 1 July 1988, 09:38:00 EDT From: David M. Chess CHESS at YKTVMV To: VIRUS-L at LEHIIBM1 Subject: OS/2 and viruses I'd like to correct a little more misinformation, about OS/2 this time. Note that all this is just my understanding of the case, and in no sense Official Word from my employer (on the other hand, I'm pretty sure that I'm right!). It's very simple (just a line in CONFIG.SYS) to bring up OS/2 in a mode where there is no DOS box. DOS-only programs (including DOS-only viruses) will not run on a machine configured that way. So if you consider the DOS mode a risk, you can easily turn it off. On the other hand > the hardware memory management of the new processors will > defeat any attempt at cross-process infection by viruses of > the (in DOS terms) .COM/.EXE-hidden kind is not quite true, I don't think. COM/EXE viruses typically spread by altering other executables as they exist as files on disks. "hardware memory management" isn't relevant to this kind of infection (it protects memory, not disk images). Even the typcial disk-image protection only protects one's executable files against writes by *unauthorized* users and processes, but these viruses tend to spread Just Fine by way of *authorized* users and processes. (That is, if George is authorized to write to 25 executable files, and George gets an infected program and runs it, those 25 executables are going to get infected (and so are the executables of anyone else who runs them) no matter *how* "unbreakable" the disk protection is in the usual sense.) * Most traditional "security" and "protection" schemes provide little hindrance to viruses. DC Kenneth R. van Wyk Hobbes: Wow, buried treasure right User Services Senior Consultant where you said it'd be! A Lehigh University Computing Center wallet full of money! Internet: Calvin: Yeah, it's Dad's. I buried it BITNET: here last week! -------------------- Date: Tue, 5 Jul 88 14:20:48 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Bill Murray's fears You don't fear the wand; just the apprentice? What makes you think the apprentice isn't already out there? What I propose is intelligent use of viruses by professionals. The apprentice is irrelevant. The apprentice will go about his business whether others write useful viruses or not. And your whole viewpoint indicates a vast misconception of the relationship of viruses to other useful programming tools. Consider the biological viewpoint once again: we use only existing animals and plants as resources. We do not design them. This is where the biological analogy becomes useless. You seem to be arguing that it is dangerous to utilize gene-altered viruses for biological purposes. What about gene-altered cows? Aren't they just as dangerous in that they might have unpredictable effects through hormonal secretions in milk? Any gene-altering introduces new possibilities into an environment. But programs are ALL gene-altered. We're not discussing a brand new area of exploration such as gene-altering. We're merely discussing the use of one particular type of gene-altering. All programs are the result of human intervention. Why is it that we don't have accidental Trojans running rampant? It's because people write programs according to general guidelines such as "use files to store data". Programs that use whole disk tracks to store data regardless of the file system would do heavy damage to peoples' data. What I've been working up to is this: people need a set of guidelines they can use in the writing of beneficial viruses. Perhaps operating system support could even be used. Virus managers and whatnot. It is obvious that without any knowledge of infection-modes and environments, idiots will write stupid viruses. But I believe viruses should be regarded in the same way as "normal" programs. There are correct ways (apart from style) to write all programs; why not viruses? And don't come back with remarks about hubris, how I don't know anything, and why people won't follow guidelines. There ARE malicious people out there. They aren't writing beneficial viruses, and they don't care about beneficial viruses. The worst thing beneficial viruses could do is provide a vehicle for transport of malicious viruses. As if there aren't already enough vehicles. As to the question of unpredictable virus spreading, if the necessary virus protection methods ever get developed and installed, it won't be possible for ANY virus to spread uncontrollably. In the meantime, viruses are already strictly limited in their environments; as I said before, it's HARD to write viruses that can live in multiple environments. Computer environments are nothing like biological environments, where biological hardware has common elements between organisms. Even if two computers have the same processor, it will be difficult to get a virus to spread between them if they use different operating systems. And appropriate guidelines might precisely limit environments. By the way, things like CHRISTMA EXEC require gross stupidity and carelessness on the part of the target user. I don't think this case is a good model for any conclusions. The spread of this virus was the fault of the users as much as the writer, if not more. And this program is also a network virus, not a program-infecting virus, so once again it's a poor model. - Jeff -------------------- Date: Tue, 5 Jul 88 16:08:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Woody Subject: intro to CRC in 1,000 words... "Shawn V. Hernan" writes, >Can someone please tell me what CRC protection is? I don't know much >about this sort of thing, and I just want to learn. I think its appropriate to post a quickie overview of what CRC, or Cyclic Redundancy Check, protection can do for you. In essence, what one is trying to do is write down a number associated with your data that will help you know whether or not the data has been altered. Originally, it was intended as a means of telling whether or not a message was transfered correctly: if the CRC of the transmitted message wasn't a pre-agreed upon value, the sender knew to try again. So keep in mind that what it was designed for is to detect "random" errors in transmission. The simplest example of a CRC is what is called "even" parity. What the sender does is express his message in binary, count the number of 1's, and append a 1 or a 0 to his message depending upon if that number is odd or even. The reciever then looks at what he's recorded, and if the total number of 1's in the message is even, he is happy - throws away the last bit (the parity check bit) to recieve the message. If the total number of 1's is odd, then he asks the sender to retransmit. The problem with something this simple is that while it will tell you something is wrong if exactly one bit was garbled, it won't tell you if something is wrong if exactly two bits were garbled. (It detects the error only if an odd number of errors were made.) There is a natural way to improve this - instead of working with just [number of 0's and 1's mod 2] use something a bit more detailed. Suppose you are working with (base 10) numbers, and are trying to send a message to a friend. What you agree to do is send the number, and then send a single digit that is the sum of the digits, then summed as many times as needed to get a single digit. For example, suppose you wanted to send the number 2,147,483,648. Since 2+1+4+7+4+8+3+6+4+8 = 47 => 4+7 = 11 => 1+1 = 2, so you would send 21474836482. Your friend would strip off the last digit (2), and then add up the digits to make sure they added up to two. If he dropped a digit, it would be detected. If he changed a 2 to a 3, a 4 to and 8, and a 1 to a 9, it would be detected, etc. Mathematically, what you are doing is sending the remainder after dividing the original number by nine. (Nine is convienent because it is one less than the base.) The basic idea of CRC is to consider the message (or datafile) as one gigantic binary number, compute the remainder after dividing by a large binary number, tack that onto the end of the message, and send it. Choice of the "large binary number" is made upon certain grounds of primality or other properties: since you are mapping a larger set (all messages) into a smaller set (the residues) you want to ensure that all the residues are covered, they are all hit about equally often, no two messages are too "close", etc. If the adversary is random - i.e. a noisy telephone line or the like - and so changes are made to bits at random, then mathematically one can show this is an excellent form of protection. However, the malefic forces we are trying to protect against are not random. For example, suppose our virus is trying to scramble our data file, and knows we are going to use a parity check. As long as the virus is careful enough to always make EXACTLY an even number of changes, the CRC won't detect it. Similarly, if the virus changes our base ten number by a multiple of nine, we won't detect it. But if it changes our base ten number by something that ISN'T a multiple of nine, we WILL detect it. This is where the discussion of the "random CRC polynomial" comes in. The idea is that even if you restrict yourself to, say, a 16-bit check tacked on the end (where the odd-even scheme is just a 1 bit check) you have a great deal of leeway. You need to divide by a 16 or 17 bit number (so you have a 16 bit residue) and you want to use a prime number (for mathematical reasons) but you don't have to use a specific one. The virus can protect itself from detection by a single residue check, but it is very hard to protect from ALL the residue checks. For example, suppose we are going to do at most a 4 bit residue. We might record our message plus the remainder after dividing by 2, 3, 5, 7, 11, or 13. The virus changes message to message*. If we used all of the checks, then the residue of message* under 2, 3, 5, 7, 11, and 13 would have to be the same as under message - and to accomplish that, message* would have to be the same as message, up to 2*3*5*7*11*13 = 30,030. For four bit protection, we're able to assure integrity up to a fairly large degree of accuracy. (In particular, if we never sent more than 14 bit messages, we could be sure it was right!) Of course, we probably aren't going to use every one of those, but if we just picked one or two, and someone else chose a different one or two, etc, someone will detect the garbling. The mechanical details of CRC are rather interesting, and the mathematical details are quite beautiful (sitting squarely in number theory and field theory). Almost any upper division textbook on the general subject should have some information about it. It is quite accessible, and I'd recommend it to anyone curious about the subject. woody WWEAVER@DREW.bitnet -------------------- Date: Tue, 5 Jul 88 17:40:56 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Otto Stolz +49 7531 88 2645 Subject: Receiving multiple files under VM/SP 5 Hello folks, as we had discussed in VIRUS-L back in June, a file could inadvertently be RECEIVEd under CMS Release 4 (and the earlier releases) -- if this file was hidden as a second partition in a NETDATA file. This was unanimously considered a dangerous feature, as the hidden file could be some trojan horse, e.g. a PROFILE EXEC which would become active at the next LOGON. Meanwhile, I've tested this feature under CMS Release 4 and the official antidote of CMS Release 5. Thanks to everybody who helped with sending double-edged files and/or remarks to me. This note is meant as a digest of my findings. A NETDATA file containing a note and an attached data file can be sent from a MVS/TSO installation to a VM/SP installation by one of these commands: > TRANSMIT node.user DSN(fn.ft) MESSAGE > TRANSMIT node.user DSN(fn.ft) MSGDSNAME(msgfile) where: fn ft are the two components of the CMS file-id (up to 8 characters, each); node user are the two components of a BITNET or EARN address; msgfile is the MVS file-id of the note to be sent. Under Release 4, - -------------- the VM/SP user sees two files in one message, separated by a double line, when PEEKing at the NETDATA file before RECEIVing it (as one should always do :-). After issuing RECEIVE, he will receive a note AND a file -- and he will only be informed of the former. If a NETLOG file is kept, both the note and the data file will be logged therein, e.g.: > Note JAMES NOTE A0 recv from JAMES at XXXXXXX on 06/22/88 10:04:20 > File HELP EXTRACT A recv from JAMES at XXXXXXX on 06/22/88 10:04:20 sent as JAMES.TRANSMIT.HELP.EXTRACT For long files, which cannot be PEEKed in their entirety, this feature indeed constitutes a severe safety threat. The SENDFILE, NOTE, and RECEIVE commands use a module DMSDDL for sending/ receiving NETDATA format files. DMSDDL is documented in DMSDDL ASSEMBLE. I suppose, there's a modified DMSDDL MODULE available for node admini- strators from their nearest backbone LISTSERV, that will avoid receiving hidden files, in Release 4. With Release 5, - ------------- the RECEIVE command has been enhanced with a new triple of options: FULLPROMPT, MINPROMPT, and NOPROMPT. With FULLPROMPT, or MINPROMPT (default), RECEIVE will no longer write a file to the user's disk with- out his consent. As there have been added *new options* to the command syntax, I had expected to read about this enhancement in the "Release 5 Guide", or in "Using Release 5 Enhancements". But this change of the command syntax isn't mentioned there at all (perhaps a mere oversight -- or perhaps an inter-release enhancement not considered worth to be repeated in these manuals); on the other hand, some trifling details (e.g. look up RECEIVE in the index) are covered. I regret my rash, inappropriate remark of 21 June on this account. The new prompt allows the user to receive every partition of a NETDATA file under the name given, or under a new name chosen by the user, or to deny receiving it. If any partition of a file is not received, then the whole partitioned file remains in the user's reader. BTW, as any new prompt, also this one constitutes an incompatibility between Release 4 and Release 5: a disconnected machine running into an unforeseen prompt will stall (and will be forced after 15 minutes)! Furthermore, the PEEK command displays two message lines, containing the note's and the appended file's file-ids. I'll keep a file with a Release 5 sample dialogue for another fortnight. Anybody interested in it please drop me a short note. CP SPOOL PUN CONT is another CMS possibility to create multiple files in another person's reader, as mentioned before in VIRUS-L. Under Release 5, these files can be overcome: they can be RECEIVED into one single, harmless disk file. If they are read in using READCARD, however, they are separated into several single disk files; this happens under user control if he has specified the new FULLPROMPT or MINPROMPT options. As opposed to RECEIVE, READCARD defaults to the NOPROMPT option. Hence, if you want to be on the save side, be sure to use READCARD always with the MINPROMPT or FULLPROMPT option! Regrettably, the CMS DEFAULTS com- mand does *not* apply to the READCARD command. That's all for now. Best regards. Otto -------------------- *** end of Virus-L issue *** Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA25777; Tue, 12 Jun 90 06:25:36 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA12880; Tue, 12 Jun 90 06:25:33 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA03927; Tue, 12 Jun 90 06:25:02 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa09086; 12 Jun 90 10:59 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 12 Jun 90 11:01:56 BST Message-Id: <$TGVTCZHTCBKX at UMPA> Subject: Virus-L vol 0 issue #0705 Virus-L Digest Tue, 5 Jul 88, Volume 0 : Issue #0705 Today's Topics stupid question Over the weekend problems with LISTSERV forwarded comments on OS/2 from David M. Chess Bill Murray's fears intro to CRC in 1,000 words... Receiving multiple files under VM/SP 5 ------------------------------ Date: Tue, 5 Jul 88 09:10:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Shawn V. Hernan" Subject: stupid question Can someone please tell me what CRC protection is? I don't know much about this sort of thing, and I just want to learn. Shawn Hernan, University of Pittsburgh please mail ( don't post) to valentin@pittvms.bitnet -------------------- Date: Tue, 5 Jul 88 09:35:22 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Over the weekend problems with LISTSERV Dear readers: Over the long (Fourth of July) weekend, our LISTSERV ran out of disk space for the VIRUS-L archive files, and subsequently stopped sending out any submissions. The problem has been fixed, but some submissions were held over the weekend, and some users may have had difficulties accessing the archive files. I do not believe that any submissions were lost, however. Once the LISTSERV was re-started this morning, all of the held submissions were then sent out to the list. I apologize for any inconveniences that this may have caused. Ken Kenneth R. van Wyk Hobbes: Wow, buried treasure right User Services Senior Consultant where you said it'd be! A Lehigh University Computing Center wallet full of money! Internet: Calvin: Yeah, it's Dad's. I buried it BITNET: here last week! -------------------- Date: Tue, 5 Jul 88 09:52:46 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded comments on OS/2 from David M. Chess Date: 1 July 1988, 09:38:00 EDT From: David M. Chess CHESS at YKTVMV To: VIRUS-L at LEHIIBM1 Subject: OS/2 and viruses I'd like to correct a little more misinformation, about OS/2 this time. Note that all this is just my understanding of the case, and in no sense Official Word from my employer (on the other hand, I'm pretty sure that I'm right!). It's very simple (just a line in CONFIG.SYS) to bring up OS/2 in a mode where there is no DOS box. DOS-only programs (including DOS-only viruses) will not run on a machine configured that way. So if you consider the DOS mode a risk, you can easily turn it off. On the other hand > the hardware memory management of the new processors will > defeat any attempt at cross-process infection by viruses of > the (in DOS terms) .COM/.EXE-hidden kind is not quite true, I don't think. COM/EXE viruses typically spread by altering other executables as they exist as files on disks. "hardware memory management" isn't relevant to this kind of infection (it protects memory, not disk images). Even the typcial disk-image protection only protects one's executable files against writes by *unauthorized* users and processes, but these viruses tend to spread Just Fine by way of *authorized* users and processes. (That is, if George is authorized to write to 25 executable files, and George gets an infected program and runs it, those 25 executables are going to get infected (and so are the executables of anyone else who runs them) no matter *how* "unbreakable" the disk protection is in the usual sense.) * Most traditional "security" and "protection" schemes provide little hindrance to viruses. DC Kenneth R. van Wyk Hobbes: Wow, buried treasure right User Services Senior Consultant where you said it'd be! A Lehigh University Computing Center wallet full of money! Internet: Calvin: Yeah, it's Dad's. I buried it BITNET: here last week! -------------------- Date: Tue, 5 Jul 88 14:20:48 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: Bill Murray's fears You don't fear the wand; just the apprentice? What makes you think the apprentice isn't already out there? What I propose is intelligent use of viruses by professionals. The apprentice is irrelevant. The apprentice will go about his business whether others write useful viruses or not. And your whole viewpoint indicates a vast misconception of the relationship of viruses to other useful programming tools. Consider the biological viewpoint once again: we use only existing animals and plants as resources. We do not design them. This is where the biological analogy becomes useless. You seem to be arguing that it is dangerous to utilize gene-altered viruses for biological purposes. What about gene-altered cows? Aren't they just as dangerous in that they might have unpredictable effects through hormonal secretions in milk? Any gene-altering introduces new possibilities into an environment. But programs are ALL gene-altered. We're not discussing a brand new area of exploration such as gene-altering. We're merely discussing the use of one particular type of gene-altering. All programs are the result of human intervention. Why is it that we don't have accidental Trojans running rampant? It's because people write programs according to general guidelines such as "use files to store data". Programs that use whole disk tracks to store data regardless of the file system would do heavy damage to peoples' data. What I've been working up to is this: people need a set of guidelines they can use in the writing of beneficial viruses. Perhaps operating system support could even be used. Virus managers and whatnot. It is obvious that without any knowledge of infection-modes and environments, idiots will write stupid viruses. But I believe viruses should be regarded in the same way as "normal" programs. There are correct ways (apart from style) to write all programs; why not viruses? And don't come back with remarks about hubris, how I don't know anything, and why people won't follow guidelines. There ARE malicious people out there. They aren't writing beneficial viruses, and they don't care about beneficial viruses. The worst thing beneficial viruses could do is provide a vehicle for transport of malicious viruses. As if there aren't already enough vehicles. As to the question of unpredictable virus spreading, if the necessary virus protection methods ever get developed and installed, it won't be possible for ANY virus to spread uncontrollably. In the meantime, viruses are already strictly limited in their environments; as I said before, it's HARD to write viruses that can live in multiple environments. Computer environments are nothing like biological environments, where biological hardware has common elements between organisms. Even if two computers have the same processor, it will be difficult to get a virus to spread between them if they use different operating systems. And appropriate guidelines might precisely limit environments. By the way, things like CHRISTMA EXEC require gross stupidity and carelessness on the part of the target user. I don't think this case is a good model for any conclusions. The spread of this virus was the fault of the users as much as the writer, if not more. And this program is also a network virus, not a program-infecting virus, so once again it's a poor model. - Jeff -------------------- Date: Tue, 5 Jul 88 16:08:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Woody Subject: intro to CRC in 1,000 words... "Shawn V. Hernan" writes, >Can someone please tell me what CRC protection is? I don't know much >about this sort of thing, and I just want to learn. I think its appropriate to post a quickie overview of what CRC, or Cyclic Redundancy Check, protection can do for you. In essence, what one is trying to do is write down a number associated with your data that will help you know whether or not the data has been altered. Originally, it was intended as a means of telling whether or not a message was transfered correctly: if the CRC of the transmitted message wasn't a pre-agreed upon value, the sender knew to try again. So keep in mind that what it was designed for is to detect "random" errors in transmission. The simplest example of a CRC is what is called "even" parity. What the sender does is express his message in binary, count the number of 1's, and append a 1 or a 0 to his message depending upon if that number is odd or even. The reciever then looks at what he's recorded, and if the total number of 1's in the message is even, he is happy - throws away the last bit (the parity check bit) to recieve the message. If the total number of 1's is odd, then he asks the sender to retransmit. The problem with something this simple is that while it will tell you something is wrong if exactly one bit was garbled, it won't tell you if something is wrong if exactly two bits were garbled. (It detects the error only if an odd number of errors were made.) There is a natural way to improve this - instead of working with just [number of 0's and 1's mod 2] use something a bit more detailed. Suppose you are working with (base 10) numbers, and are trying to send a message to a friend. What you agree to do is send the number, and then send a single digit that is the sum of the digits, then summed as many times as needed to get a single digit. For example, suppose you wanted to send the number 2,147,483,648. Since 2+1+4+7+4+8+3+6+4+8 = 47 => 4+7 = 11 => 1+1 = 2, so you would send 21474836482. Your friend would strip off the last digit (2), and then add up the digits to make sure they added up to two. If he dropped a digit, it would be detected. If he changed a 2 to a 3, a 4 to and 8, and a 1 to a 9, it would be detected, etc. Mathematically, what you are doing is sending the remainder after dividing the original number by nine. (Nine is convienent because it is one less than the base.) The basic idea of CRC is to consider the message (or datafile) as one gigantic binary number, compute the remainder after dividing by a large binary number, tack that onto the end of the message, and send it. Choice of the "large binary number" is made upon certain grounds of primality or other properties: since you are mapping a larger set (all messages) into a smaller set (the residues) you want to ensure that all the residues are covered, they are all hit about equally often, no two messages are too "close", etc. If the adversary is random - i.e. a noisy telephone line or the like - and so changes are made to bits at random, then mathematically one can show this is an excellent form of protection. However, the malefic forces we are trying to protect against are not random. For example, suppose our virus is trying to scramble our data file, and knows we are going to use a parity check. As long as the virus is careful enough to always make EXACTLY an even number of changes, the CRC won't detect it. Similarly, if the virus changes our base ten number by a multiple of nine, we won't detect it. But if it changes our base ten number by something that ISN'T a multiple of nine, we WILL detect it. This is where the discussion of the "random CRC polynomial" comes in. The idea is that even if you restrict yourself to, say, a 16-bit check tacked on the end (where the odd-even scheme is just a 1 bit check) you have a great deal of leeway. You need to divide by a 16 or 17 bit number (so you have a 16 bit residue) and you want to use a prime number (for mathematical reasons) but you don't have to use a specific one. The virus can protect itself from detection by a single residue check, but it is very hard to protect from ALL the residue checks. For example, suppose we are going to do at most a 4 bit residue. We might record our message plus the remainder after dividing by 2, 3, 5, 7, 11, or 13. The virus changes message to message*. If we used all of the checks, then the residue of message* under 2, 3, 5, 7, 11, and 13 would have to be the same as under message - and to accomplish that, message* would have to be the same as message, up to 2*3*5*7*11*13 = 30,030. For four bit protection, we're able to assure integrity up to a fairly large degree of accuracy. (In particular, if we never sent more than 14 bit messages, we could be sure it was right!) Of course, we probably aren't going to use every one of those, but if we just picked one or two, and someone else chose a different one or two, etc, someone will detect the garbling. The mechanical details of CRC are rather interesting, and the mathematical details are quite beautiful (sitting squarely in number theory and field theory). Almost any upper division textbook on the general subject should have some information about it. It is quite accessible, and I'd recommend it to anyone curious about the subject. woody WWEAVER@DREW.bitnet -------------------- Date: Tue, 5 Jul 88 17:40:56 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Otto Stolz +49 7531 88 2645 Subject: Receiving multiple files under VM/SP 5 Hello folks, as we had discussed in VIRUS-L back in June, a file could inadvertently be RECEIVEd under CMS Release 4 (and the earlier releases) -- if this file was hidden as a second partition in a NETDATA file. This was unanimously considered a dangerous feature, as the hidden file could be some trojan horse, e.g. a PROFILE EXEC which would become active at the next LOGON. Meanwhile, I've tested this feature under CMS Release 4 and the official antidote of CMS Release 5. Thanks to everybody who helped with sending double-edged files and/or remarks to me. This note is meant as a digest of my findings. A NETDATA file containing a note and an attached data file can be sent from a MVS/TSO installation to a VM/SP installation by one of these commands: > TRANSMIT node.user DSN(fn.ft) MESSAGE > TRANSMIT node.user DSN(fn.ft) MSGDSNAME(msgfile) where: fn ft are the two components of the CMS file-id (up to 8 characters, each); node user are the two components of a BITNET or EARN address; msgfile is the MVS file-id of the note to be sent. Under Release 4, - -------------- the VM/SP user sees two files in one message, separated by a double line, when PEEKing at the NETDATA file before RECEIVing it (as one should always do :-). After issuing RECEIVE, he will receive a note AND a file -- and he will only be informed of the former. If a NETLOG file is kept, both the note and the data file will be logged therein, e.g.: > Note JAMES NOTE A0 recv from JAMES at XXXXXXX on 06/22/88 10:04:20 > File HELP EXTRACT A recv from JAMES at XXXXXXX on 06/22/88 10:04:20 sent as JAMES.TRANSMIT.HELP.EXTRACT For long files, which cannot be PEEKed in their entirety, this feature indeed constitutes a severe safety threat. The SENDFILE, NOTE, and RECEIVE commands use a module DMSDDL for sending/ receiving NETDATA format files. DMSDDL is documented in DMSDDL ASSEMBLE. I suppose, there's a modified DMSDDL MODULE available for node admini- strators from their nearest backbone LISTSERV, that will avoid receiving hidden files, in Release 4. With Release 5, - ------------- the RECEIVE command has been enhanced with a new triple of options: FULLPROMPT, MINPROMPT, and NOPROMPT. With FULLPROMPT, or MINPROMPT (default), RECEIVE will no longer write a file to the user's disk with- out his consent. As there have been added *new options* to the command syntax, I had expected to read about this enhancement in the "Release 5 Guide", or in "Using Release 5 Enhancements". But this change of the command syntax isn't mentioned there at all (perhaps a mere oversight -- or perhaps an inter-release enhancement not considered worth to be repeated in these manuals); on the other hand, some trifling details (e.g. look up RECEIVE in the index) are covered. I regret my rash, inappropriate remark of 21 June on this account. The new prompt allows the user to receive every partition of a NETDATA file under the name given, or under a new name chosen by the user, or to deny receiving it. If any partition of a file is not received, then the whole partitioned file remains in the user's reader. BTW, as any new prompt, also this one constitutes an incompatibility between Release 4 and Release 5: a disconnected machine running into an unforeseen prompt will stall (and will be forced after 15 minutes)! Furthermore, the PEEK command displays two message lines, containing the note's and the appended file's file-ids. I'll keep a file with a Release 5 sample dialogue for another fortnight. Anybody interested in it please drop me a short note. CP SPOOL PUN CONT is another CMS possibility to create multiple files in another person's reader, as mentioned before in VIRUS-L. Under Release 5, these files can be overcome: they can be RECEIVED into one single, harmless disk file. If they are read in using READCARD, however, they are separated into several single disk files; this happens under user control if he has specified the new FULLPROMPT or MINPROMPT options. As opposed to RECEIVE, READCARD defaults to the NOPROMPT option. Hence, if you want to be on the save side, be sure to use READCARD always with the MINPROMPT or FULLPROMPT option! Regrettably, the CMS DEFAULTS com- mand does *not* apply to the READCARD command. That's all for now. Best regards. Otto -------------------- *** end of Virus-L issue ***