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…
The fallout from the 22-hour system outage last week of eBay, the popular Internet auction site, has resulted in an 18% tumble of that company's stock. Analysts seem to regard the technical problems as normal growing pains. Michael Bernstein of the Gartner Group regards eBay's technical and investor problems as relatively minor, and explains: "It's a fiasco like this that will force a company to really fix the problem." (AP/*San Jose Mercury News*, 14 Jun 1999; NewsScan Daily, 15 June 1999) http://www.sjmercury.com/svtech/news/breaking/merc/docs/000266.htm [Earlier eBay troubles were reported in RISKS-20.38. PGN]
Looking back from the future, 1999 will have been a pivotal year for
malicious software: viruses, worms, and Trojan horses (collectively known as
"malware"). It's not more malware; we've already seen thousands. It's not
Internet malware; we've seen those before, tool. But this is the first year
we've seen malware that uses e-mail to propagate over the Internet and
tunnel through firewalls. And it's a really big deal.
Viruses and worms survive by reproducing on new computers. Before the
Internet, computers communicated was through floppy disks. Hence, most
viruses propagated on floppy disks, and sometimes on computer bulletin board
systems (BBSs).
There are some obvious effects of floppies as a vector. First, malware
propagates slowly. One computer shares a disk with another which shares a
disk with five more, and over the course of weeks or months a virus turns
into an epidemic. Or maybe someone puts a virus-infected program on a
bulletin board, and thousands get infected in a week or two.
Second, it's easy to block disk-borne malware. Most anti-virus programs can
automatically scan all floppy disks. Malware is blocked at the gate. BBSs
can still be a problem, but many computer users are trained never to
download software from a BBS. Even so, anti-virus software can
automatically scan new files for malware.
And third, anti-viral software can easily deal with the problem. It's easy
to write software to block malware you know about. You simply have the
anti-virus scanner search for bit strings that signify the virus (called a
"signature") and then execute the automatic program to delete the virus and
restore normalcy. This deletion routine is unique per virus, but it is not
hard to develop. Anti-viral software has tens of thousands of signatures,
each tuned to a particular virus. Companies release them within a day of
learning of a new virus. And as long as viruses propagate slowly, this is
good enough. My software automatically updates itself once a month. Until
1999, that was enough.
What's new in 1999 is e-mail propagation of malware. These programs — the
Melissa virus and its variants, Worm.ExploreZip worm and its inevitable
variants, etc. — arrive via e-mail and use e-mail features in modern
software to replicate themselves across the network. They mail themselves
to people known to the infected host, enticing the recipients to open or run
them. They don't propagate over weeks and months; they propagate in
seconds. Anti-viral software cannot possibly keep up.
And e-mail is everywhere. It runs over Internet connections that block
everything else. It tunnels through all firewalls. Everyone uses it.
It's easy to point fingers at Microsoft. Melissa uses features in Microsoft
Word (and variants used Excel) to automatically e-mail itself to others, and
Melissa and Worm.ExploreZip make use of the automatic mail features of
Microsoft Outlook. Microsoft is certainly to blame for creating the
powerful macro capabilities of Word and Excel, blurring the distinction
between executable files (which can be dangerous) and data files (which,
before now, were safe). They will be to blame when Outlook 2000, which
supports HTML, makes it possible for users to be attacked by HTML-based
malware simply by opening an e-mail. Microsoft set the security
state-of-the-art back 25 years with DOS, and they have continued that legacy
to this day. They certainly have a lot to answer for, but the meta-problem
is more subtle.
One problem is the permissive nature of the Internet and the computers
attached to it. As long as a program has the ability to do anything on the
computer it is running on, malware will be incredibly dangerous. Just as
firewalls protect different computers on the same network, we're going to
need something similar to protect different processes running on the same
computer.
This cannot be stopped at the firewall. This type of malware tunnels
through a firewall using e-mail, and then pops up on the inside and does
damage. So far the examples have been mild, but they represent a proof of
concept. And the effectiveness of firewalls will diminish as we open up
more services (e-mail, web, etc.), as we add increasingly complex
applications on the internal net, and as crackers catch on. This
"tunnel-inside-and-play" technique will only get worse.
And anti-virus software can't help much. If a virus can infect 1.2 million
computers (one estimate of Melissa infections) in the hours before a fix is
released, that's a lot of damage. What if the code took pains to hide
itself, so that a virus won't be discovered for a couple of days. What if a
worm just targeted an individual; it would delete itself off any computer
whose userID didn't match a certain reference? How long would it take
before that one is discovered? What if it e-mailed a copy of the user's
login script (most contain passwords) to an anonymous e-mail box before
self-erasing? What if it automatically encrypted outgoing copies of itself
with PGP or S/MIME? Or signed itself; signing keys are often left lying
around the system. Even a few minutes of thinking about this yields some
pretty scary possibilities.
It's impossible to push the problem off onto users with "do you trust this
message/macro/application" messages. Sure, it's unwise to run executables
from strangers, but both Melissa and Worm.ExploreZip arrive pretending to be
friends and associates of the recipient. Worm.ExploreZip even replied to
real subject lines. Users can't make good security decisions under ideal
conditions; they don't stand a chance against a virus capable of social
engineering.
What we're seeing here is the convergence of several problems: the
permissiveness of networks, interconnections between applications on modern
operating systems, e-mail as a vector to tunnel through network defenses and
as a means to spread extremely rapidly, and the traditional naivete of
users. Simple patches won't fix this. There are some interesting
technologies on the horizon that try to mimic the body's own immune system
to automatically deal with unknown malware, but I am not very optimistic
about them. Sure they'll catch some things, but it will always be possible
to design malware specifically to defeat the immune systems. A large
distributed system that communicates at the speed of light is going to have
to accept the reality of viral affections at the speed of light. Unless
security is designed into the system from the bottom up, we're constantly
going to be fighting a holding action.
Melissa:
http://www.zdnet.com/zdnn/stories/news/0,4586,2233116,00.html
http://www.zdnet.com/zdnn/stories/news/0,4586,2234121,00.html
Worm.ExploreZip
http://www.zdnet.com/zdnn/stories/news/0,4586,2274306,00.html
http://www.wired.com/news/news/politics/story/20160.html
http://www.symantec.com/press/1999/n990614d.html
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
[On the other hand,] I ran *two* virus checkers against an attachment I got last week, and both said it was fine, so I opened the attachment. It was the new ExploreZip worm. Virus checkers inherently don't work on viruses that are newer than your last update of the settings file. In this case, I had the latest version of both checkers, but the virus was "too new" for either of them. Paul Hoffman, Director, Internet Mail Consortium
[Original Subject: A copy of Melissa Virus may have been detected in a message]
[NOTE: At least the intended recipient was CC:ed. PGN]
CONTENT VIRUS ALERT!
This is an automated response to inform you that a potential Melissa
computer virus (or variant) has been detected in an inbound electronic mail
message to:
[...]@health.gov.au
Date: Tue, 15 Jun 1999 12:07:31 -0700 (PDT)
From: owner-risks@csl.sri.com
[Subject: RISKS-20.44]
The message has been quarantined to prevent further propagation of the
virus. Please remove the virus from the original document(s) or program(s)
and send again. If you wish to discuss this matter, please contact the
postmaster as indicated below.
Email: postmaster@health.gov.au
Phone: +61 2 6289 7828
Fax: +61 2 6289 4928
[So, which part of RISKS-20.44 looked like Melissa herself? Presumably
the CERT Advisory which told where to get the advisories? PGN]
[BankBoston Gatekeeper Server also blocked the issue, but did NOT
CC: the intended recipient. I also had a note from Lindsay Marshall
(who handles the RISKS redistribution for the UK); he also reported
receiving such bounces. PGN]
The U.S. Supreme Court has upheld a lower court ruling that affirmed the constitutionality of a provision of the Communications Decency Act of 1996 that makes it a crime to transmit a "communication which is obscene, lewd, lascivious, filthy or indecent with intent to annoy, abuse, threat or harass another person." The provision had been challenged by a San Francisco company that had developed the "annoy.com" Web site to let people send anonymous (and allegedly "indecent") messages to public officials. (AP 19 Apr 1999, http://www.usatoday.com/life/cyber/tech/cte912.htm; NewsScan DAILY, 20 Apr 1999)
Barely 24 hours after DoubleClick said that it would acquire marketing research company Abacus Direct for $1 billion in stock, privacy coalitions announced that they would file complaints with the FTC, contending that the merged entity would pose a threat to consumer privacy. The merger, which would help DoubleClick build the ultimate online database of consumers, brings the company closer than any other to achieving every online marketer's dream. But along the way, DoubleClick may have stumbled into a consumer-backlash nightmare. [Jacob Ward: http://www.thestandard.com/articles/display/0,1449,5017,00.html]
<http://www.flatoday.com/space/explore/stories/1999b/061699e.htm> is a Florida Today article that claims that typos in software caused the loss of three rockets. Lindsay http://catless.ncl.ac.uk/Lindsay [The article claims that the 30 Apr 1999 Titan 4B failure (RISKS-20.39) is being blamed on a shifted decimal point in the software for the rocket's upper stage. PGN]
The article in RISKS-20.43 from Bryan O'Sullivan about troubles printing a PDF document reminded me of my own experience with PDF around tax time. I moved last year and had to file two different state tax returns in addition to my federal return. I downloaded some of the tax forms and publications I needed from the web, all of which were in PDF format, and ran into several cases of PDF forms that looked fine on my Win95 PC display but not so good when I printed them on a LAN-attached Laserjet printer: - Some of the Federal publications and instructions printed without any spaces between the words (luckily the forms themselves came out fine, at least the ones I needed); - The Illinois form IL-1040 was unusable; apparently it couldn't handle a character graphic about halfway down the first page and didn't print any of the rest of the form after that; - Many of Massachusetts tax forms are color-shaded and use colored areas in parts of the forms. When printed on a Laserjet, which doesn't support color, all these colors were replaced by shades of gray, making some parts of the forms difficult or impossible to read. Some of these problems may have been due to my local computing environment (though I think at least the Mass. forms should have been available in non-color versions). All illustrate the risks associated with assuming PDF is a stable and reliable format for online distribution of forms and documents. Joe McCauley
Antimissile missile hits flying target on 7th try An expensive experimental antimissile missile did Thursday what it had been unable to do on six previous attempts: Hit a flying target. A white puff of smoke in the southern New Mexico sky marked where the Army's Theater High-Altitude Area Defense, or THAAD, missile struck a target missile, which left a squiggly white trail of vapor just to the west. [Source: CNN item, 10 Jun 1999, http://cnn.com/US/9906/10/missile.test.ap/ [RISKS always seeks good success stories — although this one must qualify as only a relative success, considering the previous failures. However, we receive very few RISKS-relevant success reports, and do not want readers to conclude that there are no successes. But in the long run, it does seem that there are very few risk-free successes. PGN]
> [...] The probability of a collision between aircraft using GPS on > established air routes is significantly higher than between aircraft > using conventional navigation aids because of the greater accuracy of > navigation using a GPS. Intuitively, I doubt this. Here's the reasoning. To begin with, let us consider flight along, say, US Federal Airways. Firstly, (a) separation in instrument meteorological conditions is ensured by ATC. No change in risk here. Secondly, (b) aircraft flying under instrument flight rules in visual meteorological conditions are flying in cruise at different altitudes (thousands of feet) than those flying under visual rules (thousands + 500 feet). Thirdly, although I cannot find it in the US Aeronautical Information Manual (AIM), (c) pilots of aircraft flying visually on designated airways have *always* been advised to keep the airway centerline/fix to one side of them - yes, the same side (actually, this is well-known pilot lore all over). This takes care of the climb/descent problem. US Federal Airways extend horizontally to 4 nautical miles (4.6 statute miles) each side of the centerline. Federal Airways are defined by VOR transmitters not more than 50nm from any point on the airway that they are defining. Even though a signal may be distorted, all receivers will be receiving the same distorted signal, so any individual variation must be in the individual receivers in the aircraft. I can see no way of demonstrating either than pilots fly more accurately to GPS guidance than they do to VOR guidance, or that VOR reception is generally sloppier than the accuracy to which visual pilots are flying an airway (my experience, in fact, is quite the opposite, as would be that of most instrument flight instructors trying to get their proteges to hold a VOR course, I would suppose!). Unless one or the other of these can be demonstrated, one could not conclude that flying behavior on airways had changed significantly with the introduction of GPS. But suppose that one could demonstrate somehow that people were flying more accurately with GPS guidance. Then to conclude that the risk of collision was higher, one would have to show that the protocols (a)-(c) above were not in general being followed. Since (a) and (b) are enshrined in aviation regulations, and (c) in good practice/pilot lore, I doubt this would be easy to demonstrate. One other way to show that the risk of midair collisions had increased would be to show that there had been more midair collisions since GPS use became prevalent, and that this was not just a statistical fluctuation. Well, I don't know for sure, but I don't think there have been more. Even if there had, the cause of the phenomenon would have to be determined, and for the above reasons it would be very hard to show that it was due to suddenly-increased accuracy of flying of VFR pilots. So much for airways. On to other possibilities. Perhaps Wood was thinking of pilots wanting to fly to point X and lots of them all getting exactly to point X. If point X are the published GPS coordinates of an airport, there exist procedures to follow well before one gets to point X, which have been designed to alleviate the possibility of midairs in the neighborhood of an airport. One would have to imagine that somehow pilots are ignoring these procedures because they have a GPS, and I don't see how one could show any such thing. If point X is some specific sightseeing point, then I grant that there may be an increased need for vigilance since now one can navigate precisely to X. However, I don't know what the proportion of such flights would be, and I doubt that they are representative of most flights (It would seem appropriate to reiterate the usual warnings to pilots about increased traffic density in the vicinity of sightseeing attractions.) Finally, I should note the article in Risk Analysis 17(2):237-248, 1997, by Robert Patlovany entitled U.S. Aviation Regulations Increase Probability of Midair Collisions, brought to my attention by Hal Lewis (who, by the way, has written a fine, fine book on making decisions called Why Flip a Coin?, New York: John Wiley & Sons, 1997, which I found very entertaining as well as enlightening and have promised for two years to review for Risks, but haven't yet. Hal's got a great writing style. Read it. So there). Patlovany uses "a purely stochastic Monte Carlo model [..] to compare the relative midair collision course probabilities and mean closing velocities of four systems of rules for aircraft cruising altitudes as a function of altitude error: (1) current U.S. federal rules, (2) random altitudes, and (3) [etc...] The calculations verify that (1) federal rules increase collision course probabilities by about four times more than for a chaotic system of aircraft cruising at randomly selected altitudes, (2) risk is directly proportional to the level of compliance, and (3) [etc]." Note that Patlovany is considering cruising flight only, and altitudes, that is, vertical displacement, not the horizontal displacement which I take to be the relevant factor for evaluating Wood's GPS vs. VOR contention. Prof. Peter Ladkin Ph.D., Univ. Bielefeld, Technische Fakultaet, D-33501 Bielefeld (Germany) http://www.rvs.uni-bielefeld.de +49 (0)521 106-5326/5325
Lloyd Wood's comment regarding the probability of a collision between aircraft using GPS on established air routes applies equally to marine navigation. Navigation using electronic aids is generally from waypoint to waypoint. A "marine" waypoint is often a fairway buoy marking the end of a channel into a harbour or perhaps a buoy marking a shoal area at sea or a headland to be rounded. Vessels head from all directions towards the waypoints. A good lookout is necessary! This topic has had mention in the marine press for some years. It also reminds me of the use of radar for collision avoidance at sea leading to what is known as Radar Assisted Collisions!
This is to note we are still paying for the archaic way of using the *.xxx
extension for defining the file type.
This is only on Windows platforms which are a legacy of DOS days.
In most other platforms files have 2 parts (e.g. MacOS)
part1 resource fork
Contains the actual meta-data - program that created file, date of
creation, date of last modification ....
part2 data fork
Actual data
Now in the DOS-legacy world it is soooo easy to rename a file to another
extension and the file morphs itself. This is the sneaky trick/way used to
spread the latest virus/worm.
Another suggestion for *.ZIP files is NOT to double-click them and launch,
but to use the Classic mode of WinZip and check what is in the ZIP archive
before extraction. This would have let people know that it's a EXE file and
they could have taken precautions(?).
Another suggestion is not to have a completely homogeneous environment
(reminiscent of the potato"e" (apologies to Dan Quayle) famine)
Rumy Driver, Sybase Technical Support
I received quite a lot of mail on this subject. A couple of people helpfully tried to explain what they thought was the problem, based on their knowledge of DOS, but "assuming" that NT works that way, which it doesn't. (RISKs of assuming next-generation systems are infelicity-compatible, I guess.) Yes, in DOS, the wildcards *1.LNK and *.LNK are identical, since DOS treats * to mean "everything up to the period" (and there can only be one period). However, NT's wildcard matching does more or less what you'd expect - it's quite close to, say, how DCL does it under VMS. My problem is that it matches both the visible and the invisible filenames. For example, if I do this: C:\>copy afile.txt longname2.txt C:\>copy afile.txt longname1.txt C:\>copy afile.txt longname4.txt C:\>copy afile.txt longname3.txt C:\>dir /x long*.* LONGNA~2.TXT LongName1.txt LONGNA~1.TXT LongName2.txt LONGNA~4.TXT LongName3.txt LONGNA~3.TXT LongName4.txt > and delete *1.TXT, I "only" lose the first two files. > Footnote: Microsoft have, however, faithfully re-implemented in NT the wonderful DOS bug whereby, if you change a file's extension while copying it using a partial-match wildcard, the copy is done as if you said /A for ASCII. For example, if I have WINWORD.EXE and I want to copy it to NICK.XXX and I'm feeling lazy, I might say > COPY W*.EXE NICK.XXX without putting the /B switch on the COPY command. > Try it - you'll get a file truncated to the offset of the first ctrl-Z > character in the original. Thanks also to the person who pointed out that the automatic note appended to all outgoing e-mails from our site (saying that our domain name has changed), which PGN didn't chop off as he sometimes does with voluble sigs, contained a reference to a site which didn't work. Apparently this went wrong about two weeks ago. Of the 80000 or so Internet E-mails we have sent out since then, nobody else has bothered to mention the problem. This must mean something. Nick Brown, Strasbourg, France http://dct.coe.int/info/emfci001.htm
BKCRPESP.RVW 990424 "Corporate Espionage", Ira Winkler, 1997, 0-7615-0840-6, U$26.00/C$34.95 %A Ira Winkler %C 3875 Atherton Road, Rocklin, CA 95765-3716 %D 1997 %G 0-7615-0840-6 %I Prima Publishing %O U$26.00/C$34.95 800-632-8676 916-632-4400 fax: 916-632-1232 %P 365 p. %T "Corporate Espionage" This readable and realistic guide to becoming professionally paranoid has a special emphasis on data security and high tech companies, but can be very useful to pretty much anyone. Part one looks at espionage concepts. Chapter one, and the introduction that precedes it, points out that information is one of the primary sources of value in any business. Chapters two through five look at the basic ideas for any examination of data security, those of risk, value, threat, and vulnerability. Presented in terms, and with examples, that anyone can understand, they nevertheless form the foundation for examining security and protection for computer and communications systems as well as the sales "red book" for next quarter. Part two presents a variety of case studies. Winkler concentrates on the non-technical, relatively simple, and devastatingly effective "social engineering" aspect of break-ins. Chapter six is a compilation of tactics used in various penetration tests. One particular test is outlined in chapter seven. Chapters eight to eleven detail actual espionage cases carried out by foreign companies. A different penetration test is presented in chapter twelve. A third party account of a "crack" is discussed in chapter thirteen. Part three outlines what you can do to protect yourself. Chapter fourteen describes a significant list of countermeasures to take, starting with an effective education program. Finally, chapter fifteen presents a large scale program for overall security. This book is very down to earth, and very real. Unlike any number of "hacker" books, it doesn't attempt to impress the reader with displays of arcane knowledge: it doesn't have to. Technical details are almost non-existent, making the text an excellent choice for use in educating any level or type of employee on the need for security. copyright Robert M. Slade, 1999 BKCRPESP.RVW 990424 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer