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…
In the latest battle between man and machine, the ACM Chess Challenge between Garry Kasparov and Deep Blue, which took place in Philadelphia, 10-17 Feb 1996, the machine apparently ran into some unexpected problems. Many of these were due to improper handling of the input and output, rather than to the software itself. In the 22nd move of game four, the following happened. The description is taken from the transcript, which can be found on www.chess.ibm.park.org/deep/blue/commgm6.html; since this is a stenographic record, there may be some technical inaccuracies, but the essentials are correct. "DR. FENG: I went back and Garry is thinking I should wait there until I finish the moves. The monitor that we are using is an energy saving monitor so it went blank. So I went back and I am typing the move, A3 and somehow the A did not get recognised, it recognised it as 3. And it was a command to process number 3 and then I type F3 and the machine say I see a repetition and then say there is a beep. And it stopped beating [beeping?] after that. And then I check with the guy in the back room. They are saying that could cause the program harm and I checked with Valvo and we restart the program. Mr. Seirawan: So they had to restart the program and get it back up to speed. How much time did that cost the computer on its clock? DR. FENG: About ten minutes. And those are lost. Mr. Seirawan: Just to be clear, stay with us please, ten minutes to reboot everything and then ten minutes of lost thought time, so DEEP BLUE got hit with a 20 minute -- DR. FENG: It would have played the same any way. Mr. Seirawan: It got hit with a 20 minute penalty, it seems to me." >From the risk perspective, the situation is that we have a highly developed and very sophisticated parallel computer which is supposed to represent the state of the art, at least in chess computing. But apparently all the efforts have been lavished on the chess playing part and none on the interface or input checking. Checking the syntactical correctness of the input should be elementary, even - or particularly - in complex software systems. Woe to the student who forgets that! But what would have happened if the computer had not been playing chess, but been applied to share trading, controlling a train signalling system, a satellite, a nuclear power plant or something else where the consequences had been more severe for a third party? Erik Hollnagel, Ph.D., Principal Advisor, OECD Halden Reactor Project P. O. Box 173, N-1751 Halden, Norway +47.6918.3100 Erik.Hollnagel@hrp.no [In a language in which dairy is pronounced daily, I suppose this might be Deep Yogurt — as they say in California. PGN]
In Continental Europe, the comma is often used where anglo-saxons
would use a decimal point.
A continental student has just asked for help with a programming
problem - the following code loops infinitely:
while (fabs(some expr) > 0,001) {
iterate
}
Is this equivalent to the Fortran DO10I = 1.10 bug?
I'm just surprised not to have seen this before...
Alasdair
Friends running Chameleon under Windoze recently started being unable to use mail. Every attempt to resulted in an immediate GPF. But ftp, telnet, Netscape, etc., all worked. Frantic re-installs of any & everything had NO effect at all. Chameleon Tech support was totally baffled. Further, reading mail with OTHER programs ALSO resulted in crashes. This included replacing Chameleon with Eudora, Netscrape, etc. Yet each bombed in its own module. Four weeks into this, he spotted the non-obvious cause.... The system date had jumped to 2069 & it was the date-sorting that was crashing.... I'm beginning to seriously consider that advice [Dyson?] to withdraw ALL your money on 30 Dec 1999 & keep it cash for a day or two....
[Forwarded] At 02:30 PM 2/19/96 PST, Bill L. wrote:
There are fewer than 999 working days left until the year 2000. I know this
because one day several million dollars' worth of orders `disapeared' from
our manufacturing system. The problem was that we displayed only orders due
within 999 working days, which happened to [reach] the first working day in
the year 2000. The program basically displayed all orders with a date less
than 1-2-00, of which there were none.
How did we fix it you ask?
Why, we changed the program to go only 500 working days into the future.
[Lightly edited by PGN]
While riding home this past Wednesday (on my accident free commuter-rail
line), I came up with an approach to utilize the JavaScript "feature" of
Netscape 2.0 to track a user's browsing actions. The tracking happens in
real time with the user's browser dutifully sending results back to a remote
server, starting from the time the user visits a page with the devious
JavaScript embedded in it. It can thus sniff any passwords or keys the user
might use in a URL.
My example version runs in a browser window that the user can see. I'm only
demonstrating the vulnerability. Practically, the window can be made so
small as to be invisible to the casual user. It also helps that a user
isn't even informed when the HTML page they just loaded has some JavaScript
code within it.
Think about Netscape's new JavaScript-laden home page. The default action
on startup of Netscape 2.0 is to go to that page. It could easily start off
tracking your browsing actions. With the new on-line frontier being driven
by advertising, the value of such a log is immense. Of course, if Netscape
really wanted to do something like this, they could embed all sorts of
things directly in their browser. Naturally they don't, but this is
something that people often clamor about (e.g., the recent Microsoft Word
and the never ending AOL controversies).
As it stands, with Netscape 2.0 you cannot disable JavaScript. You can
disable Java. This is an interesting choice on their part, since at least
there has been a significant effort on the part of many people to justify
Java's claim of security and safeness. Thousands of people have pored over
the code and specifications.
But, JavaScript and Java are totally different things. They share common
names and syntax, but they don't share implementations. One is a byte
compiled language executing in a restrictive state machine, the other is an
interpreted scripting languages with vastly different properties. Compared
with the thousands of people have looked at the source to Java, no one has
seen JavaScript. Its specifications are defined by the implementation,
which to date is solely Netscape 2.0. We're told it is "Secure. Cannot
write to hard disk", which is how Java is also described. Is there enough
commonality for such a comparison? It is hard to determine that a program
is safe or secure after studying it. It is impossible without.
My particular history tracker is the third (or fourth?) way to steal private
data from a user via JavaScript. It stands out as the first one that does
it in real time, reporting history as the user is browsing. In an
interesting bit of irony, as I was writing the code to exploit this hole, a
news article from someone at Netscape appeared noting how they has fixed 2.0
during the "beta-test" period to avoid the latest of the history stealing
approaches.
As it stands, JavaScript adds a viral element to HTML. I'm not sure why
Netscape doesn't ship JavaScript disabled by default or why they don't alarm
the user before it starts to execute, or opens up new windows.
Finally, it is interesting to note that the Netscape Navigator already has
the building blocks to block the execution of any JavaScript (or Java) code
that doesn't come digitally signed from some trusted source. This would
help provide a real safeguard against the types of attack downloaded code
opens up.
My JavaScript examples are at http://www.osf.org/~loverso/javascript/.
John Robert LoVerso OSF Research Institute
Added note:
Did you ever try to teach someone the importance of keeping
their ATM PIN secret, only to find that they never lock the
doors to their house?
A non-empty subset of the hosts who have visited my JavaScript
"tracker" page run an X server with no access control enabled.
This message is a response to the DNS spoofing attack described in Drew
Dean's IEEE Security and Privacy paper, referred to by Drew Dean in his
RISKS-17.77 posting as being in http://www.cs.princeton.edu/~ddean/java/ .
Background
A bit of background on DNS: (apologies for the oversimplification)
DNS is the internet "Domain Name Service". It provides the mapping between
computer names and computer addresses. For example, the name
ds.internic.net has the 3 IP addresses, 198.49.45.10, 192.20.239.132, and
204.179.186.65. Probably, each IP address eventually is mapped onto a
different computer, although multiple IP addresses could also map onto a
single computer. The reason for many-to-many name-to-address mappings is
that it enables system administrators to balance the network load on their
machines. The name ds.internic.net is probably accessed hundreds of
thousands of times every day by people all over the network, so it makes
sense for that one name to be served by multiple machines with multiple IP
addresses.
Let's use the term "DNS spoofing" to mean that a computer on the
internet has been able to advertise a false IP address for itself.
DNS spoofing isn't directly related to Java, but might be used as part
of a Java attack applet.
Attack
The attack scenario is like so.
1) The machine evil.hacker.com advertises two IP addresses for
itself, the real IP address for that machine (say 1.1.1.1) and a fake
IP address for that machine (say 6.6.6.6). The fake IP address is
actually the address of target.com, which is the computer the attack
applet wants to try to connect to, later on.
2) Someone using a Java-powered browser loads an applet from
evil.hacker.com. Now, applets are allowed to make network connections
only to the machine they came from, which in this case is
evil.hacker.com. However, this attack applet tries to open a
connection to the computer named "target.com".
3) The applet security manager does a DNS lookup on the name
target.com, and checks if its IP address is in the pool of IP
addresses that this applet is allowed to connect to. It gets the
address 6.6.6.6. It turns out that this is one of the two addresses
associated with evil.hacker.com, and so the connection is allowed.
The connection should not be allowed.
Why is this attack possible?
There are two reasons why this DNS Spoofing attack works:
1) It's relatively easy for someone to advertise false IP
addresses. That is, it's relatively easy for someone
to run their own domain name resolver.
2) The applet security manager allows an applet to connect
to any of the IP addresses associated with the name
of the computer that it came from.
What's the fix?
The right solution for this problem is to make the Domain Name Service
more secure. It shouldn't be so easy for anyone to advertise false
names or false addresses.
A fix for the applet security manager is to be more strict about deciding
which computers an applet is allowed to connect to. The Java system needs
to take note of the actual IP address that the applet truly came from
(getting that numerical address from the applet's packets, as the applet is
being loaded), and thereafter only allow the applet to connect to that exact
same numerical address. Additionally, the Java system could be even
stricter than that, by declaring that an applet can only connect to the same
port number that it came from, in addition to only being allowed to connect
to the same IP address that it came from.
What's the bottom line for me today?
An applet on its own cannot carry out this attack. It would have to be
working in conjunction with a hacked DNS server owned and ascribed to some
domain.
Also, the attack applet would have to know the name and IP address of
machines inside a corporate firewall, in order to try to establish a
connection to machines behind the firewall.
Sun will be distributing a patch to the applet security manager to implement
the more rigorous checking described above. That fix will be available
within a few days, and it will be distributed in source code and in bytecode
format.
*The Boston Globe*, 22 Feb 1996, reports that Socks the cat appears to be
running an objectionable web site at the White House.
Surfwatch is a commercial product that attempts to protect the user from
objectionable content available on the Internet. Apparently it works by
searching for `hot' words. On the White House Web pages, Socks the cat has a
virtual tour of the White House and one stop on the tour contains the word
`couples'. This got that page on the tour blocked by Surfwatch.
Responsible adults may judge for themselves at
http://www.whitehouse.gov/WH/kids/html/couples.html
Dave Tarabar, SystemSoft Corp., 2 Vision Drive, Natick, MA 01760
508-647-2952 dtarabar@systemsoft.com
[Other filters have tripped on this one, but somehow have not get made
it into RISKS. The *San Francisco Chronicle* a while back showed
a web page with four photos — of the Pres and VP and their wives --
that was censored by one of the service providers because of the
offensive word "couples". Will RISKS now be so censored because of
this item? Stay tooned, he said, comically. PGN]
Recently (RISKS-17.70, item 1) I contributed a short article on the risks associated with an automated train-control system. A few weeks prior to that I had contributed a joke about French nuclear testing to rec.humor.funny. I'm also subscribed to the SCRNWRIT mailing list, and regularly make contributions. Brian Lynch reminded us (in RISKS-17.78, item 3) of some of the Risks of not thinking before submitting, but I have been rather nastily reminded of another. After both news postings, I received several rather nasty e-mail messages questioning my intelligence, heritage, and character. One response to the RISKS article suggested I was an idiot for not recognizing that only a moron would leave a speeding train under automatic control. (Which ignores several decades of psychological research on the willingness of people to submit to authority figures, such as the supervisor who refused permission to switch to manual.) The responses to the joke were even nastier. One writer suggested that people like me were "threatening the safety of the Free World" with such comments. (He probably could not know that I approve of the testing regime as important to the French weapons safety program.) While this hasn't risen to the level of threatening phone calls reported in RISKS-17.75, item 5, my office phone number was (until recently) included in my .sig files, so it is certainly possible that things could get that out of hand. I have made contributions in print media (for example, Letters to the Editors of both Newsweek and Playboy) but those have included only general information, such as a name and city. A determined attacker could still find me, but the ease of replying to electronic postings seems to encourage immediate attacks. Playboy now prints the e-mail addresses of people who send electronic Letters to the Editor. If I send Playboy anything in the future, I will be sure to send it on paper. I supposed I could stop contributing electronically, or ask that any contributions be anonymous. However, among the few flames were some thoughtful comments (and one kind correction) that I am loathe to forgo. The main Risks seem to be the ease and immediacy of electronic attacks, and the ability (using DejaNews, etc) of the disgruntled to gather additional details about a person with whom they disagree. This is not really news to veterans of Usenet newsgroups, but people contributing to any electronic forum need to be much more prepared for "flamage" than someone writing to a newspaper. Tom Comeau <tcomeau@stsci.edu> Computer Scientist, Space Telescope Science Institute
Re: Lack of Common Sense is Biggest Risk Of All (Gunderson, RISKS-17.73) At least at JPL, there's an enormous difference between the security procedures applied to the personal workstations and the flight workstations. I won't go into any details, to avoid giving anyone hints, but when a new procedure was put into place for access to the secure machines, my first attempt to log into the secure machines failed due to a misundertannding about the procedure. I got a phone call from the SAs within 6 hours, checking to make sure the series of failed attempts was indeed me. Kevin Maguire Kevin.P.Maguire@jpl.nasa.gov
The problem of files containing other information than that shown in the application which generated them certainly predates Word; I have seen such information by looking (with Xtree or similar) at various files. In particular, newsgroup postings often contain them, presumably due to people `including' files generated by their favourite WP without realizing that this would happen. Surely the problem is the original application saving more of memory than it needs, or (if the case is that garbage is picked up from the disc) incorrectly writing the file size to the directory when it does a disc write, so that subsequent reads read more than necessary? The extra information is certainly not needed to reconstitute the file. J. P. Gilliver, GEC-Marconi Research Centre, GEC-Marconi Ltd, GREAT BADDOW, Essex, CM2 8HN, UK. +44 1245 473331 x 2133 john.gilliver@gecm.com
If I may step back a bit from the wildcards arcana, perhaps the real risk is the notion that files are anything other than their entire contents. With MacOS, DOS/Windows and UNIX we (the humans) use filenames to identify files, while they (the computers) use serial numbers and the file contents to perform the same task. We choose to give our files names to indicate to us what the files contain. Some of us choose to give our files special names to indicate to the computer what the file contains. Now we've had two risks associated with this behaviour mentioned close together. One day it's Microsoft's Word for Windows and its virus, the next it's - oh, look - Microsoft's Windows 95 and its wildcard inconsistencies. (Interesting to note that the only complaint about UNIX's wildcarding was from someone who though ls was equivalent to dir - is this just because UNIX users are better-educated, or because UNIX is more consistent? Either way, the untrained users are the ones left with the poor tools.) But I want to consider the claim that the problem with OSes that offer a command-line is that they "require an equivalent amount of understanding of the inner workings of the operating system," which "may be unreasonable in an era of pervasive personal computing." What alternative can we go out and buy? Does using icons in preference to text help? The visual wildcarding is performed in one (terribly inconsistent) place - my brain. And I see files that look similar, and get the wrong one. Because if they *look* the same, then they obviously *are* the same. Does clicking rather than typing help? I can click quicker than I can type. And I can usually select all or "lasso" a group. So I don't use wildcards as much, and only resort to a shell when I want rid of all the files ending in .o (lasso-ing files with similar endings is harder than those with similar beginnings). So I'm less likely to abbreviate and make mistakes. But I make still make mistakes. They're just different mistakes. Off-by-one errors and accidental inclusions/exclusions of previous selections are hard to imagine at the shell prompt. Names are inadequate for describing a file's type, and they're even worse when it comes to describing a file's contents. It makes no difference whether I type a filename or click it, say it or write it (Apple do have one great product). It's the *naming* itself that's the real problem. Until we can ask our computers to "get rid of all the files that I'm never going to want ever again", there'll be trouble. But I'm not worried. I alias rm to rm -f, disable my dumpster and trust in backups. And even with such recklessness I've only ever had to ask for two files to be recovered. If you don't have a good system, make sure you get good users. - enh
Martin Minow described the virtue of Macintosh's two-stage delete process -- dragging a file's icon to the trash bin and then emptying the bin. However, what if I want to delete more than one file and do not want to do the drag and drop many times over (in other words, what is the equivalent to the use of wildcards)? A common solution is to select many files at one time (by holding down the Shift key and clicking on icons) and then moving them all in one go. Risks? Once I was trying to move a fair number of files (to another directory, not to the trash bin). After I had selected a few icons, I accidentally hit the space bar. In a flash all those selected files disappeared, straight to the void and not to a middle-stage trash bin. It is amusing that the largest key on a keyboard is assigned this short-cut functionality. Li Gong, SRI International, http://www.csl.sri.com/~gong/
I found an interesting variant on this theme. Using the IBM Windows package for FTP, I wanted to access a mainframe I never use and get a file which was supposed to have been put in my directory. The FTP package is nicely designed, with windows showing local and remote, and you select files either by typing a name or clicking, then hit on an arrow to transfer them. I was not sure what to expect nor what the file name might be, so I typed in "*" in the remote window and clicked on the arrow (I may also have given a confirming response). The PC disc seemed very busy and odd messages were flashing across the window: when I aborted, nearly every file in the current directory on the PC had been deleted. I guess the (cautious) IBM approach to transfer is this: Does the file already exist on the TO machine and directory? If so, remove it: if this works, transfer from the FROM machine. So, to transfer "*" you first delete "*" ... and to crown it all, in my case the file had NOT yet been copied for me to FTP. Result: copying all files to my machine added none and removed all. (It is possible that newer versions may be better behaved).
As far as the method of handling wildcards goes msdos is
consistent while unix isn't:
msdos: wildcards handled by application.
unix: wildcards sometimes handled by shell ("ls -l *") and
sometimes by application ("find -name '*~' -print").
(And weird examples could mix those.)
Due to better and more available libraries Unix usually comes out ahead, but
still we have inconsistencies with respect to (say) file names starting with
a dot.
Morten Welinder terra@diku.dk
Concerning the discussion about inconsistent expansion of wildcards I can't help submitting one of my favorite mistakes in assuming program behavior. I was using "mail -f toobig" on a unix system in order to distribute emails from folder "toobig" to different folders, one of them named "important". Now, if you save *incoming mail* to a folder it gets deleted automatically (mv'ed), if you do that from a different folder it stays there (cp'ed). I'm sure there are reasons for that. Now at a certain point I considered myself very smart and typed "s important;d" assuming that was one command for saving and one for deleting to be executed one after the other. The message "Saved to 'important;d' [New file]" quickly informed me about my mistake, I repeated the action using two commands as usual, made a mental note to delete the junk file and kept going. Then the work was done, I left the "mail" program, decided to clean up and go home. Thus, I issued "rm important;d". Although it was not funny I had to laugh when I was told "d: command not found". Worst of all, I don't believe that this sort of risk can be resolved unless one wants to use a formal language for issuing commands, which I don't. And do not tell me that clicking subsubwindows makes the situation any better. Rolf
Please report problems with the web pages to the maintainer