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…
Following the story in RISKS-19.13 (and its followup in RISKS 19.14), the *San Francisco Chronicle*, 14 May 1997, carries a story about an unexpected power outage due to human error. Bank of America had the problem during ``routine maintenance on half of an electrical substation the bank operates at a data processing center at Market Street and South Van Ness in San Francisco, a worker accidentally shut off power to the online unit.'' The supply was quickly restored, but ATMs were out of action for 2 hours as the entire ATM network had to be rebooted. The article does not explain why this had to happen. The result was that 1529 ATMs (all of Northern California, approx 40% of Bank of America's ATMs) displayed ``Sorry this Versateller ATM is temporarily unavailable.'' The system that allows bank tellers to access customer accounts held at other branches was also down, so customers who were not at their own branch couldn't even go into the bank to get money. B of A is apparently investigating how one power failure can bring down the entire Northern California ATM network... Mathew Lodge, Product Manager, Cisco Systems, +1 408 527 4908 [They should have been reading RISKS! It would have been obvious. PGN]
Over 3 years ago, Barry Lyn Stoller was mistakenly sent a refund check for $98,002 for a $1.99 box of Ex-Lax. Apparently, a buggy new software system had used his ZIP code (98002, for Auburn, Washington) instead of the $1.99 amount. Stoller deposited the check in his savings account, cleaned out the account, and then disappeared for three years. He was apprehended only because a routine police check turned up the earlier warrant. He has now pleaded guilty to first-degree theft. [Source: on-line edition <http://www.seattletimes.com/extra/browse/html97/xlax_051597.html>] of the *Seattle Times*, 15 May 1997, PGN Abstracting]
Remember the five systems stolen from the Florida DMV? The ones that make the ``Unforgeable'' licenses? (RISKS-18.94) Well, now it's Oregon's turn... (Note: Lake Oswego is a "high income" suburb of Portland.) The Oregon Department of Motor Vehicles is now using a ``credit-card'' style of license. Over the weekend, burglars snatched more than $15,000 worth of digital photo licensing equipment from the Lake Oswego Driver and Motor Vehicle Services office, which was discovered Monday morning (12 May 1997). The equipment included a computer, Polaroid printers, cables, a blue photo background, and a Polaroid camera. This is reportedly the first theft of such equipment, and there are no suspects. Dan Dlugonski, customer service manager of the Lake Oswego DMV office, is quoted as follows: ``But even this theft may not have given forgers the coup they hoped for. One item which is critical to the production of the new license is kept under lock and key each night. And the equipment that was stolen will not work unless it is hooked into a special database.'' [Source: *Oregonian*, 15 May 1997, Metro section, Cities and Suburbs. Lake Oswego] Comment: Anyone want to guess, with the printer, camera, supplies, etc, but no ``database'' what the probabilities are of someone being able to make a driver's license that at least LOOKS right? Now, if the ``print head'' of the Polaroid printer is removable and locked away, maybe they got nothing. (I hope that's a good safe!) I suspect there will be more to follow. Gary Grossoehme, Oregon Electronics [As we go, so goes Oswego. PGN]
A few months ago, I was using an on-line discount brokerage company E*Trade To Do My Trading With. Their Web site uses two passwords to control access, one password controls access to account information, balances, stock quotes, etc., the second password is used to confirm a trade. Recently I had a problem connecting with their site and needed to contact the company for service. As part of their telephone verification procedure, ie phone number, address, mother's maiden name, etc., they ASKED for my logon password. After questioning the Customer Support person she said that they can see my password on their screens. I asked her if she also had my trading password and she confirmed that she did by reading it back to me. Needless to say I sold out my position with this brokerage firm and I'm looking at using another brokerage service. Cliff Helsel chelsel@spacelab.net
I was asked by the SSA to be on a panel at their 6 May public forum in Hartford, CT, the start of a 6-city tour to get public input on what to do about making PEBES information available over the Internet. Each public forum has three panels: privacy advocates, computer/technology weenies, and commercial organizations. The Hartford panel included Robert Ellis Smith on the privacy panel; myself, Pete Troxel from IBM and others on the computer weenie panel; and Lynn McNulty (now of RSA) and others from Chase Manhattan, Pitney Bowes, and the Hartford insurance company on the commercial panel. We all pretty much told the SSA, and Congresswoman Kennelly (sp?) who chaired this session, pretty much the same thing as PGN's http://www.csl.sri.com/neumann/ssa.html says: making PEBES data available over the Internet *can* be done securely, authentication is only part of the issue, fraud detection needs to be used, it is a system level issue, an open review is required, issuing PINs or passwords in an out of band manner would be a good first step, etc. I particularly pushed the open review issue, saying security through obscurity is long dead. The SSA has had computer security folks in prior to turning interactive PEBES online, but it certainly wasn't an open review. The uproar over PEBES is a little silly, since it only made it marginally easier for fraud to happen, and in large part is the result of a widespread fear of some form of National ID Card. Senator Moynihan and Rep. Bill McCollum, Republican of Florida, seem to be pushing turning the SSN into such a form of national ID card, it has always been political suicide - ask the US Postal Service. Until the government implements a coherent strategy for US citizens using strong authentication for obtaining electronic government services, the cost of implementing those electronic services will always outweigh the savings. John Pescatore Trusted Information Systems 301-947-7153 15204 Omega Drive, 3rd floor 301-527-0482 (fax) Rockville, MD 20850 johnp@tis.com [For my SSA forum appearance in San Jose on 28 May, I added some caveats that may arise from relying on a public key infrastructure: http:/www.csl.sri.com/neumann/ssaforum.html]
> There is a chance that a malicious attacker can create two files with the > same MD5 hash, if he can create both files. > Consequences? Yet another reson to distrust code signing. The solution to this problem follows directly from the analogy to paper documents. In a gentler age, certified documents would be physically altered by the stamp, seal or embossing mark of the authenticator. I propose that when a digital document is certified, the certifier should first make a small, random, benign change to the document, compute the checksum on the *modified* document, and then sign that. In executables, space could be left for this ``seal'' by compiling in an otherwise unused data element (e.g., char sign_here[32] = "__sign_here__"). For interpreted documents, (including PostScript) an embedded comment can be used. Because the author won't know the document's checksum a priori, s/he won't be able to construct its evil twin. Wayne
Thomas Koenig is correct about the weakness in MD5, but recent postings in sci.crypt mention that he might be incorrect in the possible consequences. The weakness essentially allows an attacker to create two files that would have the same MD5 checksum, under very stringent conditions. However, the chances of finding two executable, meaningful pieces of code that would have the same checksum are so low that it can be considered computationally infeasible to do so. A more plausible consequence is that two cryptographic keys are created that have the same MD5 checksum. Then any digital certificate for one key would be valid for the second as well.
The IBM Mainframe comes with a support processor that has the ability to load patches into the system. The set of patches could be loaded either manually or at a scheduled time in the future. We provide the scheduled capability so that the user can have the patch installed at a time when the mainframe workload is light (such as the wee morning hours). Some of the patches requires that the support processor gets rebooted (so that it can install dynalink files that can't be installed while the support processor is running). When the patch is installed, it reboots again to finish the patch process (update files, to re-activate the system) The patch clean-up routine is invoked via scheduled operation which somehow knows that there is a scheduled patch operation that must be started on the second reboot and starts the patch cleanup routine and system activation. The patch routine initially creates a scheduled operation to kick off the clean up routine before starting the initial reboot. Since a date and time must be provided, the value was set to the first of the next month. This ensures that the scheduled operation won't be kicked off before the reboot. Several years ago on a customer's machine, a patch took place via scheduled operation. Patch rebooted the system which installed the patch. On the second reboot, due to a bug that has nothing to do with either scheduled operation or patch, scheduled operation patch handling routine was bypassed and the patch never performed the clean up routine. You guessed it. On the first of the following month scheduled operation kicked off the patch cleanup which did its job and reactivated the system. At the time it did this (which was in the wee hours of the morning) the customer in question happened to be working on the system and I won't describe the customer's reaction at that time. The patch routine was patched so that the date of the cleanup routine will start on the 31st of December, FEFF (hex). To explain, scheduled operation has a beginning time window and end time window - since the end time window was not specified, it defaults to 256 years later or FFFF (hex). This way if the patch cleanup routine happens to be inadvertently left behind, it will remain stuck on the queue until long after we all retire if it doesn't get cleaned up. After this patch was carefully tested and made available to all of our customers, we learned that some of our customers in Japan was no longer able to have their code patched - either manually or automatically. Upon further analysis, we concluded that these customers configured their system using local time instead of UTC. So when patch created the scheduled operation, it had a start window at Dec 31, FEFF, end window at Dec 31, FFFF. One of scheduled operation's job was to ensure that the end window is at a later time than the start window, otherwise scheduled operation is rejected. But, before this date comparison was made, Scheduled Operations converted the local time to UTC. By adding a few hours, the start window became Jan 1st, FF00 and the end window - you guessed it - Jan 1st, 0000. Unable to verify that year 0000 > FF00, it rejected the request and thus the patch was unable to do its job. Our solution was to change the start window to Dec 25, FEFF and plan our retirement a week earlier. Josh Bieber, Support Processor Console Functions Microcode, Department G41 Office 250-1M003, Glendale Lab - Endicott, NY
As if we didn't have enough problems, we don't know when the year 2000
starts. Even more of a problem for the year 2000. It all depends upon how
many dams we build, what the whether is and all the other functions that
reflect the rotation of the Earth.
The culprit is the leap second. Not a big deal if our watches are off by a
second or so once in a while — they are rarely that accurate. A very big
deal for those who depend on the most minute positioning of the stars
relative to the Earth.
But computers are caught in the middle since they must convert between
representations and there is simply no way to convert between future years
and the number of seconds since a base date because the leap second is
based on unknown events in the future.
It's as if the inch were based on the length of the current King's thumb.
Hard to write real estate deeds using such a measure.
The solution is very obvious. Just stop this silliness about leap seconds.
Of course, astronomers will need to keep their correction factor but they
care enough to do it. The rest of us can easily live a small error. I'm
not worried about being a day off in the year 100K.
Is this a real problem? Assuming I'm correct about the definition of time
conversions, the answer is yes. You simply can't write a program that
compares two converted representations of a year. Technically because you
can't do the conversion repeatably and pragmatically because I don't know of
real conversion routines that have the necessary leap second tables anyway.
Worse if a few actually do.
And one is allowed to write:
Date CurrentDate;
same = Date("Jan 1, 2000") == CurrentDate.
This is the proper way to write the code and the == operator is not
supposed to know ``Oh, it's a year comparison, I can fudge it.''
Bob Frankston effectively suggests running Internet (or Intranet) machines on TAI. Both TAI and UTC are based on the same second standard - the difference is just leap seconds, which, as he notes, is dependent on human decision rather than an algorithm. The current NTP (Network Time Protocol) is a distributed adaptive algorithm for clock synchronisation based on a server hierarchy: one obtains the time from three servers with short transmission delays (measured experimentally and adaptively) and uses continuous adaptation to improve synchronisation of the local clock time with that distributed by the servers. The servers are `stratified' according to quality. For example, the Stratum 1 servers in Erlangen and Osnabrueck in Germany get the time from the PTB radio standard UTC clock broadcast from Frankfurt; Stratum 2 servers will use these as sync sources, etc on down. So the first disadvantage of Bob's suggestion is that we'd need to know leap-second history in order to synchronise our nets to TAI, rather than letting leaping tocs [tics?] lie. But, he may point out, at least we only have to know the past rather than divine the future the same way as Parisians. A second disadvantage to his suggestions is that there's no technical reason why GPS should not soon become part of the Internet, when we all have pocket servers/browsers/mailers/videoplayers and we're running IP addresses through satellites. So we'll be bound to UTC. And of course anyone who wants or needs to can recalculate TAI from UTC. But he does make a case for using both, or at least being more careful with algorithms relying on time calculations. There are certain physical limits to what can be done in the way of synchronisation. I have just learned from Ben Torrey (reuben.g.torrey@ac.com) that from what he understands, due to the effects of gravity as predicted by Einstein's GenRel, the atomic clock in Denver, a mile high in the Rockies, runs a few microseconds per year slower than the one in London, i.e., real physical processes run that much slower. He suggests that may have some consequences for the local lifestyle. Indeed so - as has been known to Californians for some decades, the higher you are, the slower you move...... Peter Ladkin, Universitaet Bielefeld, Postfach 10 01 31, D-33501, Bielefeld, Germany http://www.rvs.uni-bielefeld.de +49(0)521 106-5326/5325/2952
retaliation against my public anti-SPAM activities
We are a very small company. We are being attacked electronically, because
of my public anti-spam stance:
(A) Our server was subjected to an inbound bombing from the hijacked
servers into our mailserver last night (14 May 1997).
(B) Thousands of messages were sent OUT today (15 May) from the same
hijacked servers, resulting in a torrent of complaining, hostile, violent
mail to our mailboxes. Some people began to mailbomb us with large
documents.
I have 99.9% confidence that the hostile messages were injected into the net
from a computer dialed into enterprise.net, a UK ISP, and have the
corroborating records to prove it, at least everything I can get without
cooperation from enterprise.net. I am unable to reach anyone at
enterprise.net who will assist in this investigation.
The messages were relayed off nevwest.com and freenet.carleton.ca SMTP servers.
The administrators at these sites have not been terribly supportive, though
they claim to be working on it. They have also received quite a bit of
inbound mail, but appear somewhat unsure about what to do or ``how that
happened''. They've asked me if *I* sent the messages.
Complete details of the attack and my anti-junkmail posting which started
all this appear here:
http://www.agentzero.com/junkmail
The message I have sent out follows. I need support from the UK. I am
prepared to do whatever it takes to get a prosecution.
-- quoted message follows --
My domain newmediagroup.com is under attack by someone who doesn't like my
MILITANT, PUBLIC ANTI-SPAM stance. To date, their actions have included
sending apparently several thousand e-mail messages, forged showing my name
as the sender. In addition, this same party or someone working with them
conducted a denial-of-service attack on our system last night, 14 May. See
http://www.agentzero.com/junkmail, including system logs clearly showing the
terrorists' use of third-party unsecured SMTP servers as relays (which you
will also see by looking at the headers of the messages that were sent).
Their attack has also included threats of harm against me.
PLEASE let people know this did not originate at newmediagroup.com. It is a
complete forgery. We are TRYING to investigate and at the moment have a
number of backbone carriers and MCI security, involved. I am doing all I
can. PLEASE tell people to stop writing to complain. This did not come
from us. We don't spam. I am FIGHTING spam and that is why I was targeted
in this manner. When you see their mail-bomb messages to me, you will
understand.
I am seeking cooperation from the sites that were used as relays. Sheila,
apparently an administrator at freenet.carleton.ca. (office@ is their e-mail
address; if you have received junk that bounced off their mailer, I STRONGLY
suggest you contact them and demand the holes be closed.) Carleton Freenet
has notified me (15 May 1997, 1600 EDT by e-mail) that they will not release
their SMTP logs, which would show the origin of the message injected into
their mailer. A man reached at nevwest.com said he had ``one technician
working on it'' but really didn't understand the specifics, and was not very
excited about helping. This is all very exciting for electronic terrorists,
I am sure.
New Media Group (and I in particular!) do not send or generate commercial
e-mail. Ever. We are a small Internet presence provider working closely
and on-site with clients in the Midwestern US. Only. We do not seek,
service, or advertise to anyone outside that area, and we do not use e-mail
for advertising.
Copies of all logs and the threatening messages which came here have been
forwarded to security officers at all ISPs we could identify, and at the
security offices of backbone providers involved in this. We're trying, but
it will be difficult to identify who did this. We're trying. I fully
intend to press criminal and civil charges at the very moment an indictment
becomes feasible.
The reason we have been targeted is that I (personally, not this company)
have been leading a campaign AGAINST junk e-mail. Please help me find out
who did this.
If you look at the headers, you will see that the messages did not come from
here. The incoming messages threatened more attacks unless I stop my
campaign to free people from unwanted junk e-mail. This is terrorism, plain
and simple and I call on the entire Internet community to help track down
the responsible parties. I will appreciate any assistance you can provide.
I am offering a reward of $1,000 for information leading to the arrest and
conviction of the perpetrators of this crime.
NOTE ADDED 16 May 1997:
We were hit again overnight 15 to 16 May. This time messages were sent to
many addresses in the U.S. Primarily the incoming has been bouncing due to
bogus or no-longer-in-use names at these locations. The nature of the
addressing suggests that the names were culled from newsgroups and other
public sources, and that the system doing the gathering went back some
distance in time to get them, as many were expired.
... It's been a busy couple of days. We have received approximately 2,500
undeliverable messages in the last few hours. (Normal is 20-50 per day.)
The incoming complaints and attacks are slowing, because I think people are
learning that jim@newmediagroup.com is ANTI-junk. Word is getting out, and
hopefully that will help in the future.
Actually, InterNIC lists two reasons for a domain status to be on hold (besides an official delete request): non-payment and lack of name service (see http://rs.internic.net/support/tele/domain-delete-domain.html). (I think disputes over a domain name might cause a hold as well.) A representative from InterNIC said that they don't release the reason for putting a domain on-hold to third parties. A representative at ACM member services whom I called (since I, too, rely on the service) stated that the problem was with their ISP. So it's entirely possible that the name server that serves acm.org failed and InterNIC detected the failure. In any event, the problem was resolved within 24 hours. Jim Huggins (huggins@umich.edu / huggins@acm.org)
I would bet that it's the InterNIC - given my experience with them. ... We moved in mid-1996 from Ohio to California, changed the corporate name, got new phone numbers, etc., but, we wanted to keep our Internet domain name (all.net). To make a long story short, it took them almost a year to update our information, and they only did it after we repeatedly refused to pay them their fee (we were 8 months or so late by this point) until we got a paper copy of the bill (which they were sending off into the ether somewhere). They also used a wrong credit card number (despite reading it back to me correctly, they couldn't manage to submit it correctly), it took them several hours to get to someone at their site who could tell me that they couldn't change our InterNIC information unless they got e-mail from our site (which is impossible, unless you forge e-mail, when your site is off the air because they have terminated their services). Their automated mail-bots can't handle replies correctly, and there doesn't seem to be a process for escalating to a human being. Eventually, I was able to get the problem partially corrected, but it shouldn't take 30 phone calls, 15 e-mail messages, and nearly a year to change an address so they can get paid $50. I, for one, am in favor of alternative InterNICs. Let's make this a competitive industry and see if they can survive with this shoddy business practice in the real world. Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225
BKELCDEM.RVW 961210 ``Electronic Democracy'', Graeme Browning, 1996, 0-910965-20-X, U$19.95 %A Graeme Browning brow@clark.net %C 462 Danbury Road, Wilton, CT 06897-2126 %D 1996 %G 0-910965-20-X %I Pemberton Press Books/Online Inc. %O U$19.95 +1-800-248-8466 203-761-1466 fax: +1-203-761-1444 online@well.com %P 200 %T ``Electronic Democracy: Using the Internet to Influence American Politics'' Maxwell's "How to Access the Federal Government on the Internet" (cf. BKHAFGOI.RVW) tells what your (US) government can do for you. Casey's "The Hill on the Net" (cf. BKHILNET.RVW) is a kind of personal memoir of exploration of the use of technology among politicians. Browning here provides the basics, background and case studies for grassroots use of the net to affect and influence the political process. The first three chapters contain anecdotal accounts of specific political events that have been influenced by net-based activities. This is readable, interesting, and even informative, but many similar works go no further. Browning proceeds to advise on acceptable tactics on the net, as well as the potential downside to political use of the Internet. There is a brief look at some related technologies, and a set of resources (which the author admits are personally selected and not exhaustive). A realistic, useful, and balanced guide. copyright Robert M. Slade, 1997 BKELCDEM.RVW 961210 roberts@decus.ca rslade@vcn.bc.ca rslade@vanisl.decus.ca
Please report problems with the web pages to the maintainer