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…
At this week's ACM97, The Next 50 Years of Computing, the Association for Computing (ACM) has given its first Paris Kanellakis Theory and Practice Award to six people incisively involved in the creation of public-key cryptography: Leonard Adleman (University of Southern California), Whitfield Diffie (Sun Microsystems), Martin Hellman (Stanford University), Ralph Merkle (Xerox PARC), Ronald Rivest (MIT), and Adi Shamir (The Weizmann Institute of Science), ``for the conception and first effective realization of public-key cryptography. The idea of a public-key cryptosystem was a major conceptual breakthrough that continues to stimulate research to this day, and without it today's rapid growth of electronic commerce would have been impossible.'' The award is named in memory of Paris Kanellakis, whose tragic death in December 1995 cut short a distinguished research career. This event is most worthy of notice in RISKS, because the systematic use of public-key crypto has extraordinarily high potential for dramatically reducing many of the security risks so frequently discussed here -- including loss of confidentiality (e.g., through its use in the distribution of conventional crypto keys and in key management generally) and integrity (through its use in cryptographic checksums, digital signatures, and authentication). Congratulations!
[Once again the disability community takes the lead in decrying the GUI revolution, which has gone way too far. Interfaces should be measured in terms of how often one must move a hand from keyboard to mouse and back, in terms of the swapping delays that real users experience when endless little dialogue boxes have to pop up to accomplish anything, and in terms of the provision of meaningful keyboard equivalents for the functions that real people use. All the widespread PC OS's fail miserably at these criteria in my opinion. Except for a small number of crucial functions like copy and paste, I find myself being much more productive with a Unix command interface and my beloved Emacs text editor than with either the Mac or Windows interfaces and mouse- intensive WYSIWYG editors. Phil Agre] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help@weber.ucsd.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Wed, 26 Feb 1997 12:24:37 -0500 (EST) >From: "Jay Hersh aka Dr. Beer (SM)" <drbeer@doctorbeer.com> To: voice-users@cuckoo.hpl.hp.com Subject: Working with Quicken I am currently using Quicken version 6 and previously used version 5. What I have found is that many of the "buttons" do not register their names with the Windows API and therefore DragonDictate can't automatically build macros on the fly to access these. This situation is worse with Quicken 6 than it was with version 5. Overall I believe this is a significant problem within the application development industry, i.e. moving functionality more and more towards mouse oriented interfaces, using visual icons inside buttons rather than plain text and/or failing to register the text with the Windows API. Additionally more and more of the functionality of applications accessible through mouse usage lacks hot key equivalents making it difficult to create macros by hand (macros based on keystroke combinations are more reliable in general than those base on mouse positioning and button clicks since they are independent of window resizing). Another obnoxious trend is that of popping up windows for each bit of functionality rather than subsuming them within the current window. For instance Quicken does an automatic backup which puts up 5 different windows, one after another, each after you hit the enter key for the current one. This is annoying because you must wait each time for the new window to map onto the screen before you can hit the enter key. This also makes developing a macro to accomplish this difficult because of the timing issues involved in waiting for the next window to map before issuing the next enter key. I believe that we as a community, along with Dragon Systems, Kurzweil, and IBM as companies need to stop these trends now. The more applications become developed around an assumption of the mouse as a primary user interface the more difficult utilizing the current generation of speech recognition technology (which is based upon synthetic keystroke generation) will become, and the more a barrier is presented to us and especially to those with severe enough handicaps that hands free usage is their only option. Jay This is a key free document, no keyboards were harmed in its creation. (The DragonDictate speech recognition system, the CIC handwriting recognizer, or some combination was used.)a [Suggested to RISKS by "Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com>]
The Nevada state Senate has introduced a bill that would make sending unsolicited ads directly to e-mail accounts a misdemeanor. "Most e-mail users pay for their service, so unsolicited e-mail is like receiving direct mail with postage due," says the Senate's majority leader, who notes the bill is modeled on a previous measure that bans unsolicited advertising over fax machines. California, Virginia and Connecticut are considering similar measures, but the Nevada legislature is widely viewed as closest to passing the ban. (*St. Petersburg Times*, 3 Mar 1997; Edupage, 4 March 1997)
In a post to comp.lang.java.security and BUGTRAQ, Major Malfunction & Ben
Laurie claimed on 25 Feb 1997 to have discovered a couple of new Java-based
attacks. See:
http://www.alcrypto.co.uk/java/
The first "less serious hole" allows a miscreant "to gain access to
information from the client machine which would normally be considered
'secure'." This works with the Netscape Navigator. Though their attack
works as advertised on the page, there is really nothing new to this
discovery. On their page, they say:
>All we can do is log the real identity of a client machine, despite
>most precautions they might take to prevent us from doing
>so... [firewalls, proxies, SOCKS, anonymizer...]
>we take one call to InetAddress.getLocalHost()...
And there you have it. Since the applet is running on the client machine
and it is allowed to call InetAddress.getLocalHost(), it can find out the
client machine's IP. Though this may surprise some users (especially those
using the anonymizer), the ferreting-out of this information is not really a
dangerous new invasion of privacy. The Web is currently not a private
place. This demonstration serves to bring that point home. Your Browser is
probably a blabbermouth. It is a clever move to use Java to look up an IP
at the client end through several proxy layers, but not all that clever.
The second attack is more disturbing. This one works only for the Microsoft
Internet Explorer. They claim "this loophole allows an attacker to connect
to any TCP/IP port on the client's machine." That's a bit of an
overstatement, but interesting information about listening ports can be
gathered (for possible later use). This may leave a firewalled host more
susceptible to standard TCP/IP based attacks. That's bad.
The Java Security Manager usually disallows port scanning behavior. But the
crackers use the well-known trick of sticking some Java code in the
browser's cache and later executing it through a file: URL (using frames in
the usual way.) Since Microsoft's cache layout is transparent, this attack
works. This is an interesting variation on the Hopwood slash-and-burn
attack described on page 69 of the book I wrote with Felten "Java Security:
Hostile Applets, Holes, and Antidotes". The attackers cheat a bit for
demonstration purposes by having the patsy clear their cache to begin with,
but even without this exercise, guessing the cache location (one of four
possibilities) would not be all that much of a challenge.
Contrary to the claim on their page, Java security rules are no longer
relaxed for code loaded out of the cache (unless the cache happens to be in
the CLASSPATH---not recommended). That problem was fixed. In any case,
Microsoft apparently places HTML and class files in the same directory
*stored with their original names*. Though MSIE can't browse cache files
directly, HTML pages can reference cache files by explicit name. Thus the
file: URL, if properly constructed, can invoke the Java class. The applet
the crackers stuff in your cache is a port scanner. In this case, the port
scanning attack works because an applet is allowed to open a socket
connection back to where it came from. Guess where it came from? The
client machine. So a port scan is carried out by their cache-bomb applet.
That leaves only the problem of getting the port scan information back to
the cracker site. They use the URL lookup covert channel to do this. (The
Princeton team has explained this in a paper.) This is one of many ways of
sending interesting tidbits out from an applet.
In summary, the information released on 25 Feb by Major Malfunction & Ben
Laurie provides a couple of examples of some known attacks. If that helps
educate Web users about the risks of executable content, that's good. If it
stirs up unnecessary panic, that's bad.
Gary McGraw
p.s. See http://www.rstcorp.com/java-security.html for information on
the book, Java Security: Hostile Applets, Holes, and Antidotes
Dr. Gary McGraw, Research Scientist, Reliable Software Technologies (RST)
Sterling, VA <http://www.rstcorp.com/~gem> gem@rstcorp.com
If I may be so bold as to re-state Bob Atkinson's arguments, here is
my understanding of what he wrote:
Since the earliest days of the down-loading of software from BBSes,
most users have typically down-loaded software just because it is
there and they want to run it. Users have not refrained from
down-loading and executing software because of security concerns.
Therefore, given that most users simply want to down-load and run
whatever choice software offerings they encounter, Microsoft has
endeavoured to make this process as transparent and unencumbered as
possible.
In my view, Microsoft had two possible avenues of development and marketing
to choose from, as they developed their browser: 1) to move the security
benchmark forward, as Java has done, or 2) to leave it where it is, or even
allow it to slip a bit, in order to garner market share and further control
of network-based software interests. Is it, then, any wonder that they
chose the latter!
The issues surrounding the consumer demand that Microsoft is responding to
are the same issues which surround many other activities in society. To
state this another way, there are many pursuits which have risks associated
with them, and large numbers of people choose, every year, to
rationalize-away those potential risks; smoking, promiscuity, obesity, and
many other socially acceptable behaviours are all examples of the same
phenomena we see manifesting itself in the view Bob Atkinson propones.
Christopher Rath, Northern Telecom Ltd., Box 3511, Station `C', Ottawa,
ONTARIO K1Y 4H7 CANADA crath@nortel.ca (613) 765-3141 FAX: (613) 763-4101
A friend of mine was going on vacation for a week, and asked me to come by her house each day to feed her cat. The house has a standard alarm system: when you open the door, it beeps; punch in the correct number and the beeping stops. I memorized the code, but on the third day, I couldn't remember if the last digit was a 6 or a 7. I tried 7; the beeping stopped. I fed the cat and left. For the next two days, I punched in the same code, fed the cat, and left. On the last day, I punched in the code, fed the cat, and stayed around to read the paper. Five minutes later there was a knock on the door. It was the police. They asked me if I lived there; I said I didn't, but was cat-sitting. They asked me the address of the house I was in; I didn't know it, since my friend lives just around the corner from me and I know where the house is by sight, not by address. That was enough for them to assume that I was robbing the place; they handcuffed me and were about to take me to jail when a neighbor came out and verified that I was cat-sitting. What had happened? The last digit of the alarm code was actually a 6, not a 7. But there's an additional "feature" of the system: if someone is pointing a gun to your head and telling you to turn off the alarm, you can simply add 1 to the alarm code and punch that in instead. This sends an "extreme distress" signal: the beeping stops as if you'd entered the correct code, but the police are dispatched to what they assume is a high-risk situation. I'd been sending false alarms for four days, but leaving before the police arrived. The risks are clear: I could have been shot. As it was, my friend was billed for four false alarms; at $50 per false alarm, it cost us $200 (we split the bill). Robert Orenstein [Even though this item is marginally computer related, the design feature may be suggestive of related risks in authentication mechanisms -- especially those that seek to entrap attempted intruders. Incidentally, W.S. Gilbert was there before you: ``Either at sixes or at sevens.'' PGN]
The following bit of spam just arrived in the mail
>>>>> "spam" == RHill <RHill@TheHost.com> writes:
spam> Hello, I saw your site at
spam> http://catless.ncl.ac.uk/Risks/17.78.html/, it looks great...
The spam goes on to tell me how to register in Internet directories for a
mere $249. Note the reference to "your site" and the shallow compliment.
The "site" that the spammer refers to is RISKS Digest volume 17, issue 78;
it contains a short contribution from me. Looks like the spammer grepped
the web site for e-mail addresses, possibly in mail-to: tags.
Clearly e-mail spammers aren't any smarter or more discriminating than
snail-mail spammers when it comes to gathering addresses; does this fellow
really think that every mail-to: tag in a web page refers to its author(s)?
I'm reminded of the well-known junk mail that begins "Dear Mr. and Mrs.
Public Library, you have just won..."
Jim jim.thompson@pobox.com
I believe that John understates the risk of outsourcing IRS forms processing, in several ways. First, the government employees will continue to have access to the information, so the exposure of information doesn't simply shift from one venue to another, but continues at the first and is added at others, plus the risks of transporting the data first in hard format, then in electronic format. There will also be all the points of exposure in auditing the contractors. Second, based on the behavior of the credit-reporting industry, private enterprise seems to show no very high standard of concern for privacy. The firms on which we rely for "preparing our tax returns, handling our checking accounts, or storing the records of counseling sessions" are individually responsible to us under law to maintain confidentiality, which gives them an incentive to act responsibly: if your accountant failed to safeguard your financial information, he could reasonably expect to find himself in court, with your personal lawyer at the other table. (Compare this to the record of the credit-reporting industry.) I doubt the same strict and direct responsibility would be found in outsourced processing of IRS forms, unless the IRS somehow magically could come up with a new and effective set of rules and operations to manage it, of a kind we have never yet seen. The RISKS item does little do allude to this. The government employee's "little to fear as far as termination of employment" is a red herring, to which it's possible to oppose another scenario: "Lowest Bidder, Inc." gets a big chunk of the IRS's outsourced forms processing business. Joseph Savvy, CEO of the business, knows a potential gold mine, and through friends in places where money is laundered — with expert accountants and all the needed computing capacity — does a lot of data mining on the stream of information passing through his business's keyboards. This leads to a brand new stream of expert and nearly untraceable financial crime, plus other traditional crimes like blackmail and extortion, and the sale of some really exciting mailing lists on the open market. After all, who checks the provenance of information on mailing lists? To me this seems not at all unrealistic. Pete kaiser@acm.org
This is how dog tattoo numbers work in Germany, which your other SSN-reporter may care to adopt. Our dog has a 4-digit number tatooed in its ear. A finder can call the registry centre (number available at each local vet or attached elsewhere to the dog) and report e.g., Hellhound 0666 found. The registry centre database may report several different dogs 0666, so additional data about gender and breed may be asked for, for clarification. If you are on the owner short-list, you get a phone call, asking whether your dog is missing. If so, you are given the phone number/address of the finder. Lazy finders just turn the dog into the local pound & let them sort it out (maybe missing on the chance of a reward). Because dogs are required to be numbered, either per tatoo or per subcutaneous transponder, for crossing national borders, this mechanism is no extra hassle. Probably UK does not have this border requirement. Stu Savory (Owner, Bulldogs 0157 and (yes!) 0666) [They have Border Collies instead, whose collars enable Collie forwarding and Collie flowering. However, we are wandering, so let's terminate the ssnaggy dog stories. PGN]
It is common practice to engrave one's drivers license number onto object which are likely to be stolen. This assists in the identification and retrieval. Guess what? In Iowa, the Drivers License number is identical to one's SSN! So the risk is in assuming that your SSN is privileged information. It gets written on every check that I write, it's also my health care member ID number, employee identification number, etc. etc. etc. Brian Reynolds
> She replied, "3's an error code." On a medical device with 4 digits output what sort of meaningful error code would you except? Our home model does the same thing (although it flashes the result for an error) and its manual clearly states what each error code means. It also explains how to use it to avoid getting the various errors. Error "3" is that it couldn't read your temperature, usually a result of not aiming it properly. I don't think anyone would confuse that with a valid reading. The risk here seems to be that the nurse was not trained beyond "stick it in the ear and push the button". Sort of like if she had been trained with an oral thermometer to "stick it in the mouth" and not properly to place it under the tongue. At least the aural thermometer (is that what they are called?) tells you there's a problem whereas the oral one would just give a bad reading. They also work vastly better for "difficult" patients like small kids. Bill Seurer ID Tools and Compiler Development IBM Rochester, MN BillSeurer@vnet.ibm.com http://members.aol.com/BillSeurer/
A colleague of mine at AT&T suggested that this is similar to someone breaking into your house and making international calls. Who is responsible? Actually, I think it's more like someone knocking on your door, you let them in, and when you are not paying attention, they make these calls. Now, who is responsible? You? The phone company? Your house insurance? Although I hate to see people defrauded, I have been waiting for the day that people get burned from downloading programs from the net and running them. How can you expect anything else? Hopefully this publicity will help educate people against these dangers. Avi Rubin [usual disclaimers apply]
Perhaps phone lines should be password protected. That is available for incoming WATS calls. I have a simpler form for outgoing calls — it is only one digit long and the password is "9". Only the most diligent of the scam artists would bother with this possibility. Even safer are the minority of folks whose password for an outside line is "7" or some other non-9 digit. Scam artists who bother taking that into account must be really rare, and deserving of being hired into an honorable (?) position fixing some of the commercial software so often discussed in RISKS. Larry Kilgallen
>From: Marc Horowitz <marc@cygnus.com> >Subject: Re: Who made the call in the Moldova porn scam? (Claar, RISKS-18.83) >... A more proper analogy: If someone steals your car, and crashes it into >another car, totalling both, the owner of the other car is not responsible. >If someone steals your phone line and makes lots of calls, AT&T is not >responsible. I'm not unhappy with your conclusion, but I strongly dislike your analogy. International calls are very profitable for phone companies. If someone steals your phone line and makes lots of international calls that AT&T can collect for, AT&T makes a substantial profit---and unlike the car accident analogy, doesn't risk lethal injury. This makes it to AT&T's benefit to be a "bad driver", to encourage as much damage and mayhem on the "road" as possible. Bad analogy; bad policy. There is good reason to hold AT&T responsible for calls made to that number after AT&T was notified of the scam; and good reason to hold the customers responsible before that point. Paul Colley colley@qucis.queensu.ca +1 613 545 3807 http://www.qucis.queensu.ca/home/colley/info.html
A recent item on fraudulent Usenet postings reminded me of a stunt some of my students pulled on me a couple of years ago. It seems that some students (we never found out who) posted some personal ads purporting to come from me on a romance web page. I found out about this when I received e-mail from some admirers. My wife was unimpressed. :> We traced the source of the forged messages to an undergraduate computer study hall. They have since changed their policy to require that users obtain accounts first. It took a whole week before the fraudulent message was removed from the web page it was on, and then only when I threatened to report the owner of the page to whatever authority governed fraudulent communications in their jurisdiction. The responses I received to "my" ad were from some quite charming ladies who were also victims of this scam. I regarded the matter as a prank, but the same technique could have been used to place my name in uglier contexts Lessons: monitor undergraduate computers carefully. At the very least, register users. And use PGP. Perhaps, we should all periodically sweep the web to see where our names are ending up? Dr Andrej Panjkov, La Trobe Uni, Melbourne, Australia A.Panjkov@latrobe.edu.au http://guardian.maths.latrobe.edu.au +61 3 9479 2595
Upon further testing (prodded by others), I poked around on my VCR and, well, it does have the proper calendar, although the date is shown wrong, only the year is affected. It gets the days right (Feb 29 2000 is a tues, and the VCR agrees). I guess the risk is worrying about non-problems when there are much important things.
Please report problems with the web pages to the maintainer