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…
Memoirs of a (media star) virus researcher [MEMOIR7.CVP 930515]
I have been known, from time to time, to make rather unkind statements about
the accuracy of virus reports in the mainstream media. Some of my antipathy
arises simply from the fact that there is an awful lot of "mythology"
surrounding viral programs, and most of the pieces that appear in the media
simply perpetuate this. Some of my experience, however, is first hand.
I like live radio best, and TV news the worst. "Live" anything gives you a
bit of control, whereas TV is, in my view, arrogant, sensational and overpaid.
However, the electronic media still doesn't have an "all-computer" channel, so
most of the media reports about viral programs happen in print media. I've
had a few forays there as well, but would like to outline one recent
experience.
A reasonably prominent periodical devoted to security topics has been
advertising for writers in, among other areas, the virus field, so I sent some
sample materials off. I did not hear anything for about eight months, and
then got a call asking me to do an article. On groupware. Well, OK,
regardless of the topic I can use the money. Only there isn't very much money
slated for this, slightly under $400 for roughly three pages of material.
(Please have it ready in 20 days.) It doesn't take long, at that price, for
the "rate per hour" to drop into the basement.
However, it is not enough to write the article. No, one has to contact the
vendors, and hear what they have to say on the topic. This, actually,
consumes the most time. Some research, and roughing out an outline, took up
two hours. A rough draft took three. Polishing the final draft took about an
hour. Lots of room for profit there. (Of course, when you consider the years
it takes to build the background to be able to do that, it tends to reduce the
margin a bit ... :-) But contacting three consultants, two user group
representatives, and eleven representatives from seven major vendors took more
than fourteen hours spread over a ten day period. In the end it got me one
very helpful vendor contact (Carol Smykowski from Fischer International, very
nice lady), one returned message, one faxed spec sheet from a loosely related
product and a heavy parcel that arrived postage due after the deadline.
Needless to say, this was less than helpful to the project.
In the end, the article was rejected. Not enough "vendor quotes".
However, is my whining and complaining of any importance to you? Well, yes,
it is. What is really important here is the fact that most of the articles
being generated in the "trade press" are, by and large, "infomercials" on the
printed page. Articles are being written, by people who, if they have a
technical background at all, are writing out of their field, and are being
judged on the acceptability of the content to vendors and advertisers. The
vendors, quite happy with the situation, are in no hurry to be helpfully
involved in the process (or, indeed, even to return phone calls).
(As two examples, I cite the recent (as this is written) releases of PKZip
2.04 and MS-DOS 6.0. For the first month after the release of the new PKZip,
while the nets were stretched by the reports of the various bugs, and the
latest release by PKWare to try to correct them, PC Week blithely rhapsodized
over "version 2" and advertised that it had version 2.04c (the real buggy one)
on its own board. Meanwhile, in spite of the protests of the virus research
community *before* MS-DOS 6 was released, and the almost immediate storm of
reports of bugs and problems with various of the new features, the trade press
is only now, after six weeks of ecstatically positives reviews of MS-DOS 6,
starting to report some of the potential problems.)
The primary distribution of this article will, of course, be the Internet, as
it is also my primary source of information. Unfortunately, the population of
"the net" is likely around two to five million. A large number, perhaps, but
very small in comparison to the estimated hundred million PC users alone. And
in that "larger" world, the inaccurate "non-net" media tends to hold much more
importance.
copyright Robert M. Slade, 1993 MEMOIR7.CVP 930515
Vancouver Institute for Research into User Security Canada V7K 2G6
ROBERTS@decus.ca Robert_Slade@sfu.ca rslade@cue.bc.ca p1@CyberStore.ca
Elizabeth Zwicky's report (RISKS-14.62) about cut and paste with the elbow reminded me of the "Case of the Overhanging Data Entry Operator", an anecdote which caused some amusement many years ago in the customer support department of one of the British manufacturers of mainframe computers, for whom I then worked. In those days, keying data directly onto disk, instead of punching onto cards first, was relatively new, and "Direct Data Entry" was a selling point. The DDE station was an intelligent terminal with disk, screen and keyboard. The operator used to log in giving a password. There was a fault in the password handling whereby a leading space would be accepted as part of the password when this was set, but leading spaces were ignored when the password was keyed at login. The temporary work-around was, obviously, not to use spaces in passwords. On one site, the support engineers were puzzled to find that, despite this advice, the fault was being repeatedly triggered on one DDE station, although the operator concerned emphatically denied having pressed the space bar when entering a new password. The proximal cause turned out to be that the operator was a well-built woman ... Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk
While the X method for cut and paste may be poorly designed, I think there is another RISK associated with system admin using window systems: namely, the tendency to leave a window open with the root account logged in. I don't mean to sound holier-than-thou, but it was always my practice to limit my actions as root to as few as possible, by always explicitly su-ing to root, performing a task, and logging out again. While this does not eliminate the aforementioned risk, it does tend to minimize it. Byron Rakitzis. <byron@netapp.com>
I think the advantages of cut-and-paste with X clients far outweigh such a potential problem. We should identify the main source of the risk, which in my opinion is general access to super-user privileged shells. This can be greatly reduced by employing one of those utilities that provide individual super-user privileged commands to specific users from their own accounts. It would be much harder to paste something that did damage in this scenario. Tim Cook, Systems Engineer, Deakin University.
>I've never liked the X method of cutting and pasting much,
>but I'm beginning to feel actively hostile towards it.
> Elizabeth D. Zwicky zwicky@erg.sri.com
Not to mention mixed platform, mixed GUI cut-and-paste problems. I am a
system manager for both VMS and Ultrix systems. I use an Ultrix machine
running Motif for my GUI, while most of the VMS users have DECwindows.
The main problem is the differing cut-and-paste buttons: Motif uses the middle
button, while DECwindows uses the right button (assuming a right-handed mouse
set-up). This becomes a problem when I run a standard DECwindows applications
with the display on Motif. Only the left mouse button (select text) remains
constant.
Plus, some DECwindows applications (notably DECwindows Mail) like to reset the
cut-and-paste buffer if you switch input focus to a certain window. (E.g.,
DECwindows Mail seems to put the text of the current message in the
cut-and-paste buffer automatically.) My autofocus mouse (ala Sun) wreaks
havoc with this. Many times I have selected text in one window, moved the
mouse to a terminal window, pasted, and had the entire contents of a mail
message run as Unix commands because I had accidentally had my mouse cross
over the DECwindows Mail window (focusing input briefly on it).
My solution? Live with it. It has not gotten to a point yet where I feel the
need to hunt down the various settings files (*if* this is possible) to fix
the problems by creating "Lishka's own standard GUI set-up". Being a system
manager, I use a good variety of computers and their various GUIs frequently.
Furthermore, I have to help users a lot, and I have found that if I customize
my own GUI and shell settings too much, then I can't function with the
standard GUI and shell commands. (It is very embarrassing to type all of
these arcane short-cut aliases in front of a user at her/his terminal, and
have them not work! You look incompetent....)
How to practice safe cut-and-paste practices? *NEVER* paste into a terminal
window with a superuser session (be it "SYSTEM" or "root"). This means one
has to type it all, possibly leading to transcription errors, but one should
always double-check important commands anyway.
Of course, as Ms. Zwicky's message shows, a lot of times pasting into a
superuser session window is unintentional. More than once I have gone to
scroll my xterm window (using the middle button in the scroll-bar area), only
to hit the middle button a microsecond too early. BLAM! I've just pasted a
mail message into my VMS SYSTEM session, and all of its contents are being
interpreted as commands. Luckily nothing major has happened because of this!
Sometimes I think going back to a good old VT100 terminal would be safer all
around....
Christopher Lishka PPE Division, CERN lishka@dxcern.cern.ch
The Macintosh Programmer's Workshop (MPW) shell provides an interesting solution to this problem ... you execute a line of text as a command by pressing the ENTER key (on the numeric keypad). RETURN simply inserts a carriage return in the text. Similarly, pasted text isn't interpreted as commands to be executed. I wouldn't mind it at all if xterms, cmdtools etc. worked this way. I've yet to experience disaster as a result of X pasting, but I've come close. Joseph Nathan Hall, Software Systems Engr, GORCA Systems Inc. jnhall@sat.mot.com joseph@joebloe.maple-shade.nj.us (609) 732-3194
An article which color interface designers would benefit from reading: Gary W. Meyer and Donald P. Greenberg, "Color-defective vision and computer graphics displays", IEEE Computer Graphics and Applications, v. 8, n. 5, Sept 1988, p. 28-40. It discusses how to select colors which are appropriate for the various types of color blindness, along with reasonable general solutions. Eric Haines
> "A black icon facing left to right means a call was placed, but no > contact was made. A red icon facing left to right means a call was > placed and contact was made, but a promise to pay was not received. > A green icon facing left to right means a promise to pay was arranged. > An icon facing right to left means the debtor called the collector." Not only are the color blind affected by the new monitors, so are the dyslexic. I can very easily see a dyslexic person interpreting a right to left icon as left to right. Suppose the person is color blind and dyslexic.... Tom Ohlendorf, Programmer/Analyst, Towson State University, Towson, MD 21204 OHLENDORF-T@TOA.TOWSON.EDU (410) 830-3642
The CHI community is aware of the potential problems that Vannevar Yu has pointed out. For example, the Macintosh User Interface Guidelines has 8 pages devoted to the use of color in applications. They urge developers to "Always develop for black and white first and then colorize that design". They point out that to accommodate "people with color-deficient vision", "you shouldn't use color as the only means of communicating important information. Color should be used redundantly." I'm sure that other user interface guidelines and texts make similar points. Perhaps the risks here are that applications developers are not aware of (or ignore) the literature about human interface design. Dave Tarabar dtarabar@hstbme.mit.edu
In response to David Sobel's statement about NIST and the DSS, I wrote in RISKS-14.60: ... NIST issued the DSS proposal along with a public call for comments as part of their normal practice with proposed standards. The community responded, and NIST promptly addressed the security concerns. Among other things, the DSS now accommodates longer keys (up to 1024 bits). As a result of the revisions, the DSS is now considered to be just as strong as RSA. In RISKS 4.62, Marc Rotenberg responded: Denning has to be kidding. The comments on the proposed DSS were uniformly critical. Both Marty Hellman and Ron Rivest questioned the desirability of the proposed standard. One of the reasons for the concern was the secrecy surrounding the development of the standard. The documents disclosed by NIST and NSA to CPSR make clear that NSA used its classification authority to frustrate the attempt of even NIST's scientists to assess the candidate algorithm. The DSS is similar to a scheme by El Gamal, which was presented at CRYPTO 84 and subsequently published in the IEEE Trans. of Information Theory (July 85). It is even closer to a scheme by Schnorr, which was presented at CRYPTO 89. The DSS is not classified and the basic approach has been under scrutiny by the crypto community since 84. All of the cryptographers that I have spoken with at NIST have made the assessment that the DSS (as revised in response to the comments by Hellman, Rivest, and others) is at least as strong as RSA for comparable key lengths. I am unaware of any evidence to the contrary. Also in RISKS-14.62, Bill Murray wrote While it may be true that DSS with a 1024 bit modulus is as secure for digital signatures as RSA, it does not meet either the congressional mandate or the requirement. The congressional mandate was for a public-key standard, not for a digital signature standard. The requirement is for a mechanism for key exchange. According to NIST, there was no Congressional mandate for a public-key standard. Congress did give NIST the charge to develop standards for sensitive, unclassified information, but it left open to NIST exactly what those standards should be. On its own initiative, NIST issued a solicitation for a public-key standard in the Federal Register, June 30, 1982. My understanding is that the solicitation was very broad and did not identify exactly what functions such a standard would need to provide. Several years later NIST, at their discretion, proposed the DSS. In retrospect, we can now look back and see how the DSS fits in with Clipper and Capstone. The result will be a complete package that has encryption, signatures, and key management/exchange. Thus, the advantage of RSA over the DSS in its ability to do key exchange disappears. It is very easy to be critical of a process when you are looking at it from the "stands" instead of the "court" and from hindsight rather than from current action and concerns. Dorothy Denning
Ed Roback's last sentence is the zinger, in terms of revealing
the state of mind of those involved in this effort:
...and of the law enforcement community for continued legal
access to the communications of criminals.
What ever happened to "innocent until proved guilty"?
Also, Clipper is only mandated for government use (he says).
I'm all in favor of exposing criminals in government, but is
this really the most cost-effective way?
Jim H.
They mean "suspects", not "criminals", don't they?
<> NSA's analysis on the security
<> risks of the escrow system is not available for public
<> dissemination.
<>
>>> >>>> NIST: It will not be possible for anyone from Mykotronx, VLSI,
<> NIST, NSA, FBI (or any other non-escrow holder) to
<> compromise the system.
Really? Then why is the NSA/NIST/etc *so* reluctant to release
details of the system? Details that are certainly known
(piecemeal) to the *anyone*s mentioned above.
<> To prevent this, it
<> is envisioned that every time a law enforcement agency is
<> provided access to the escrowed keys there will be a record
<> of same referencing the specific lawful intercept
<> authorization (court order). Audits will be performed to
<> assure strict compliance. This duplicates the protection
<> afforded nuclear release codes. If additional escrow
<> agents are added, one additional person from each would be
<> required to compromise the system.
<>
>>> >>>> NIST: No. First of all, there is strict and limited use of
<> subpoenaed material under the Federal Rules of Criminal
<> Procedure and sanctions for violation. There has been no
<> evidence to date of Governmental abuse of subpoenaed
<> material, be it encrypted or not. Beyond this, other
<> Federal criminal and civil statutes protect and restrict the
<> disclosure of proprietary business information, trade
<> secrets, etc. Finally, of all the Federal agencies cited,
<> only the FBI has statutory authority to conduct authorized
<> electronic surveillance. Electronic surveillance is
<> conducted by the FBI only after a Federal judge agrees that
<> there is probable cause indicating that a specific
<> individual or individuals are using communications in
<> furtherance of serious criminal activity and issues a court
<> order to the FBI authorizing the interception of the
<> communications.
You just *don't* get it, do you? You can make all the laws you want.
You *CANNOT* force anyone to comply with them.
And all the assurances you can give about due process and Federal
judges agreeing, etc doesn't hold water. What Federal judge agreed to
the ATF/FBI sponsored stupidity in Waco Texas recently?
As we have already seen severe erosion of the 'unwarranted search
and seizure' protection for the sake of the phony War on Drugs, how
can you expect anyone to believe the same thing wont happen on a much
larger scale. It's *so* much easier to search electronic
communications than someone's car.... Just ask the NSA.
And speaking of "only after a Federal judge agrees" it seems like you
just introduced a SINGLE failure point into the marvelous triple-lock
system so cleverly crafted....
skeptical, jim
I have put together a few sentences from NIST. Together they paint a rather
scary picture. I don't think I've changed any meanings by taking anything out
of context.
>>>>> NIST: There are no current plans to legislate the use of Clipper.
> .... The
> option for legislation may be examined during the policy
> review ordered by the President.
>>>>> NIST: .... We also
> point out that the President's directive on "Public
> Encryption Management" stated: "In making this decision, I
> do not intend to prevent the private sector from developing,
> or the government from approving, other microcircuits or
^^
> algorithms that are equally effective in assuring both
^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
> privacy and a secure key-escrow system."
^^^^^^^^^^^^^^^^^^^^^^^^
>
>>>>> NIST: You are correct that, currently, Clipper Chip functionality
> can only be implemented in hardware. We are not aware of a
> solution to allow lawfully authorized government access when
> the key escrow features and encryption algorithm are
> implemented in software. ..... Existing software
> encryption use can, of course, continue.
>>>>> NIST: No studies have been conducted on a government-wide basis to
> estimate the costs of telecommunications security
> technologies. The needs for such protection are changing
> all the time.
To me it looks like the line quoted from the President's directive only
protects private encryption if done in hardware. As they themselves say,
there is no known way to enforce the escrow of software encryption keys.
Can anyone speculate on the likely results of this "option for legislation"
that the President is going to "examine"?
So my feeling from reading all this is that the government may try to
legislate the use of encryption that can be implemented only in hardware.
I can see it now. "Responding to privacy concerns about the Clipper chip,
AT&T has privately developed a new encryption chip using a proprietary
algorithm. .... 'In order to ensure that this chip will assure privacy
as well as complying with new escrow laws, the algorithm has been submitted
to NIST's approval process, and we have made a few changes,' says AT&T
spokeswoman ...."
It would not surprise me at all if Clipper ended up in all Newtons,
cordless phones, and faxes by the year 2000. This will cause someone
to make incredible amounts of money. Has anyone wondered where all
this money will go? I am not trying to form a conspiracy theory
here--it is possible that the Clipper really was motivated by wiretaps
and no one realized how many Clippers could end up being sold. But
given the upcoming proliferation of wireless computers, I think this
question needs to be asked now. Whatever the origins of Clipper,
there is now a serious risk of corruption associated with it just from
the money involved. Does anyone have hard estimates on how much
additional money flow would be generated by using Clipper in all
wireless computers and communication products for the next 10 years?
Chris Phoenix, chrisp@efi.com, 415-286-8581
>What is the smallest number of people who are in a position to compromise the >security of the system? >>>>> NIST: It will not be possible for anyone from Mykotronx, VLSI, > NIST, NSA, FBI (or any other non-escrow holder) to > compromise the system. Under current plans, it would be > necessary for three persons, one from each of the escrow > trustees and one who knows the serial number of the Clipper > Chip [...] Clearly, NIST doesn't consider release of a chip's key to outside criminals by one FBI agent to be a compromise of security, if that agent got the key from the escrow agencies in a normal way. Does this mean that once a person has been subjected to a wiretap, he doesn't deserve any security -- no matter what the reason for the tap? What of the ability of a single gov't employee illegally to declare a national security tap and by weight of authority get escrow holders to release keys? This, too, sounds like a single-source of failure. What of the possibility of buying two people, one in each agency, to get copies of the whole database? That sounds like 2 rather than 3 to me. >Did the administration ask these questions (and get acceptable answers) before >supporting this program? If so, can they share the answers with us? If not, >can we seek answers before the program is launched? > >>>>> NIST: These and many, many others were discussed during the > development of the Clipper Chip key escrow technology and > the decisions-making process. The decisions reflect those > discussions and offer a balance among the various needs of > corporations and citizens for improved security and privacy > and of the law enforcement community for continued legal > access to the communications of criminals. Clearly, NIST believes that a set of meetings behind closed doors is an adequate discussion and that we the public should thank them for their effort and applaud their claimed "balance among the various needs of corporations and citizens for improved security and privacy and of the law enforcement community for continued legal access to the communications of criminals". Whatever happened to scientists at NIST? Why does it sound like we're hearing from PR men? Carl Ellison, Stratus Computer Inc., 55 Fairbanks Boulevard ; Marlborough MA 01752-1298 cme@sw.stratus.com TEL: (508)460-2783
I'm surprised that no one has commented on what I see as an obvious way to compromise the escrow agencies for Clipper. Suppose for instance that clipper phones were already available for several years. Suppose that during the recent Waco standoff, the BATF went to some gullible federal judge and said: "We have found that these people have got a large number of Clipper equipped phones. They keep using different phones, and it takes us hours or days to process the paperwork, contact the escrow agencies, etc. for each new phone they use. These delays are making a dangerous situation worse and give the cultists enough time to plan actions and execute them before we can decipher the recorded conversations. It endangers the children in the compound and the law enforcement people around the compound. We need you to sign this order that requires the two escrow agencies to release the entire set of keys to us. (Since we don't know the serial numbers of all the phones he might have.) Of course, we don't want the media and the cultists to find out about it, so there is a gag order included. Of course, we will destroy our records once the standoff is over." The frightening thing about this is that they only have to convince one federal judge. Mickey McInnis mcinnis@vnet.ibm.com
Please report problems with the web pages to the maintainer