I'm only a few miles from yesterday's wreck. The known facts to date: The Amtrak was ""passing"" a stopped freight by crossing over to the other track, then crossing back. For whatever reason, the inbound MARC had NOT stopped [short of the 2nd crossover], & the two passenger trains collided head-on. This is EXACTLY the worst case accident scenario railroad signal systems & procedures have been designed to prevent; designed so for many decades. [When WAS the first RR block signal installed?] Yet it happened anyhow..... The RISK? Whether despite, or because, or coincidental to CSX's centralized dispatch & track management system; or the weather, or human error; sometimes, alas, old Risks cannot be eliminated, only constrained one day at a time.....
Recently I was asked to type up a resume for a friend and provide both a hard copy and a copy on disk. I typed it up using Microsoft Word. Before I gave her the final copy, I wanted to double-check one piece of information. Since I didn't want to wait forever while Word came up, I sent it to a simple text editor. I was shocked to find that buried among the text and code were several URLs that I had visited while cruising the Web! One of the addresses included my username and password for a foreign electronic paper that I subscribe to, and one, to my embarrassment, was http://www.whitehouse.gov. <Blush> None of them showed up when viewed with Word, and if I hadn't checked it with the text editor, I wouldn't have known they were there. Fortunately, it was no big deal, but the security and privacy risks are obvious. I have no clue how they ended up embedded in my Word document. I don't use Microsoft Assistant for Word (or whatever it's called). The only other thing I can think of is that I was cruising the Web at the same time I had the document open and somehow they ended up there. Nonetheless, you can bet I will be checking all my Word documents with a text editor before sending them out to anyone!
I've noticed that if my DOS prompt icon in Windows '95 is "depressed" on the taskbar, but not in the foreground, and I have screen savers disabled in its properties, the screen saver will not come up. This could be a security risk: If I have my screen saver password protected, and the desktop is showing, I would assume (and did assume) that my screen saver will come up. I wonder if this is a "feature" in that as long as the item is selected on the taskbar the screen saver would not come up, even though it is not fullscreen, or if this is a bug. My advice: Make sure the program on the taskbar is a windows app. or nothing at all is "depressed". Matthew Delaney N2MDB firstname.lastname@example.org ax.25: n2mdb@k2sk.#eny.ny.usa.na Finger for PGP key http://www.j51.com:80/~delaney/
> ... Using his finely tuned, VR trained reflexes, he immediately > crashes into the other car. Is this risk plausible? Not only plausible, but IMHO, quite real. See the extensive work on flight simulators, etc., for the details and risks. Can I draw RISKS readers attention to 'New Scientist' 27Jan pp 34-37, "Virtually Real, Really Sick." This give some very sobering food for thought on VR systems. Paul
ETHICOMP96 The Third International Conference on Ethical Issues of Information Technology Hosted by Facultad de Informatica, Universidad Pontificia de Salamanca en Madrid, in association with Centre for Computing and Social Responsibility, De Montfort University, UK and Research Center on Computing and Society, Southern Connecticut State University, USA Preliminary Notice and Call for Papers Two international conferences have been held which address the social and ethical issues surrounding the world of computing. The first was in the USA at Southern Connecticut State University (NCCV91) and the second (ETHICOMP95) was at De Montfort University in the UK. Both conferences have been recognised as milestone events. In order to sustain momentum and advance resulting research, a third conference ETHICOMP96 is to be held in Madrid. The intention is to bring together international scholars to consider current and future developments of IT and resulting social and ethical issues. Madrid is an ideal location for this conference, being a major European capital with a high cultural, academic and commercial reputation. The overall theme of ETHICOMP96 will be the value of IT to society and the likely impacts upon society's values. The intention is to include papers which provide practical guidance on socially and ethically sensitive applications of IT -- the social benefits and drawbacks of using IT. In parallel to this will be the presentation of case studies which raise or illustrate significant ethical problems of IT usage (1) in the workplace, (2) in education, (3) at home and (4) in leisure. Papers and case studies are invited from relevant disciplines such as philosophy, computer science, information systems, law, social sciences, business and government. Papers and case studies with a multi-disciplinary perspective are particularly welcome. See full details in English or Spanish by accessing http://www.cms.dmu.ac.uk/CCSR/ccsr/conf/ccsrorgconf.html For further information contact: Centre for Computing and Social Responsibility School of Computing Sciences De Montfort University The Gateway Leicester LE1 9BH UK Telephone +44 116 257 7475 Fax +44 116 254 1891 E-mail email@example.com
>... This is receiving, not transmitting. For the purposes of the law, "transmission" means "sending of data", more or less. Your http server is "transmitting" the info to the visitor's browser. >I know this is semantics at this point; Beware the difference between common-parlance semantic differences and legal terms-of-art semantic differences. In common parlance, "obscenity" isn't as bas as "indecency" to many people, since a "swear-word" is an "obscenity". Legally, it's not an obscenity, but an indecency, and obscenity is more stringently proscribed than indecency. The understandable lack of knowledge of legal terms of art (don't feel bad - a lot of lawyers don't know the difference between obscenity and indecency) is the primary means by which the fundamentalist groups behind the CDA have managed to increase supposed public support of it. They perpetually uses the terms interchangeably, and then suggest that the CDA will prevent the "exploitation of children" ( - Cathy Cleaver debating Jerry Berman on tv the other day). To state it as a RISK: It is easy for fundamentalist groups to gain more acceptance of the idea of censoring online communications, by combining loaded terms that imply something else ("exploitation of children" is very emotional a phrase, and implies child pornography, rape and abuse - subjects not in any way relevant to the CDA) with confused terms that most of the public didn't have a legal understanding of even before the confusion was introduced (e.g. "indecency", "obscenity" and "pornography", which is legally a synonym of "obscenity" as are "harmful to minors" and, as far as we can tell, "patently offensive".) Stanton McCandlish Electronic Frontier Foundation Online Activist firstname.lastname@example.org http://www.eff.org/~mech/
After I saw D'Oliveiro's notes (see below) on the "?" wildcard and its use within Win95, I did some testing with Visual Basic 3.0, Visual Basic 4.0, Access 2.0, and Access 7.0 (aka Access 95). The KILL statement (used to delete a disk file) is implemented in three different ways! Start with 6 files in a directory (mine was C:\TEMP): TEST9.TXT, TEST91.TXT, TEST92.TXT, TEST931.TXT,TEST932.TXT, and TEST.TXT. VB 4.0 and Access 7.0 using KILL "C:\TEMP\TEST9?.TXT" will delete two files: TEST91.TXT and TEST92.TXT. VB 3.0 using KILL "C:\TEMP\TEST9?.TXT" will delete three files: TEST91.TXT, TEST92.TXT, and TEST9.TXT. Access 2.0 using KILL "C:\TEMP\TEST9?.TXT" will delete two files: TEST.TXT, and TEST9.TXT. (I don't understand this one!) I could not find any note of the differences in the help files or the Developer Network CD (Jan 96). So it is left up to your user to find out! Isn't this a RISK where deleting a file from code has a different effect when you switch versions? It really demonstrates that you can't trust converted code, you still have to test each and every feature.
I just read something disturbing in PC Magazine, which I have verified is true. In Windows 95, the "?" wildcard is treated inconsistently in file specifications: sometimes it means "exactly one character", and other times it means "at most one character". Suppose you have a directory with two files in it, one named XX and one named XXX. The command "DIR XX?" will only show the second file, but "DEL XX?" will delete both files! One dependable rule in every computer system I have ever used prior to this, is that a wildcard specification will always expand to the same set of filenames, regardless of what command you use it in. Wind95 not only breaks this rule, it breaks it in the worst way: the "delete" command, given the same wildcard specification, will delete a larger set of files than the less harmful "directory" command will display! This means you can no longer use the technique of checking a wildcard specification with DIR to make sure it will only affect the right files, before letting it loose with DEL. Lawrence D'Oliveiro, Computer Services Dept, University of Waikato Hamilton, New Zealand +64-7-856-2889 email@example.com
An interesting technicality in the discussion of inconsistent wildcard expansion in Windows 95. In MS-DOS the DIR and DEL commands are not programs, the are "internal commands" which are processed by the command interpreter (COMMAND.COM). I don't have a copy of Windows 95 handy, but I would assume that this is still the case. Thus we do not have a case of different programs interpreting wildcards differently, but the same program (the command interpreter) interpreting them differently in a different context. Michael Smith firstname.lastname@example.org Emmenjay Consulting http://www.hutch.com.au/~emmenjay/emmenjay.html
A couple of people have pointed out a typo in my posting on this subject - the limit on command-line length on the old UNIX system I used was 512 bytes, not 51. Now there's a RISK - keyboards that won't type what you mean. Peter Curran email@example.com
In 17.75, Otto Stolz points out that the UNIX 'ls' command will list more files than the 'rm' command would remove if (shell-globbed) wildcards are used: ls x* lists all files, directories, _and the contents_ of directories beginning with the character 'x', while rm x* will remove only files beginning with 'x' (not directories). There is an important issue at work here: That universal wildcard expansion (as is done under the UNIX shell) does not equivale universal argument interpretation. 'ls' and 'rm' interpret their arguments in very different ways; 'rm' won't delete directories, and 'ls' lists the contents of directories. (ls -d could be used to circumvent the second of these). While this may be obvious, I think it's important to point out that pre-globbed wildcards simply produce a list of words as command-line arguments; this in no way implies that the program using those arguments should interpret them in a particular way. This can be exploited in both good and bad ways; for example, if a directory were to contain a file named '-i', then 'rm *' in that directory would expand to 'rm -i ....' (assuming '-i' is the first expanded filename in the wildcard). The -i switch to rm forces interactive mode where the user must answer 'y' or 'n' to delete each file. I know some people use this to 'protect' certain directories from accidental 'rm *'. However, one could also create a file named '-rf'... This exercise is left to the reader. Don't be fooled: UNIX syntax is in no way based on hard rules---conventions are the dominating factor. Needless to say there's also no guarantee that a particular shell expands the '*' and '?' wildcards as one would normally expect. The various tradeoffs here have to do with where the conventions are embodied: In Win32 systems, they are within the application itself; under UNIX, they are generally within the shell. Which would you rather have---'invisible' (and unalterable) semantics within each particular application or 'treatable' semantics enforced by your shell (and applied to all applications)? The RISK here has to do with software conventions and non-obvious behavior of (apparently) mundane software. Conventions such as these permeate UNIX, and I know more than one UNIX neophyte who has been bitten by them. M. Welsh, firstname.lastname@example.org
I'd like to make a few clarifications about the FV credit card attack demonstration program, as there have been a few misunderstandings in the way it was described on RISKS. At the moderator's request, I'm keeping this as short as possible; full details are at http://www.fv.com/ccdanger, or by personal mail. -- Our "overstated" claims were overstated by those who described them. We do not claim that there's no possible technical defenses; in fact, we enumerate several such defenses, and also outline four broad classes of commerce systems that do not have this flaw, only one of which is our own. I do apologize for some probably-misleading wording, however. -- It is true that the threat goes beyond commerce mechanisms. If word processor vendors were telling the world "everyone should type credit card numbers into word processors" we would probably have focused on word processors, too. -- Antiviral and other prophylactic software can only protect against the LAST attack of this kind, not the next one. The infection vector can be a socially-engineered Trojan Horse, and once installed the program does nothing that categorically distinguishes it from a screen saver or keyboard accelerator. -- The complexity of our attack has been overstated. Credit card numbers can be recognized with about 8 lines of C code. My favorite approach to the traceless dissemination of the data can be done in about 20 lines of C code. The hardest part is the installation and the actual keystroke interception! The DLL for our current Windows implementation is under 16K. -- It is true that the most likely detection would be by the sheer volume of traffic on the back-channel, but there are also simple traffic-gating techniques. And users should never get errors back from a well-implemented distribution channel. -- Address verification isn't the answer. It can be very effective in preventing a certain class of *uses* of stolen credit card numbers, but there are many other ways to use such numbers, especially for terrorism/vandalism. -- Current credit card fraud detection is inadequate. Nearly all of the traditional fraud detection mechanisms are based on pattern analysis, and the criminals typically get nabbed after repeated uses of the same stolen card number. This is not very helpful against an attack that yielded enough card numbers to treat them as one-time tokens. -- My most serious disagreement with Olin Sibert is on the question of the easy infiltration of home machines. Up to now, there has been no motivation for serious criminals (organized crime, terrorists) to build malicious computer programs. Organized crime and terrorist groups have both the means and, in a future of Internet commerce, the motivation to mount such an attack. A sufficiently unsophisticated user can easily be tricked into downloading and running a malicious program. The essence of the FV attack on credit card numbers is statistical; we don't need to infect the machines of the most sophisticated users, as long as we can infect a lot of unsophisticated users' machines. ***The true and neglected underlying risk is that of system security being compromised by unsophisticated end-users. Today, we live in an Internet where people consider "cut and paste" a technical term, and where users complain of getting so lost in a web site that they have no way of escape other than rebooting their machine. (Yes, these are both based on real customer service incidents at First Virtual.) The permanent insecurity of the consumer platform is an under-appreciated reality of 1996. The bottom line: a commerce mechanism that presumes that the consumer's machine has not been compromised is a commerce mechanism that will be easily defeated on the bulk of consumers' machines. I hope these clarifications shed some light on what FV is and is not claiming about the risks of credit cards on the Internet. I think there's a very serious set of risks here, and I hope that those risks haven't been overshadowed, in the technical community, by the confusion that comes from trying to alert the wider population to the fact that such risks exist. If I'm right, then the first symptom the banks are going to have of such an attack will be an increase in the overall rate of credit card fraud, with NO evidence linking this phenomenon back to the Internet. I think that's a huge potential risk. Anyone interested in more details on the flaw FV has been demonstrating can find more information at http://www.fv.com/ccdanger. -- Nathaniel Nathaniel Borenstein <email@example.com> Chief Scientist, First Virtual Holdings FAQ & PGP key: firstname.lastname@example.org
I think the response above from First Virtual is sufficiently laden with concessions to show the debate for what it really is: a difference of opinion over the importance of various unmeasurable factors, such as: - The likely competence (or lack thereof) of potential attackers; - The difficulty of translating laboratory prototype software into a secret, widely-distributed, error-free, mass-market consumer product; - The ease with which stolen credit card numbers can be turned into value for an attacker (and risks posed by such activity); - The availability and effectiveness of all types of counter-measures (the dismissal of prophylactic software is arguably unimaginative); - The effectiveness of existing fraud-detection measures; ... and so forth. If we make assumptions at one end of the scale, society could collapse in a fortnight. Under other assumptions, nothing much happens. Much depends on those assumptions--and the real RISK is that a one-sided presentation can alarm without educating.
Please report problems with the web pages to the maintainer