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…
We noted in RISKS-19.12 and 19.43 that there have been serious development difficulties in connection with SACSS, the California Statewide Automated Child Support System. Finally, California Health and Welfare Agency announced on 20 Nov 1997 that the contract with Lockheed-Martin IMS has been cancelled altogether. [Source: Robert B. Gunnison, *San Francisco Chronicle*, 21 Nov 1997, A30. The article also notes that a new Cal DMV system was abandoned in 1994 after spending $50 million, and that problems with the Cal lottery system cost the state many millions.]
Federal prosecutors in New York City have charged a former Forbes employee George Parente with breaking into Forbes' computers after he was dismissed 21 April 1997, sabotaging the systems, and causing what the company estimated was more than $100,000 in damage. The computer outages caused employee inconvenience and necessitated significant effort in restoring programs and lost data. Parente faces up to five years in prison, but has denied the charges. Evidence includes a 55-minute phone call to a Forbes computer line made that evening. The crash occurred the next morning. [Source: *The New York Times*, 25 Nov 1997. PGN Abstracting] [In an unrelated case, Senal Arabaci, 31, a Manhattan computer programmer, was charged Monday with sabotaging a computer system at Art Assets LLC by deleting and modifying files after a billing dispute with the company. He was released on a $50,000 bond. [Excerpt from an AP item, 25 Nov 1997, on the Forbes case, noted by Don_Rosenberg@compuserve.com. PGN]
On 23 Nov 1997, Paul Sirks got out of his plane in an attempt to restart the engine by cranking the propeller. The plane took off on its own without him, reached 12,000 feet, and flew for two hours before running out of gas and crashing into an unoccupied bean field northwest of Columbus, Ohio. [UPI item, 24 Nov 1997, PGN abstracting]
Worldwide, hackers cost businesses an estimated $800 million in 1995 through break-ins to computer systems at banks, hospitals, and other large businesses, according to investigators of the Senate's Permanent Investigations Subcommittee. Despite the staggering losses, few businesses report the security breaches for fear of negative publicity that could scare off customers, officials say. Also, most losses incurred by banks do not appear in required federal reports. The subcommittee's eight-month investigation showed that security problems seem to be worse in the private sector than in government. More than $400 million of the calculated losses were attributed to U.S. businesses. Fear of hacker attacks has prompted many corporate users to boost budgets for security spending. A study conducted by http://www.yankeegroup.com/ . The Yankee Group, a Boston-based consulting firm, and *Infosecurity News* showed that corporate security budgets have already increased by 25 percent, with more increases expected this year. The study also concluded that nearly half of all break-ins are committed by internal users.
The *Guardian* has recently (actually I'm rather tardy) published two articles on the use of encryption to protect communications. The first dealt with the (possible) reasons that the US and UK governments wanted to control the use of encryption. The second (published 16 October 1997) dealt with the an EC report, Ensuring Security and Trust in Electronic Communications (on the web, according to the article at www.ispo.cec.bei/eif/policy/97503.ntml I looked but couldn't connect). The first paragraph reads "US and British intelligence agencies received a major blow last week, when the EC urged governments to introduce uniform and effective encryption standards to protect communications on the Internet, writes Duncan Campbell. In a landmark report, the EC asserted that legal recognition and standards for digital signatures, which depend on effective cryptography, should be put in place across the EU by 2000 "at the latest"." Other interesting comments include the following. "Although the EU concedes that individual governments can, in principle, make their own national security arrangements, member states are now being warned that restrictions on importing or exporting cryptographic products may be unlawful under sections of the European treaty, as well as contrary to existing community directives". The article goes on to say, "The Commission says it found no evidence that regulation could or would stop criminals from using effective encryption." Full text of both articles is at http://online.guardian.co.uk/archive.html, limiting the search year to 1997 and use the search string "crypto*" to bring up two articles from 17 Sep and 15 Oct. Mike Ellims Pi Technology <mike@pires.co.uk> +44 (0)1223 441 256 [DISCLAIMERS]
A friend who manages one of the Y2K compliance projects at a major US-based multinational corporation reports the following (some light editing to protect sources and to consolidate several messages): Just heard this one from one of our expat Brits in Zurich. Apparently [a large food retail chain in Britain] has these highly automated regional distribution centers. They are starting to receive canned goods with expiration dates running past 2000. So, at the same time as they were receiving shipments of tinned tomatoes with shelf lives until '05 (which were being shuffled into storage bins by their automated pallet system), their automated "expired goods" system was scanning the new stuff, thinking they had gone bad 92 years ago, pulling them, and putting them on to lorries which then took them to the dump. [...] after trashing the "expired" tins, the automated system placed an order to the supplier to replace them. Apparently some guy at the warehouse noticed this but didn't want to say anything [...] It was only when the tomato company's sales rep said something like, "Jeez, you guys are selling a lot of our tinned tomatoes lately," that they caught on. Besides the usual Y2K issues, two other risks are worth noting: 1. Either the system has no autoamted tripwire mechanism to alert operators about major deviations from suitable running averages, or its thresholds are not set properly. 2. The usual organizational risk of people being afraid of rocking the boat. Caveat: I trust my direct source, but this is a "friend of a friend" kind of story, so there's a slight chance that this could be a Y2K urban legend, if nothing else because it's so exemplary.
According to the _Ottawa Citizen_, 17 November 1997, p. C1, an Ottawa consulting firm has registered the term Y2K as a trademark, "making it illegal for others to use the term". Main points: - I-T Net Consultants began looking into getting a trademark in 1995. "'Lo and behold, no one had registered it'". - "Two months ago, I-T Net received a letter giving it official rights to the Y2K term". - "'We're not going to get litigious', said Mr. Beraskow. Instead, as the company notices Y2K being used, it will send a letter informing the organization that Y2K is a trademarked term". - "I-T Net will probably let its own clients use Y2K for 'a nominal fee'... However, Mr. Beraskow said the company would take organizations to court if they continue to refuse to stop using the term." There's no mention as to whether I-T Net claims the trademark is valid in other countries. Yves Bellefeuille, Ottawa, Canada <yan@storm.ca> [Does that cover "y2k" also? PGN]
A friend of of mine recently ran into this problem with the Word 97 grammar checker: > Word 97 grammar checker wants me to change > "we will not be issuing a credit note" to > "we will be issuing a credit note" Who checks the grammar checker? Azeem (az ! at ! pobox ! dot ! com) BBC
The following message appeared on the net. > From: Anonymous <anon@ANON.EFGA.ORG> > Subject: Major security flaw in CyberCash 2.1.2 > To: BUGTRAQ@NETSPACE.ORG > > CyberCash v. 2.1.2 has a major security flaw that causes all credit card > information processed by the server to be logged in a file with > world-readable permissions. This security flaw exists in the default > CyberCash installation and configuration. > > The flaw is a result of not being able to turn off debugging. Setting the > "DEBUG" flag to "0" in the configuration files simply has no effect on the > operation of the server. > > In CyberCash's server, when the "DEBUG" flag is on, the contents of all > credit card transactions are written to a log file (named "Debug.log" by > default). > > The easiest workaround I've found is to simply delete the existing Debug.log > file. In my experience with the Solaris release, the CyberCash software > does not create this file at start time when the DEBUG flag is set to 0. > > The inability to turn off debugging is noted on CyberCash's web site under > "Known Limitations". The fact that credit card numbers are stored in the > clear, in a world readable file, is not. We have taken this quite seriously and have put through a full release of our software which will be available Monday 24 Nov for three platforms and others shortly thereafter. The flaw was in the debug logging function, not in the protocols or core implementation. Nonetheless, the effect was an unnecessary exposure of potentially sensitive information, and it shouldn't have gone out the door that way. We're tightening our internal processes to avoid this in the future. That said, here's the actual exposure. The credit card information that's in the clear in the log comes from "merchant-initiated" transactions, which means the merchant obtains the credit card number from somewhere — phone, mail, fax, SSL-protected Internet interaction, or unprotected Internet interaction. The merchant thus has the same info in the clear already. If the card number was provided via a wallet, then the card number is blinded at the consumer's end. It is therefore not in the clear as it passes through the merchant's machine and the reported exposure does not apply.. In order for the unprotected log to pose a risk of exposure, someone has to be able to gain access to the merchant's machine. If the machine is well protected, viz behind a firewall and/or carefully configured, presumably an outsider won't be able to gain access. And in terms of the *additional* exposure the open log represents over existing risks, if the same information is accessible in the clear elsewhere on the machine, eliminating from the log or encrypting the log provides little or no real protection. We continue to advise merchants to take strong steps to protect their machines. To our knowledge, the exposure documented above has not resulted in the actual loss of any customer data or other security incident. Dr. Stephen D. Crocker, Chief Technology Officer, CyberCash, Inc. 2100 Reston Parkway, Reston, VA 20191 crocker@cybercash.com +1 703 716 5214
On Tuesday, 18 November 1997, America Online suffered a variety of breakdowns that left users without service. Starting sometime before 8 a.m. ET, AOL responded at various times with "Unable to send mail at this time." "Unable to receive mail at this time." "There has been a temporary delay in the connection process." and "The system is temporarily unavailable." Some users could retrieve their mail by about 12:45 p.m. ET, but it was impossible to send mail until shortly before the time stamp on this message, which is when I was finally able to send it to you via AOL. One Risk, often repeated: The bigger and more complex systems get, the more prone to problems. Edward Fischer, Director, Information Systems, Post Newsweek Stations, Inc. 3 Constitution Plaza, Hartford, Connecticut 06103 Voice: (860) 493 2522
Since Wednesday, 19 Nov 1997, AOL seems to have had significant Internet
connectivity problems. Many customers who use local ISPs to telephone AOL
(using AOL's TCP/IP connection option) have been unable to get through.
Other ISP customers have been unable to reach the AOL website. And there are
reports that mail between AOL and MSN is not properly function.
Complicating the diagnosing of this problem is the fact that AOL seems to be
blocking some IP services (such as PING) put allowing others to pass (such
as HTTP) to various hosts.
Further complicating the problem is that AOL's standard response, when
people call the company's technical support hotlines, is to say that the
fault lies with the customer's local ISP, and not with AOL itself.
I have verified that connectivity problems between AOL and the rest of the
Internet exist from at least two locations:
* Vineyard.NET (204.17.195.100)
* MIT Media Lab (18.85.0.2)
I have also spoken with people in California who have reported similar
connection problems.
I have personally called America Online on several occasions. Each problem
they say that the problem is with my Internet Service Provider, and not with
their Internet connection. This seems unlikely.
Speaking with my upstream Internet provider, I am told that the problem may
be with the Routing Arbiter database (www.ra.net), which apparently crashed
several times in November.
What this is showing is the problems of an open network in dealing with
quality-of-service problems. It shows the ease of finger-pointing on the
Internet today, and the difficulty of accountability. It also shows the
real problems when there are large, national networks which fundamentally
nobody is in charge of.
I do not know when, if ever, this problem is going to be resolved. In the
meantime, many, many people cannot reach AOL.
Not that this is necessarily a bad thing, mind you.
This is not a new risk, but I thought it was interesting nonetheless.
I subscribe to a mailing list about bone marrow transplants. Recently one
of the other subscribers complained about "A"'s web site. "A" was trying to
raise money to pay for a bone marrow transplant (BMT) for herself and had a
web site that announced this. She also had links to other web site's
including one to "B"'s site. To confuse matters further "A" and "B" have
the same first name. The complaint was that the link to "B" site, instead
brought up a porn site. The complaint was whether "A" was in fact
legitimately raising for a BMT or just another scam. The other alternative
was that someone had hijacked "B" site.
The true explanation was much more mundane. In fact "B" site had moved
several months ago and "A" had not updated her link. It appears that the
old ISP had been bought by "Free XXXPics Unlimited" and were recycling the
URL.
This is not really a new risk as phone numbers have always been recycled,
perhaps less frequently then they are now. It does seem like something that
will become more frequent in the future.
My attempt at hiding the identities of the innocent ("A" and "B") is
probably futile as the identities are probably easy to determine by starting
with my home page or using a net search.
Art Flatau <flataua@acm.org>
Austin, Texas http://www.acor.org/diseases/hematology/Leukemia/leukemia.html
*Marketplace* Radio just reported that Scott Adams posed as a "management consultant" at Logitech, Inc [with the help of its president and a wig...] and managed to get the working group to rewrite the mission statement from a simple, straightforward page to an obfuscated jargon-filled morass. No one person questioned the sanity of the input data. The RISK? Is this the human form of "Of course it's correct, the computer says so..." perhaps? Sigh... "Clothes Make the Man, Babble makes the Expert."
Robert X. Cringely's article is at: <http://www.pbs.org/cringely/archive/nov697_ main.html> I did a little research with Outlook 97, and have divined the following schedule. Wednesday, 26 November 1997 Wednesday, 25 November 1998 Tuesday, 23 November 1999 Wednesday, 22 November 2000 Wednesday, 28 November 2001 Wednesday, 27 November 2002 Tuesday, 25 November 2003 Wednesday, 24 November 2004 Wednesday, 23 November 2005 Beyond this date, there is Thanksgiving no more. The last holiday of 2006 appears to be Election Day. That seems to be it. No more holidays after Election Day, 2006. The implication of Election Day is truly horrifying.
[...] Although Microsoft tends to let dates slide, this is the first one I've heard them advance... Chris Adams <cadams@acucobol.com>
BKHLTHCK.RVW 970706 "Halting the Hacker", Donald L. Pipkin, 1997, 0-13-243718-X, U$44.95/C$62.95 %A Donald L. Pipkin %C One Lake St., Upper Saddle River, NJ 07458 %D 1997 %G 0-13-243718-X %I Prentice Hall %O U$44.95/C$62.95 201-236-7139 fax: 201-236-7131 betsy_carey@prenhall.com %P 193 %T "Halting the Hacker: A Practical Guide to Computer Security" This book is a compilation of observations on computer security, particularly on network connected computers, and particularly in regard to outside intruders. What specific system information is included relates to UNIX. Most of the advice is generic. The information is "practical" in that it relates to common, rather than theoretical, attacks. However, the text does not provide practical answers: the defenses are left as an exercise to the reader. There is nothing really wrong with the information provided in the book. (I wasn't too thrilled with the section on viruses, but we'll let that go.) It has all, though, been said before, notably by works such as Spafford and Garfinkel's "Practical UNIX and Internet Security" (cf. BKPRUISC.RVW). In fact, there were passages that I'm quite sure I could have traced as to origin and author. Normally, I don't comment on CD-ROMs unless something unique is available. As with most such disks, this one provides information that is available elsewhere, mostly from COAST. Overall, though, in this case I think the CD-ROM does add some value, holding information such as the "Rainbow series" of security standards, and a list of machine address codes for Internet addressing as assigned to vendors. copyright Robert M. Slade, 1997 BKHLTHCK.RVW 970706 roberts@decus.ca rslade@vcn.bc.ca rslade@vanisl.decus.ca
Microsoft has subsequently posted an official statement as to what they are
doing. What I find most interesting is their temporary "work-around":
...Since this erratum can only be exploited by a program that was
developed with malicious intent and deliberately uses this
illegal instruction, following common-sense computing practices,
such as not downloading or running executables from unknown
sources, can protect a user from this problem.
Since Microsoft Active-X is essential "downloading or running executables
from [possibly untrusted] sources", Microsoft is inviting everyone not to
use Internet Explorer. Of course, I don't expect them to actually say that
nor do I expect most people to realize that merely "browsing" may constitute
"downloading and running".
Roland B Roberts, PhD, Muller Data Corp, 395 Hudson Avenue, New York, NY
10014 USA 1-212-807-5143 rroberts@muller.com
Using DEBUG? You don't need to do that... The decimal versions of the bytes can be entered on a PC using <ALT>+
Re: New Pentium flaw (someguy, RISKS-19.46)
Leonard Erickson <shadow@krypton.rain.com> Mon, 17 Nov 1997 22:50:30 PSTsomeguy@somethingorother.com writes: > Here is how to use DEBUG to create a DOS executable that exercises the new > flaw. DEBUG is available on DOS, Windows 3.x/95/NT and OS/2, and maybe > others. No need to use DEBUG. Every single one of the 4 bytes required can be entered directly from the keyboard! Get to a DOS prompt and type this: copy con kill.com And then hit return. Hold down the alt key and type 240 using the numeric pad. Release the alt key. Hold down the alt key and type 15 using the numeric pad. Release the alt key. Hold down the alt key and type 199 using the numeric pad. Release the alt key. Hold down the alt key and type 200 using the numeric pad. Release the alt key. Press the F6 key. Press enter. You now have the KILL.COM file... Run at your own risk. As an old sig file says: Real programmers use COPY CON FILE.EXE Leonard Erickson (aka Shadow) shadow@krypton.rain.com
Re: New Pentium flaw (someguy, RISKS-19.46)
Robert Stanley <Stanley@@nr1.ottawa.istar.net> 18 Nov 1997 14:47:39 GMTI was amused, and pleased, to note that running this in the DOS box of an OS/2 Warp system resulted in an OS/2 exception, which is a recoverable situation, and not a halt-and-catch-fire of the Pentium. Robert Stanley — Stanley@Simware.COM
Re: New Pentium flaw (Strayer, RISKS-19.46)
Nick Rothwell <nick@cassiel.com> 18 Nov 1997 11:15:21 -0000> While I'd rather there wasn't "halt and catch fire" instruction for the > Pentium, programs that crash the PC aren't exactly rare. Actually, no program has ever crashed my PC. That's because it runs Linux. Your argument here is basically: because a huge percentage of Pentium-based computers are not properly protected by the OS against unprivileged software crashing them, there is no need to worry about a hardware bug which would bypass a proper protected-mode OS. This kind of bug cannot be circumvented even by competent OS design. (Interestingly, this particular bug has been - in Linux and BSDI at least. I'm waiting to see how long it takes for fixes to appear in less competently-designed popular operating systems.) Nick Rothwell, CASSIEL http://www.cassiel.com
Re: Pentium Fix?
"Pekka Pietik{inen" <pp@netppl.fi> Tue, 18 Nov 1997 09:49:00 +0200Actually the fix is far more clever than checking the memory for that instruction sequence, and works perfectly. connecting (ROOT):~ >./crash <c2800fc8/c2800ff8> <handler c01094b8... ... done> zsh: illegal hardware instruction ./crash model : Pentium 75+ vendor_id : GenuineIntel stepping : 5 f00f_bug : yes The fix (described in www.intel.com) basically puts the IDT (a list of addresses the processor jumps to when various software interrupts like illegal instructions or page faults happen) on a page boundary so that the first thing on the next page is 0xe (page fault), and instruction fault is on the first page. The first page is left unmapped. When someone runs the f00f code (or any invalid instruction) the processor naturally tries handles the invalid instruction. Before the fix the processor would have died while handling it, but since it can't jump to the handler because it can't find the address to jump to, it gets a page fault. This page fault puts the processor into a sane state, and now some code in the page fault handler can check what really happened and handle the situation properly. The fact that this fix works is only caused by the fact that the instruction fault (and nothing performance-critical) happens to be before the page fault in the IDT. If it hadn't been, Intel would be in some trouble. There is a small performance loss, but it's unnoticeable. Pekka Pietikäinen, Net People Ltd., Oulu, Finland [The above messages relating to the new Pentium flaw are just a sampling of those received. PGN]Please report problems with the web pages to the maintainer
xTop