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…
126,000 customers in northern San Francisco experienced a power outage for
up to 3.5 hours beginning at 6:15 a.m. on 23 October 1997, when five
transformers stopped working at the power substation at Eighth and Mission.
The FBI counterterrorism unit is investigating what it considers the
likelihood of sabotage (for reasons not revealed, although 39 of the 42
switches were open).
[If this turns out to have been not terrorism but rather salt water spray
from the San Francisco Bay accidentally causing a short that tripped the
switches, we would have a new interpretation of "Bay to Breakers" (the
annual so-called San Francisco foot-race). PGN]
[Error in date (23 Oct) corrected in archive copy. PGN]
[This just came into my mailbox. I have no idea if it is for real, or is a spoof. In the absence of further indicia of truth, I am inclined to put it into the urban legend category. Paul] Date: 10/15/97 05:50 PM >From: acobb@coombs.anu.edu.au Hi everyone from a colleague It's about new fancy electronic car failures due to electromagnetic fields >Morning all, >Thought that this article in the Sydney Morning Herald, Monday, Oct 13, >pp.1 and 4 would be of interest. >Tim. > >********************* >"Crazy cars: the newest hazard on Sydney's roads" > Phil Scott, Motoring Editor > >New cars are jamming their own brakes, locking doors, shifting gears and >mysteriously shutting down. The cause: electromagnetic interference, the >same phenomenon that affects hospital equipment and aircraft instruments. > >At risk are a small number of new cars with inadequate "immunity" built >into the electronic systems which control engines, brakes, transmissions >and features such as central door-locking, cruise control and >air-conditioning. Some airbags, claim the experts, may even be prone to >random firing. > >Engineers list known Sydney hot-spots as near the airport on General Holmes >Drive, in parts of Chatswood and Hurstville. Traffic light sensors, taxi >and police radios, broadcast transmitters and underground power lines can >trigger failures. > >Volvo has a unique problem at Tempre, where power lines under the Prince['?]s >Highway have caused brake pedals to pulsate opn five examples of its >flagship 9-Series models. > >"The power lines are buried in the kerbside lane and have caused the >braking system to pulse if the car is stationary" a Volvo spokesman, Mr. >Graeme Adam, said last night. > >Also affected is Hyundai. "We've had a number of instances but you can >count them on two hands", said Mr. Patrick Lyons, public affairs manager. >Some of the company's Lantra models were shutting off their anti-lock brake >systems, leaving drivers with mechanical brakes and a red warning light. > >Volvos with jammed brakes, Ford door locks which open and close unaided and >Holden glitches with air-conditioning and automatic transmissions are being >attributed to interference. > >Australia, unlike Europe, has no design rules requiring common standards of >"immunity" for electrical systems in cars. > >The technical director of the accredited testing authority EMC >Technologies, Mr Chris Zombalas, said: "This highlights a critical safety >issue and the problem, to put it mildly, is poor engineering. The >electronic systems aren't engineered properly to operate in the >environment". Automotive failures are also well-known to RFI Industries, >an independent testing laboratory in Melbourne. > >"Of course the automotive world is closed-mouthed, like the medical world", >said Mr Dick Davies, manager of its electro-magnetic compatibility and >interference laboratories. "We put these malfunctions into different >classes > >"A fuel gauge that doesn't work when you're on the mobile phone is a grade >one. A grade two might be the windshield wipers going off. Startling, >yes, but by itself unlikely to cause an accident. > >"Grade three could be the electric seat repositioning itself while you're >driving. That could, perhaps cause an accident. Then you have grade >fives, the catastrophic ones. You might be driving down the Hume Highway >at 120km/h and the microprocessor says stop the left wheel...or maybe the >cruise control jams". > >Mr Davies cites an incident near Sydney airport. "An underground power >cable was run out in the airport extensions under the freeway. It just >happened the car was moving very slowly in a traffic jam and it sensed the >magnetic field from the cable, and stopped the front wheels. It was kind >of embarrassing. The sensors, depending on the brake system, can be >magnetic and the frequency of the mains cable was just the right frequency >to set off the brakes." Adam Cobb, Research School of Pacific and Asian Studies, Australian National University ACT 0200 Australia 61-2-62438557 http://coombs.anu.edu.au/~acobb
The DoD has creating a standard operating environment called the Common Operating Environment. All internal and external development is expected to comply with the COE. However, recently, it was discovered that there was a bug in the screen lock program that came with it: > I have discovered that the screen saver used when the COE screen gets > locked, somehow always "the worms", consumes all available cpu time on the > system. This causes any boot processes of the application, and even > graphical application processes the user is running, to slow to almost > zero progress any time the screen gets locked. I first discovered this when > I walked away from a system running the COE segment installer. The screen > locked, as expected by the deadman timer. When I unlocked it, though, I > discovered that no progress had been made on the segment install. > > While this problem is just an inconvenience in the case of segment > installs, this is catastrophic for the application my customer is > migrating. This application includes a number of boot processes that > maintain a constant flow of data between each of the machines running this > application. There is no room for falling behind just because the screen > saver is displayed. Apparently the screen saver, probably considered as a utility, was not tested with the rest of the system when it was integrated. Thus, the general risk is one of creating a seemingly innocent function, adding it to a product, and having a severe impact. John Long Castek RBG - The Reuse Business Group johnlong@castek-rbg.com
I recently visited a Web page that contains this:
* Cleanroom Software Engineering
The objective of the Cleanroom methodology is to achieve or
approach zero software defects with certified reliability.
where the heading line was a link. I clicked it, and got a page whose
entire contents were:
Error opening file:
So I wrote to the webmaster, who eventually responded that the problem had
been corrected. I tried the link again. It hadn't. Perhaps by now it has
been, but I'm in no hurry to go back there.
I'd be cautious in putting a page up about "zero software defects" — there
may be some Goedelian rule operating in the universe of software under which
any software complex enough to be useful must necessarily contain at least
one defect. In "The Psychology of Computer Programming", still a good read,
Gerald Weinberg recounts a lovely story about debugging the null program.
As you might guess, even the null program could contain bugs.
Pete kaiser@acm.org
Having in the past given up with the domain name private.org due to the amount of irrelevant e-mail I received to it, you would have thought I would know better. I own the domain name HTTP.ORG. The web site for that domain has always received a fair amount of seemingly random hits, presumably from people mistyping URLs and having their domain suffix search order including ORG. Recently however I have noticed a dramatic increase in the number of hits to www.http.org, so I decided to investigate further. Looking at the access logs, it did appear that the recent upsurge in hits could also attributed to mistypes. But why the very recent increase ? The common link is Lynx web browser 2.7.1. It would appear that the latest version of Lynx likes to pretend to be clever and guesses at a URL if it doesn't receive a response from the host that you typed. Unfortunately this means that a request for any of the following typos: lynx http//:www.somedomain.com lynx http//www.somedomain.com lynx http/:www.somedomain.com lynx http/www.somedomain.com Will result in Lynx trying... Looking up 'http' first. Looking up 'www.http.com', guessing... Looking up 'www.http.edu', guessing... Looking up 'www.http.net', guessing... Looking up 'www.http.org', guessing... Getting http://www.http.org//www.somedomain.com At which point my site is queried. The risks are obvious. Confusion reigns and I receive a constant flow of hate e-mail from users all around the world who think that I have hijacked the web sites they are trying to reach. *sigh* Dominic J. Hulewicz - mailto:dom@inta.net - http://www.intanet.com/dom [Dominic CC:ed a lynx development list on this contribution. I have carefully removed that address here, but am now getting copied on requests to be removed from that list! I never sausage lynx before. PGN]
I paid *too* much in taxes and got labeled a deadbeat taxpayer. Here are the four components for disaster: 1) my mortgage holder pays my property taxes, 2) I'm enrolled in a special program that lowers the amount kept in escrow because I pay these taxes semi-annually instead of annually, 3) most people pay annually, 4) computers. The mortgage company, for some bizarre reason, paid too much in taxes. It turns out they paid the 3% fee for using the semi-annual scheme with the first half instead of the second half. The city's computers saw that the amount was more than was owed semi-annually and assumed I was voluntarily trying to pay annually. It kindly switched me over to the annual plan. But since the amount was also less than the annual amount, it assumed I was a tax cheat. If I didn't catch this, the house would have been auctioned off.
I heard the following story on CBC Radio 1:
A picture framing business had more than 240,000$ stolen from their account.
A quick debit card primer
The debit machine is normally used by the merchant who swipes the client card
in the card reader, then enters the amount of the sale. The customer then
enters his PIN on a separate keypad. When the PIN is verified, the customer's
bank account is debited and the merchant's bank account is credited.
A transaction adjustment is the reverse. The process is the same, but the
customer's account is credited and the merchant's is debited. This is a
relatively rare transaction (typically used when returning an item which
was purchased via debit card).
The story:
On Friday Night, thieves forced the front door open with a crowbar, and
used the merchant's debit machine (which is also used to charge Visa & MC)
to do transaction adjustment in excess of 240,000$. They used 10 debit
cards for which they had the PIN numbers. When the merchants opened their
store on Monday, nothing had been stolen and they did business as usual.
Only when they did the "debit machine reconcile" at the end of the day did
they notice a discrepancy. The balance from the debit machine slip read
-248,372$. Fearing a mix-up, or some data entry SNAFU, they contacted the
bank, but no one returned their call.
The next day, their account had been frozen, and their vendor number (used
to process MC & Visa) was suspended. All this time, no bank officials would
return their calls. Eventually, they reached someone in the corporate office
who told them that they couldn't do anything until the police investigate.
The police determined that thieves did the deed by Thursday, but the bank
still took over 2 weeks to reinstate the account and vendor number.
Some interesting points:
- The transactions were done between Midnight and 4 AM.
- There was a $45,000 adjustment done at 3AM.
- The bank account balance at the time was only 2000$
- The merchants DID NOT have overdraft protection.
- In order to start a debit machine, one needs a special vendor card.
But the bank typically tells customers to keep the card in the cash
register till for easy access.
- The merchants have been doing business with the same bank for over
18 Years.
The thieves have been identified. It mystifies me how they thought they
could get away with it, since the transactions are traceable.
Some thoughts:
On the bank side, there doesn't seem to be any checks made on the validity
of a transaction adjustment (Unusual transaction patterns, overdraft, etc).
No one at the bank seemed to know the system, or be able to give answers.
Plenty of familiar risks:
- No transaction validation
- Not securing the key card
- Clue-less bank advice
- Clue-less bank officials
Benoit
Andre L. Dos Santos (RISKS-19.41) described an attack based on
installing classes onto CLASSPATH. "The danger of setting the CLASSPATH
environment variable to a path where malicious classes are located is well
known."
Starting from JDK1.2 (public beta version should have appeared on our web
site by the time this article appears), we can separate from locally stored
system code and locally stored but less trustworthy code. In particular,
a separate class path (configured using a Java property) is introduced such
that
(1) CLASSPATH should only contain trusted system code (so in most
cases, a user should not touch/change it);
(2) java.app.class.path should contain everything else one wants to
load from the local file system.
Local applications loaded from java.app.class.path are subject to the same
rigorous bytecode verification and other runtime checks that have been
applied to applets downloaded over a network.
In short, there is no longer any built-in difference (in terms of security)
between a local application and a remote applet. Moreover, a policy-based,
easily configurable and extensible security model is now applied, equally,
to both applets and applications. (Documentation of this should come with
the beta release.)
Li Gong, JavaSoft, Sun Microsystems, Inc.
(Re: Youngman, RISKS-19.40) It's interesting to note that this operation would not have been hampered one bit by strong encryption - even if the images were so encrypted, the sting would have obtained the keys - there's no point mailing an encrypted image to someone you think is a fellow devotee without the key.... Also, the site (http://www.cnn.com/US/9709/30/cybersting/) shows again a worrying lack of understanding amongst lawmakers/enforcers. It took "investigator Michael McCartney" (they don't say which agency) 10 minutes using e-mail to get "a picture of an adult male having sex with an adult male". Hasn't he heard of Usenet? - I'm sure that it wouldn't have taken that long to find something in a.b.p.e.gaymen. Mike
Actually, there's a slight translation problem here. France is divided into 96 "Departments", corresponding roughly to counties. These were initially numbered 01 to 95, so if you live in number 42, your car registration is of the form "NNNN XX 42" (say "2724 TJ 42") and your postcode is of the form 42NNN (say 42301). Then Corsica - number 20 - was split into two Departments, numbered 2A and 2B (and not to be confused with 02). So cars are now 2724 TJ 2A, but postcodes remain 20123. Clive D.W. Feather, Director of Software Development, Demon Internet Ltd. Tel: +44 181 371 1138 Fax: +44 181 371 1037 <clive@demon.net>
I wonder whether they will add artificial "line-noise" to alleviate people's worries? I've heard that early Lexus cars had a similar problem. The cars were so quiet and well sound-proofed that one couldn't tell by listening whether or not the engine was running. This led to a lot of drivers trying to start an already-running car, and ruining their starters. In response, Lexus modified the soundproofing to let a little more noise in, and also modified the dashboard readouts, making the lights much brighter, so that one could tell *visually* that the car was running. I can't confirm that this was really what happened, but it's what my father told me when I asked about the unusually bright dashboard lights in his car... Ari Rapkin
At <http://www.zdnet.com:31019/zdnn/content/zdnn/0918/zdnn0010.html>, Jonathan Littman mentions an interesting aspect of a security scan using a war dialer: > Hacker shocker: Project reveals breaches galore > Hackers call it "war dialing." > By Jonathan Littman > September 18, 1997 2:47 PM PDT ZDNN > A security expert has used this old hacker's technique to root out > thousands of modem lines in Northern California that may be leaving > corporations and individuals vulnerable to attack. > [He] has been letting his computer do the dialing. A whole lot of > dialing: 1.4 million numbers or so; 500 an hour, 12,000 a day. Roughly > 14,000 of the 1.4 million numbers [his] program randomly dialed were modem > lines, a figure that translates to thousands of open doors for would-be > hackers to wreak havoc. Readers of RISK wll already have noticed that if 14,000 of 1.4M numbers dialed were modems, then about 99% of the phone numbers were either unassigned or were not modem numbers. So did 1,386,000 people receive calls from a modem? Or were the random calls directed solely at known commercial exchanges? And it appears from "500 an hour, 12,000 a day" that these calls went out at all hours. Which would be preferable, do you think: being bothered by a modem during working hours or in the middle of the night? In addition, US Code Title 47 Section 227 (recently discussed in RISKS 19.34 ff), automated calls are forbidden by law in the evening and night-time (the server for <http://www.law.cornell.edu/uscode/47/227.html> isn't responding as I write this, so I don't have the exact times). The fruit of this poisoned tree is not completely rotten, so the article's interesting findings will be useful in security awareness programs, especially if the ethical and legal issues are discussed in addition to the findings. M. E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com
I have enjoyed reading comp.risks for some time now, but have never experienced any of the problems recounted there. No invasion of privacy, no denial of service, no hare-brained computer errors beyond the normal ones found in commercial software that mostly fails to do reliably what it is supposed to do. Until now! The ACM Member Services offers e-mail forwarding to ACM members. Being a wandering sort, I have used this for a few years in order to have a stable e-mail address. You can choose the name to use as long as the name is not already used. My service worked fine until recently, when a fellow member whom I'll call Smith decided to open a forwarding account under the name 'das'. Now this happens to be my current name in the local account to which e-mail is forwarded. It's hard to see how this would screw things up, since acm.org is a completely different domain from my local one, but I suppose sendmail screw-ups are like the trees in the forest - uncountable. (I don't actually know if they're using sendmail. I tried to get the technical details of the mess, but no one at ACM responded to my request.) Anyway, test e-mail from Smith to Smith started appearing in my mail. I forwarded the mail to his real account and he got on the tail of ACM Member Services. They were somewhat slow to respond, so this went on for a while. Then I got no more test mail from Smith and assumed everything was fine. However, my e-mail traffic died off completely, which I took for an ominous sign, especially when a reply I was expecting did not arrive. In fact, it did soon arrive, forwarded by Smith. Yes, my e-mail was now being forwarded to Smith. I had already alerted ACM to a possible problem and received no answer for a few days. Now I sent off a somewhat heated complaint. After all, this was no mere test e-mail; this was my private mail getting sent to a stranger. ACM finally replied to this and told me the problem was fixed. No apology or explanation. And, wouldn't you know it, mail to Smith (now private mail) started getting delivered to me again. At this point, Smith swung solidly into motion. But by then I had had enough and simply short-circuited the problem by changing my forwarding address to a local alias. ACM then proudly informed me that the problem was finally solved, proving this by sending me a mail that was forwarded to my new alias. I explained to them why this didn't prove anything, and told them that I and Smith were still lacking a proper apology and explanation. The apology arrived, but no explanation. The ACM also managed to reveal presumably confidential information during our e-mail exchanges. For example, my account number was revealed to Smith and his to me. This is one of the attributes that give access to the online services, such as the one that allows you to change the address to which e-mail is forwarded. I figure they have earned this article! David Sedlock
I have been deluged with e-mail since my article about the anti-aliasing of fonts was published in the last issue of RISKS. Unfortunately, it was distributed through an oversight; I had sent mail to the moderator several days before RISKS "went to press", asking him not to publish the article. This came about because further investigation on my part had indicated that the problem seemed to lie with individual fonts not being anti-aliased in any application, rather than there being a consistent problem with anti-aliasing in Netscape alone. It is already well-known that cancelling a Usenet article is no indication that it will not be seen by a large number of people. The RISK illustrated here is, I suppose, that even with a responsive moderator at the helm, taking the step of asking a human not to publish an article does not guarantee that it will not be distributed. [My apologies for missing the request to cancel the message. I had been away for the annual Baltimore security conference and for a variety of reasons had gone 16 days without an issue. Because I had not been able to check the RISKS mailbox for two weeks, the backlog included many hundreds of would-be contributions (plus a massive number of bounces from the previous issue). I culled out a few that seemed most interesting without even beginning to go through the mailbox. In the future, if you wish to withdraw a submission, please CC my personal mailbox, with a sensible and relevant subject line, because I am massively deleting apparent spams sight unseen (despite ongoing filtering). PGN]
National Computer Security Association invites participation in the CyberRisk '97 Conference, The only conference for Internet Liability and Policy Solutions November 6-7, 1997 Buena Vista Palace Resort & Spa at Walt Disney World Village, Lake Buena Vista, FL There are many issues surrounding the Corporate Internet in 1997 including: acceptable use & policy development, content control, legal liability, legislative impacts, employee monitoring and management responsibilities. CyberRisk '97 has been developed to address these issues and offer practical, real-world solutions to those charged with creating policies and determining appropriate Internet use for their respective organizations. The Conference includes an optional Internet Policy Development Workshop. See <http://www.ncsa.com/events/conferences/cyberrisk97.html> for full details or call 800-488-4595 and press "2" at the prompt. M. E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com
Please report problems with the web pages to the maintainer