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…
NPR's Morning Edition had a brief story this morning on high-tech Japanese toilets that include functions such as auto seat raise, warm rinse, and hot-air blow dry. Some of these have recently been implicated as a source of fires in houses. Reporter to woman shopping for toilet: "Are you concerned about the possibility of fires?" Woman (as translated): "No toilet is 100% safe. I am willing to accept some risk." Carl Landwehr, Mitretek Systems [Does this give new meaning to "going down in flames"? It also links the "Royal Flush" brand name with a red-hot poker player. PGN]
I had a report (which I've been unable to confirm, despite the time I've
spent waiting) that during the heat wave in the northeastern U.S. earlier in
July, a "weather" command on some computer at MIT produced the following
curious output:
athena% weather bos
Conditions at KBOS on 7/6/99 at 7:56 PM EDT (18:56 GMT)
Weather: Partly Cloudy
Temp: 2147483647 F (2147483647 C)
Visibility: 10 mi
Barometer: 29.72 inHg
Wind: NE 13 mph
Needless to say, the particular temperature value shown is intriguing to the
computer nerds among us! Steve Summit <scs@eskimo.com>
[Yup, it is 2**31 - 1. PGN]
eBay users have apparently been victimized by a nasty denial-of-service-like scam: Someone makes an early relatively low bid, then a totally out-of-line high bid (which discourages all other bidders), and then withdraws the high bid at the very last minute — which is allowed by eBay. This is known as bid shielding. See a Website created by Jason Hamilton http://mars.superlink.net/jason/ebay/ who was one of the victims.
<http://TOM.cs.cmu.edu/intro.html> This site offers a service for converting different kinds of documents into "viewable formats". it not only does Web-accessible documents, but also files that it will import using the form protocol for files. Imagine the potential for stealing information that this service opens up! http://catless.ncl.ac.uk/Lindsay [But, security by obscurity does not work too well for strange formats. PGN]
One of our engineers has decided to leave and go back to school to complete her Ph.D. and enter teaching, a career move we all wish her the best in. Before a going-away party could be scheduled however, she ended up in an unusually contentious software design meeting with four other momentarily-combative engineers, including myself. It was ugly! As I pondered whether or not I was out of line during the meeting, and how we could reconcile our differences so she could leave on a high note, our administrative assistant used Microsoft's Outlook/Exchange "meeting request" feature to schedule a lab-wide going away party. Unlike most engineers in the lab, I and one of the other combative engineers quickly hit the "accept" button which converts the e-mail based meeting request into a calendar item and sends a RSVP back to the meeting organizer. A day later, an update was issued on the same meeting request, and I scanned the request for the change. While the lab-wide mail list alias "Lab.All" was still on the "Required Attendance" line, I and one other combative engineer were now explicitly listed, by name, on the "Optional Attendance" line. My heart sunk at the thought that some of us were no longer welcome at her going away party. Good friends for so long, how could one lousy meeting drive us apart? After some tactful asking around though, it became clear that there were no hard feelings and no one had tagged anyone as optional. Ah, enter another Microsoft Outlook/Exchange feature. If a meeting request is sent to a mail list alias, and then individuals accept the request *and* use the option to e-mail back a yes/no response to the meeting organizer, Outlook/Exchange does not recognize that the individual(s) are part of the original mail list alias. If an update is then issued on the same meeting request, Outlook/Exchange treats the unrecognized names as optional attendees. Depending on the issue at hand, being explicitly listed as "optional" can take on a whole lot of extra meaning. Who needs enemies when you have Outlook/Exchange ;-) Thomas Gilg, R&D Software Engineer, Hewlett-Packard tomg@cv.hp.com
As someone who plans to practice critical care medicine in the future, I read Dr. Doyle's posting in RISKS-20.49 with interest. Although my clinical experience in considerably shorter (currently a senior Internal Medicine resident), I've noticed a number of incidents similar to that described by Dr. Doyle. Along the same lines, but more insidious, is the possibility of misinterpreting data because the computer processes the data in a manner different than one would expect. Case in point: Among the data that ventilators give regarding a patient's status are two values related to how much air the patient is moving. One is the tidal volume (the amount of air moved in a single breath) and the other is the minute volume (the amount of air moved over the course of one minute). It's very easy to assume that the numbers being reported by the machine are the actual tidal volume (air moved in the last breath) and the actual minute volume (true amount of air moved over the preceding minute). I've noticed that, at least on the ventilators used at my hospital, that this is not the case. Whenever we have an irregularly breathing patient, the reported minute volume changes very rapidly. Although I haven't been able to get a copy of the ventilator's manual to confirm my suspicions, it seems that the value reported as the minute volume is a calculated value based on the respiratory rate and the patient's last tidal volume. The risk here is that someone might not realize this. In an irregularly breathing patient, a doctor, nurse, or respiratory therapist might take a quick peek at the minute volume, assuming that the value reflects that patient's status over the entire last minute (i.e. an average of an entire fast-slow cycle) instead of being a snapshot taken at a brief moment of time. Also, in order to interpret the blood gases (a measurement of the pH, oxygen tension and carbon dioxide tension — used to decide if any changes need to be made in the ventilator settings) of a vented patient properly, one should take into account the minute volume that the patient has at the time the sample is drawn. Our laboratory computer allows the resp. therapist to enter the vent settings and minute volume along with the blood gas result so that they appear in the lab report. The person drawing the blood sample has to report something to the lab regarding the minute volume and this is usually whatever he sees on the readout at the time he draws the gas. The risk here is that someone reviewing the medical record might see the spurious minute volume value and conclude that the clinician made an erroneous decision regarding the blood gas values when, in fact, his actions were correct. For the record, the ventilator in question is a Siemens Servo 900C. My hospital also used the more advanced Servo 300 model, and I've noticed the same behavior in that model as well. (Anyone want to comment on the risks of designating a more advanced model with a lower model number?)(
Re: (http://www.zdnet.com/zdnn/stories/news/0,4586,2298512,00.html) The article on the jailing of a cell phone user in the UK continued with "`The scientific evidence showed that there was a real possibility of risk,' Ensor said". Of course, no references were given in the story. But they aren't necessary because we know that cell phones are immoral and dangerous and cause cancer. It reminds me of the moralistic attitude that made it so difficult to prove that ulcers were caused by bacteria rather than being punishment for a stressful (immoral) lifestyle. The real risk of this nonsense is in relieving the airlines for responsibility for safety. Many people will not turn off their cell phones because they are too mundane to think about. Why no outrage at the airlines for such incompetent design? Of course, the real problem will cell phones is that they confuse the systems on the ground and planes already survive the lightening and other sources of radio noise. But what does one expect from a system that provides only punishment for those who liberalize the rules? And where the issue is the perception of safety more than the reality. [We received lots of e-mail on this topic, most of it suggesting that there is still little hard evidence of bad effects. PGN]
I have long argued that the real problem with ActiveX is the inevitable proliferation of controls with security holes. Once an insecure applet is distributed, it can never be revoked because the signature is built into the applet... if you hit a site and it asks you to run an applet provided by Microsoft, are you going to say "no"? Richard Smith's article indicates that the problem is much worse than I expected, and worse than he realises: patches to the applets won't help... malicious users can simply provide the old insecure versions on their websites as trojan horses, depending on social engineering to convince "enough" users to just blithely execute the apps. No, any code that's automatically downloaded from the net (and that includes Office documents!) should be run inside a sandbox. For active content, there's Java. For Word, there's Word Viewer. For vendors who ship documentation as self-extracting archives and Excel spreadsheets, well, the best solution is education. I'm glad that Microsoft has recognised this problem and is providing "HTA" pages as an alternative to marking applets as trusted. Let them save face, so long as the problem's fixed, and turn off ActiveX for all other purposes. Peter da Silva <peter@baileynm.com>
Wasn't this the problem with Eudora executing Javascript in e-mail? It was (cached) on the hard drive, and thus safe? The core problem is that Microsoft is blurring the boundaries between the computer and the web. The problems that such blurring creates are subtle, often misunderstood, and hard to fix. Richard's proposed solution of HTA applications means that an attackers needs to get something to cache a file on disk, and something else to read it. Or, "Beware of SystemWizards, for they are subtle..."
Are you operating a mail server at a university department, with lots of one-user machines, Unix and whatever, hanging around on your network? Is your host being used as a smart host by those end-user machines? You should better go to www.imrss.org and check whether your mail relay is listed as an open relay there. The probability is high - but I'm sure you haven't been told that your machine is on the list. IMRSS is scanning the Internet for open mail relays. They try to send a test message through your machine, and look whether it gets back to them. If that's the case, the IP address from which the message was delivered to them is considered to be an output funnel of an open relay, and added to their database of possible spam mail sources. That database is available via DNS, ready to be used by any modern mail server software for blocking any mail which gets delivered from the IP address in question. The problem: IMRSS is _not_ going to tell _you_. But they are going to tell _anyone_ who happens to _ask_ them about _your_ machine. Obviously, this is bad style (as is the fact that you don't get reasonable contact information from their web pages, as is the e-mail autoresponse you get when you try to contact them, and so on). There are some actual RISKS connected with IMRSS' approach, too. For instance, you may learn about your outgoing server being listed with them from your users, whose messages get suddenly bounced from certain sites. Not grave, but not the thing you really want. But worse: IMRSS is actually doing spammers a favor. Wanna spam through open mail relays? Just look out for your favorite university (or internet provider), and feed the IP addresses used by it to IMRSS. You'll get a nice list of open relay candidates, including the workstation in that proferssor emeritus' office the administrator doesn't really care about. Possibly, you, the spammer, know about this before the administrator has learned that he may have a problem. I checked this for a major German university, and got several dozen relay output funnels, some of them corresponding to another dozen input funnels. The administrators have been notified. Finally, suppose you use IMRSS' database to block e-mail. Be assured, they'll have lots of major relays listed there, possibly without these relays' administrators knowing about this. Are you really sure that none of your users or customers is expecting important or critical messages from a machine IMRSS considers to be a possible spam source? You better be. Because _this_ is _your_ RISK. Web references: - The initial announcement of IMRSS to the spamtools list: http://www.iecc.com/cgi-bin/artget?t19981208011 - IMRSS' home page: http://www.imrss.org/
In the case of the phone lines that locked up when they could not reach the emergency 911 number --- when a major 911 system went down near Toronto (see previous message): That the phones lock up is an intentional feature so that the 911 operator has a chance to get the information about the calling number and send help even if the caller is unable to communicate. Unfortunately, the "lock up" does not time out even if the 911 system doesn't answer within any reasonable period, and so the phone can't be used to reach any other number. At least 24 people's phones are known to have locked up. Based on estimates from Peel police, there might have been another 110 or so calls that did not get through to 911. About half of calls to 911 in the area are typically genuine emergencies. Meanwhile more four days later, Bell has still not restored full service to the downtown Toronto financial district after a disruption at a switching centre. (See previous message.) At least two Toronto Stock Exchange systems are still down, as are a number banking machines.
Mail is doing the rounds in the UK about an Y2K banking scan which goes something like this: Someone calls telling you that they represented your bank, and that they were having difficulty meeting requirements to be computer ready for Year 2000. They say that all bank customers would need to transfer their accounts to a bond account, specially designed to protect their money until the bank can fully comply with the Year 2000 requirements. To verify they talking to the proper account holder, you need to confirm some personal information, i.e. account number, sort code, and verbal authorisation to transfer funds to into the specially designed account... You can guess the rest. Mike Ellims, Pi Technology mike.ellims@pitechnology.com www.pitechnology.com +44 (0)1223 441 434
> ... is current education in digital circuit design sufficiently attuned to > the subtleties of the physical world, or do students have an overly > simplistic view of how bits are represented in hardware? ... I believe that people who design chips and other circuitry to perform specific logical computations are generally aware of the need to assess whether the physical behavior of their circuits actually implements the logical specifications. That is one of the basic uses of the public domain circuit analysis program SPICE and its variants. That said, the complexity of large chips and the fact that their scale may be bumping up (down?) against quantum phenomena calls into question whether the equivalence of their physical behavior and logical specs can truly be verified. Pereira is certainly correct about the deterioration of "continuous" math education. Jim Dukelow, Pacific Northwest National Laboratory, Richland, WA 99352 jim.dukelow@pnl.gov [Standard RISKS disclaimers apply.]
In reading Henry Baker's thoughtful article, I am strongly reminded of
something the late Isaac Asimov once said:
The most exciting phrase to hear in science, the one that heralds
new discoveries, is not "Eureka!" (I found it!) but "That's funny..."
Asimov's point is similar to Baker's: that discovery is more driven by
the desire to understand mistakes, discrepancies, and other "funnies"
than by pure intellectual will.
Jim Thompson <jim.thompson@pobox.com>
A VERY excellent account of Kepler's achievements can be found in Arthur
Koestler's book, the Sleepwalkers. As I remember, it was published in circa
1959. It should be in your local library. I encourage all to read it. It
is a history of cosmology from the time of the ancient Greeks to Kepler and
Newton.
As a side issue, the Greek who invented the Ptolomeian model of the universe
also wrote a treatise on conic sections!!!! This is covered in The
Sleepwalkers. I can't remember his name exactly - it may have been
Apollonarius of somewhere (Perga??).
Felix Tilley in Tucson, Arizona
[ADDENDUM: Stasinos Konstantopoulos <konstant@let.rug.nl> sent us this:
Apollonios of Pergamos did indeed write `Conic Sections' in the 3rd
century. But it is Ptolemeus of Alexandria who should be attributed
with the atavism of the Ptolemaikon (Ptolemaic? Ptolemeian?) system,
one century before that. PGN]
You mean:
* Forth Go
Dependability.org has been established by the IEEE CS Technical Committee on Fault Tolerance and IFIP Working Group 10.4 on Dependable Computing and Fault Tolerance to be a central source on the Web for information about dependable systems technology. We hope that you'll visit the site often. In addition, the IEEE CS Technical Committee has established a mailing list for distribution of its newsletter. The newsletter is sent out on an irregular schedule and lists upcoming events and other news of interest to the dependable systems community. If you would like to subscribe, an easy to use subscription form is available at http://www.dependability.org/ or you can send a message to mailto:majordomo@dependability.org with a body that says: subscribe fttc <your-e-mail-address> We welcome additional sponsors. If your organization is interested in sponsorship please contact mailto:weinstock@dependability.org
BKINSCNT.RVW 990625 "Internet Security with Windows NT", Mark Joseph Edwards, 1998, 1-882419-62-6, U$49.95 %A Mark Joseph Edwards mark@ntshop.net mark@ntsecurity.net %C 221 E. 29th St., Loveland, CO 80538 %D 1998 %G 1-882419-62-6 %I Duke Communications/29th Street Press %O U$49.95 800-621-1544 970-663-4700 fax: 970-667-2321 %O www.29thstreetpress.com ccarmel@29thstreetpress.com %P 515 + CD-ROM %T "Internet Security with Windows NT" The introduction states that the book is intended for those with little or no NT security knowledge, but I suspect that making this the sole resource for a new system manager would be a dangerous thing, since it provides the proverbial "little knowledge." Chapter one gives the user or administrator too much and, at the same time, not enough background on TCP/IP. There is a lot of trivia that does not relate to security, while there is no discussion of, for example, dynamic re-routing, which would be important in future examinations of IP spoofing. The grab bag of mostly intrusion related information in chapter two is not terribly helpful in preparing a defence. It is not clear to me why this part is entitled "TCP/IP Essentials." Part two outlines the basics of the Microsoft Windows security model. There is little presentation of a conceptual understanding or framework of the foundation chapter three, which instead lists a number of terms and programs. The "how to" of simple security operations is more comprehensible in chapter four. Part three talks about principles of network security. Chapter five does not deal with multiprotocol networks, but again lists an assortment of security concerns. A number of security threats are described in chapter six, but not in an organized fashion. (The virus information, obtained from the Semantec [sic] Anti-virus Research Center, is basically useless.) A number of aspects that should be addressed in a security policy are listed in chapter seven. Chapter eight discusses a number of client programs for NT, but without much security relevance. A number of attacks are tersely described in chapter nine. Part four looks at firewalls. Chapter ten does a reasonable job of explaining the different types of firewalls, although it also includes some unrelated material. Some considerations for evaluation are given in chapter eleven. Part five outlines the Microsoft Proxy Server. Chapter twelve runs through dialogue boxes in the Internet Information Server. The proxy server itself is described in chapter thirteen. Design issues are discussed in chapter fourteen. Implementation is talked about in chapter fifteen, although there are a number of areas not completely covered. Some client considerations are mentioned in chapter sixteen. Seventeen looks at troubleshooting and maintenance. The book can provide some useful material, although most of the utility comes from the appendices, listing quick suggestions and resource contacts, rather than the text itself. Much of the content is unfocussed and almost disorganized. Some topics included are not immediately relevant to security work, while other areas stop short of actually helping the user or administrator. copyright Robert M. Slade, 1999 BKINSCNT.RVW 990625 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
The Software Engineering Symposium '99
August 30-September 2, 1999
David L. Lawrence Convention Center
Pittsburgh, Pennsylvania
Theme: Improving the State of Software Engineering:
Principles, Practices, and Projections
The SEI Software Engineering Symposium provides a forum for discussing
currently applicable practices that software practitioners can use today.
The 1999 Conference on Software Technology and Engineering Practice (STEP
'99) will be held jointly with the SEI Symposium.
The STEP '99 conference is sponsored by the International Workshop on
Computer-Aided Software Engineering, Inc. (IWCASE), an international
association of users, researchers, and developers of software tools, methods,
and technology, and by the IEEE Computer Society.
The Preliminary Program, including Exposition Information, Registration
Information and forms, and Presenter Guidelines, is available on the
SEI Web site at
http://www.sei.cmu.edu/products/events/symp
Contact:
Symposium '99 Conference Coordinator
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Phone: 412 / 268-3007
FAX: 412 / 268-5556
E-mail: symposium@sei.cmu.edu
Please report problems with the web pages to the maintainer