Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Repeated attacks by a computer cracker have virtually shut down New York's
Public Access Networks Corp., better known as Panix. The attacks have
overwhelmed the computers' capacity to respond to requests for an
``electronic handshake'' by sending as many as 150 bogus requests a second.
``This is the first major attack of a kind that I believe to be the final
Internet security problem,'' says a Lucent Technologies Internet security
expert, who says he "has been waiting" for just such an event. Internet
computers have no quick way of distinguishing these bogus requests from real
ones, and even when security software is upgraded to ease the problem, the
crackers could respond with even more intense assaults. ``There's going to
be the usual arms race,'' predicts the Lucent security expert, between
improved security measures and crackers' ability to disable them. (*Wall
Street Journal*, 12 Sep 1996, B1)
[RISKS received various messages on this item, including from
Fernando Pereira <pereira@research.att.com>. PGN]
*The Washington Post* [also] did an excellent story about it on 12 Sep 1996. AP and others also picked it up. There's a statement on PANIX's web page, http://www.panix.com. We don't have the resources to answer a lot of technical questions right now because we've got our hands full, but if anyone who is familiar with the attack has ideas for possible defenses, we can be reached at staff@panix.com. -S. Simona Nass staff@panix.com PANIX Public Access Internet [At its heart, this is an unsolvable problem in general. There are some useful things you can do against very specific types of attacks, but there are too many types of attacks for a comprehensive defense. The best you can do in the near future might be to have some early-detection capabilities to detect emerging attacks and then reconfigure dynamically accordingly. In the long run, it might be desirable to have more secure systems overall, which would require (among other things) nontrivial authentication (i.e., NOT fixed passwords) for any resource that might be abused. However, without draconian measures, denials of service will always be possible, whether they occur accidentally or intentionally. De RISKibus non disputandum est? PGN]
MobilCom, a subsidiary of German TeleKom (since 100 years monopolist onn telephone communication in Germany, with its monopoly ending in 1998) publicly offers 100,000 DM to a telephone hacker who is able to communicate at the expense of the (national) number 0171-3289966. The related chipcard is said to be safely stored in lawyer`s office. In an attempt to paint this dubious offer somewhat "politically correct", the successful hacker will have to donate his earnings to a social institution of his(her) choice. Background of this offer is a recent magazine report informing the public that German hackers know relevant details of the encryption algorithm (A5) implemented in GSM mobile phones; this algorithm was always quoted to be "secure" by GSM producers and service providers. According to the magazine`s informant (a 22 year old male), he had informed German Telekom (provider of D1 mobile phone services) with details in May 1995. TV reports next week may "demonstrate" of how such knowledge may be used. The story is "old vine in new bottles". Since GSM was specified in a joint European (essentially UK/French/German) exercise, material (though restricted to producers of GSM hardware and service personnel) were "available" in early 1990s, including the PSL code on which the encryption hardware is based. GSM methods implement an authentication process with which the caller`s chipcard-based key is compared with the database of applicable keys; after successful authentication, a session key is generated which is used by the encryption algorithm (A5) to "unbreakably" encrypt the communication. (Btw: for export to non-European countries, a weaker algorithm A5x is available; this approach is similar to NSAs policy of exporting US crypto methods :-) "Security" of A5 and, more interestingly, A3/A8 (the algorithms for authentication and generation of session key) are "secure because they are not publicly known" (well-known principle of "Security by Obscurity"). This assumption was wrong as independent experts got copies of GSM algorithms (written in PSL) and could determine the effective length. Among others, Ross Anderson reported (on Internet) in 1994 about insecurity of A5 (he even published a C version of this algorithm which could have been used in determining weaknesses). In 1993, an expert group in a UK university had easily cracked about 75% of the 114-bit key protecting communication. GSM technology is used in 3 different German mobile phone services (D1, D2 and E-Plus) with more than 4,5 mio users. On the background of the media reports, users should look at details (when telephone with which number how long) more regularly, as falsification of individual chip cards may now become a new hacker sport, with the generous offer of Mobil Com. Klaus Brunnstein (September Friday 13,1996)
I've recently been reading Donald Norman's latest book, _Things That Make Us Smart_ (ISBN 0-201-62695-0 pbk). Instead of reviewing it, though, I'm going to illustrate how it has changed my thinking by criticizing a portion of an article I read last night in my partner's Wesleyan alumni magazine (Vol. LXXIX No. 1, Summer 1996). "Which Way?" (author unclear) talks about the work of Scott Plous (Associate Professor of Psychology) and specifically his book _The Psychology of Judgement and Decision-Making_ (McGraw-Hill, 1993). Here's a quote from the article: Plous indicates how easily decision-making can go awry with an example drawn from a thirty-nine question survey at the beginning of his book: "Linda is 31 years old, single, outspoken, and very bright. She majored in philosophy. As a student, she was deeply concerned with issues of discrimination and social justice, and also participated in antinuclear demonstrations." "Which is more likely," he asks, "That Linda is a back teller, or that Linda is a bank teller and is active in the feminist movement?" Most people guess that Linda is more likely to be a bank teller *and* a feminist; that choice seems to be intuitively correct. Yet adding detail to a scenario does not increase its likelihood. The more general statement — that Linda is a bank teller — poses the fewest restrictions and is the probable. Plous's point: Mathematical probability, not intuition, should guide this choice. To do otherwise is to use a flawed decision-making process that increases the likelihood of error. Before reading Norman's _Things That Make Us Smart_ (TTMUS), I would have simply nodded at the quote and continued reading. This time, though, my immediate (almost experiential ;-) reaction was, "This is wrong!" TTMUS contains a large section on the fallacy of confusing formal logic with "logic of language". The six pages starting at 227 point this out particularly clearly. In the quote above, much is made of Linda's activism; when choosing an answer, "bank teller" is almost certainly dismissed by most people as being irrelevant to the story — this would be made much clearer by asking whether Linda is more likely to be a bank teller or a computer programmer. Which bring us back to RISKS: in user interface design, we must be careful which information we present to the user and how we present it, because the user will *not* interpret the information according to the rules of formal logic. I strongly recommend that everyone here pick up a copy of TTMUS; with any luck, it will change the way you think, too. Aahz (@netcom.com)
[Background:] I am a pilot who flys a small airplane equipped with a GPS satellite navigation system approved by the Federal Aviation Administration for use in clouds (IFR). I have been experiencing in flight warnings that the system has been (flagged) unusable somewhere around 1% of the time it is used. Lest you think this is trivial, you can consider driving a car whose windshield went opaque 1% of the time you were driving. So far I have been told the following: 1) Some early GPS's were shipped with a defective Digital Signal Processing chip. This was corrected in later units. 2) Several different models have substantially similar computational algorithms. 3) When sufficient satellites are received, some units discard barometric altitude information for purposes of position calculations. A satellite declaring itself "healthy" is NEVER discarded automatically in these units. Erroneous computed GPS altitude is a good warning indication of a bad position fix. Usually barometric altitude is more accurate than the altitude civilian GPS units compute from satellites (because of SA/AS). 4) US DOD mandates testing GPS units in its inventory against jamming. This testing has resulted in interference to civilian units to a radius of some 100 miles. 5) Commercial GPS satellite simulators are widely available. 6) Were one to hook up a GPS satellite simulator to an amplifier and antenna, one could disable many civilian GPS's at will. IFR certified units would give RAIM warnings, but would not give usable navigation information. (RAIM is a consistency check of computed positions found generally only in IFR certified GPS units) 7) All GPS units lacking automatic satellite elimination capability are likely to be similarly vulnerable. Presently, automatic satellite elimination is mostly on GPS intended for sole means of navigation overwater. 8) VFR (not certified by the FAA for use in clouds) only GPS units are not required to indicate that their computed positions are erroneous. 9) Because GPS is extremely accurate almost all the time, many pilots have fallen into the habit of trusting GPS positions without cross checking against other means of navigation, or even against the computed errors displayable by the GPS unit itself. I would greatly appreciate knowing of any errors in this information and/or additional information relevant to civilian GPS navigation use. I think one can assume that a pilot getting a wrong position at night in the mountains, or no position in clouds in the mountains could have a problem. Jim Easton 4364 Bonita Rd., No. 166 Bonita, CA, 91902-1421 Tel: (619) 548-0138 FAX: (619) 470-8616
The 9 Sep 1996 issue of *Aviation Week* contains the first section of the inquiry board's report on the Ariane 5 failure. The title is "Ariane 5 Report Details Software Design Errors", and is on pages 79-81. I particularly liked the board's comment in the final paragraph: "The board is in favor of the opposite view, that software should be assumed to be faulty until applying the currently accepted best practice methods can demonstrate that it is correct." Alan E. Frisbie, Flying Disk Systems, Inc., 4759 Round Top Drive Los Angeles, CA 90065 1-213-256-2575 Frisbie@Flying-Disk.Com
Mr. Dorsett, in RISKS-18.43, and Mr. Ladkin, in RISKS-18.44, disagree with my call for discretion in public speculation about airline disasters, in RISKS 18.42. Both argue that open and lively dissuasion of the issues can have real value. True, but neither man offers substantial reasons why such discussions aren't equally valuable if conducted more discretely. I also think their arguments also show single-mindedness in that airline safety and finding the correct conclusion are the only factors to consider. Publicity about airline accidents makes people fear flying. Some fraction of those people will choose to drive to their destination, using a much more dangerous mode of transportation. Public discussions could increase airline safety but result in a net decline in total public safety. I can't prove that the net change is positive or negative, nor do I believe anyone else can prove it. Nevertheless, neglecting the secondary consequences of public debates is shallow. I may also have overstated my call for discretion in my original message. I have no wish to stifle serious discussion among technically oriented interested parties. I merely object to it being done in such a public forum. Surely we can arrange more closed forums or e-mail list servers. Total secrecy and security aren't necessary, but a little more discretion is. If the NTSB is indiscreet, it too should be censured. It should not be interpreted as a signal that it is OK for us to be indiscreet too. The Internet, Usenet in particular, is one of the most public forums ever invented. This is a particularly inappropriate place for sensitive subjects. American daytime TV has been filled with talk programs that show people discussing the most sensitive and sensational subjects imaginable. The public seems to enjoy the voyeurism. I expect that nearly all of us detest this development. Is it surprising to realize that we may be unwittingly engaging in analogous activities? Finally, I must take strong exception to one part of what Mr. Dorsett wrote: - The author of _Unheeded Warning_ notes his concerns (as a pilot) of the safety of the ATR-72 in icing conditions long prior to the eventual October 1994 crash. His book notes explicit steps taken to keep the issue alive in the media and thereby bringing political pressure to bear on the NTSB and FAA to maintain appropriate perspective in both the investigation and regulation of the aircraft. This pressure arguably resulted in FAA mandates to adjust the design of the anti-ice system on the airplane. Similar pressure was absent after a similar crash in 1988 in the Italian Alps. If the facts were as Mr. Dorsett states, I think this is deplorable. Just think what it means to "keep the issue alive in the media and thereby bringing political pressure to bear". This subjects questions of engineering safety to the same kind of handling as the O.J. Simpson trial. It stirs up fear among the general public to give the issue emotional strength and appeal. The word that describes precisely that set of circumstances is demagoguery. Demagoguery is never praiseworthy. (My apologies to non-native English speakers. I understand that demagoguery is one of the least translatable words in the entire English language, but in this case, it is the only word that fits.) Mr. Dorsett expands on that theme when he says "It's a political world, not a technical one." I say no, never. Mixing demagoguery and science is irresponsible. It must never be tolerated. Dick Mills http://www.albany.net/~dmills
> No doubt there are other risks that also deserve sensitive treatment, but to > me airplane disasters stand out most clearly. Funny, but I read that item, and it struck me that it applied almost exactly to railway accidents. Clive D.W. Feather Associate Director, Demon Internet Ltd. <clive@demon.net> Director CityScape Internet Services Ltd. <cdwf@cityscape.co.uk> +441813711138 [Well, when I read that item, it struck me that it applies rather broadly to almost everything that RISKS has tried to do for the past 11+ years. Your humble and obedient *Designated Holist*, PGN]
As it happens, the *Columbia Journalism Review* web site is currently carrying a 1990 feature on the difficulties of reporting on aircraft accidents before all the facts are in. See http://www.cjr.org/boot_reprint/boot.html Mark Jackson - http://www.alumni.caltech.edu/~mjackson
Bear Giles points out that Win95's handling of passwords is annoying. What's
more, it points out the poor system design because there is no correlation
between system, screen saver, or on-line login passwords. As has been
pointed out by many, Win95 is an unsecure operating system.
I learned this in a most amusing way recently, when I was setting up my new
Hitachi notebook computer. The first task was to install Windows 95 and
select a password. After rebooting, I decided to see just how secure it was
and typed the password incorrectly several times. Each was rejected, but
then I clicked on "Cancel" in the dialog box and — lo and behold! I was
granted access.
Jack B. Rochester, Joshua Tree Communications, Cherry Hill Farm, Cherry Hill
Road, Grafton, New Hampshire 03240 jrochester@endor.com 1-603 523 8350
[*Which Is Of Endor?* PGN]
RISKS-18.42 and 18.43 discussed the possibility of passwords being found in core files. While it is certainly a risk, there are mitigating factors: 1) a program has to crash at a time when it still has a password in memory, 2) an attacker must have access to the resulting core file, and 3) the attacker must inspect or copy the core file before the user (or possibly the system) gets rid of it. A much worse risk, and one which is unbelievably still with us, is the storage of cleartext passwords in "password-protected" files. There is no need for a program to take an unusual action (crash) at a particular time, nor is there usually any time limit, since the resulting file is usually desired by the user and kept around for some time, if not permanently. This risk was brought to mind recently when I had a need to break into a password-protected file that is part of a product made by the company I work for. The file is used to install certain macros in another company's product and the macros are password-protected to prevent accidental changes by end users. We (the development team) knew what the password was supposed to be, but it wasn't working. On an off-chance, I opened the file in a text editor and started scrolling through the mostly binary contents. Toward the end of the file, I found a string which matched the supposed password but differed in case, which both turned out to be the password and explained the problem. Bad enough that the password was stored in cleartext, but it caught my eye because it was preceded by the cleartext string "Password:"! For us, this lack of security doesn't matter, since the password protection is intended only to discourage accidents and our support group will give the password to any user who needs it. Others may not be so lucky, and of course who knows what other currently-shipping products may suffer from the same risk? --James
This is a known bug in the older (3.4 ??) versions of Delrina's WinFAX. Robert Sargent 423-671-0273 Pager: 800-365-4578 cisco Systems, Inc.
Not only does the receiver see the credit card number, a lot of fax machines store those credit numbers as part of the record of what numbers were dialed when.
>From: Edward N Kittlitz <kittlitz@world.std.com> >According to my rusty memory and 2 minutes of Altavista searching, ... This is correct. See 47 USC 227(d) (requiring footprint) and 227(b) (barring unsolicited commercial faxes). [>...] The federal appeals court in California, the Ninth Circuit, upheld the fax-ban provision of the TCPA in _Destination Ventures_ (1995) on precisely this cost-shifting rationale. For an article of mine discussing TCPA (and concluding that while it does not now apply to junk e-mail, it could constitutionally be expanded to do so), see http://techweb.cmp.com/net/issues/036issue/036law.htm >From: David Allen <dallen@nr.infi.net> >... I think the court erred in its comparison in a critical >way when it cited First Amendment protection for spam. I think it's crucial to point out that the court *did not* base the TRO on free speech law, contrary to the suggestion of some RISKS readers. Even Cyberpromo's lawyer has stated that their argument was based on theories like tortious interference with contract, and not on any supposed First Amendment right. I agree that the TRO was improperly issued, but I think too much has been read into it. It's simply the judge's way of preserving the status quo so he doesn't have to think hard about the issues until trial. (It's crucial in this respect to remember that the TRO was issued in the context of an ongoing lawsuit between the parties.) Mark Eckenwiler eck@panix.com
Perhaps AOL should offer its users a special "spam-free" service. Certainly, if users request that AOL filter their incoming e-mail, then the purveyors of [ugly]-mail spams would have no leg[alism] to stand on. - Andrew Greene
I've been using the following legal information, which I picked up from
another mailing list (Keith Bostic's /dev/null list), in my responses to
junk e-mail these days. So far I haven't yet received junk e-mail on my
home computer while it had a printer attached, but one of these days...
Under US Code Title 47, Sec.227(b)(1)(C):
"It shall be unlawful for any person within the United States to
use any telephone facsimile machine, computer, or other device
to send an unsolicited advertisement to a telephone facsimile
machine"
A "telephone facsimile machine" is defined in Sec.227(a)(2)(B) as:
"equipment which has the capacity to transcribe text or images
(or both) from an electronic signal received over a regular
telephone line onto paper."
Under this definition, an e-mail account, modem, computer and printer
together constitute a fax machine.
The rights of action are as follows. Under Sec.227(b)(3)(B):
"A person or entity may, if otherwise permitted by the laws or
rules of court of a State, bring in an appropriate court of
that State --
(A) an action based on a violation of this subsection or the
regulations prescribed under this subsection to enjoin
such violation,
(B) an action to recover for actual monetary loss from such a
violation, or to receive $500 in damages for each such
violation, whichever is greater, or
(C) both such actions. If the court finds that the defendant
willfully or knowingly violated this subsection or the
regulations prescribed under this subsection, the court
may, in its discretion, increase the amount of the award
to an amount equal to not more than 3 times the amount
available under subparagraph (B) of this paragraph."
For the full legal text USC Title 47, Section 227, see:
http://www.law.cornell.edu/uscode/47/227.html
Dan Franklin dfranklin@bbn.com
I was motivated (as I'm sure others were) by the RISKS-18.43 blurb about
Lexis-Nexis and their "legal community" serving database (the tiny quote is
from their pleasant-sounding recording of the day). I first called in to
their 800 line on the afternoon of 12 Aug, 96. I sat and listened to their
recording for about half an hour while I was working on something else. I
had to get up, so I decided to take the nice recording-lady up on her offer
of leaving a message. When I tried, the voice mail system declared that the
voice mailbox was full and no further messages were being taken. The nice
recording-lady promptly hung up on me. I tried again this morning (13 Aug
1996), and the recordings have all changed and are now instructing those
concerned with removal of names from the database to make all requests "in
writing". They give instructions to mail to their address (given in
RISKS-18.43) or to fax them the request at (513) 865-1930 (different from
RISKS-18.43). Just wanted to let people know that the procedure appears to
have changed, due no doubt to the overwhelming responses they have most
likely received.
Jim Walters jwalters@spock.resd.honeywell.com
["Kevin Johnsrude" <kevinj@roguewave.com> reported that
he gave up after being on hold for half an hour, finally
voicemailing (as requested) only his full name and address --
before the voicemailboxoverflowedwithtoomanyrequests.
Peter.J.Scott@jpl.nasa.gov also noted the change to fax/snailmail. PGN]
Please report problems with the web pages to the maintainer