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…
> ANNAPOLIS, Md. (AP) — The computer has sunk the ancient art of celestial
> navigation at the Naval Academy. In the new academic year, midshipmen
> will no longer have to learn the often tedious task of using a
> wedge-shaped sextant to look at the stars and plot a ship's course.
> Instead, the academy is adding a few extra lessons on how to navigate by
> computer. Naval officials said using a sextant, which is accurate to a
> three-mile radius, is obsolete. A satellite-linked computer can pinpoint
> a ship within 60 feet. [...]
(http://www.sjmercury.com/business/tech/docs/058935.htm)
George Mannes, Two Rector Street, 14th Floor, New York, NY 10006
212-271-8208 george@thestreet.com http://www.thestreet.com
[Also noted by George Dinwiddie <gdinwiddie@min.net>,
dc@panix.com (David W. Crawford) (who remarked on the timeliness of
Peter Ladkin's summary of GPS vs sextant!), and
psm@air16.larc.nasa.gov (Paul S. Miner).]
[I suppose SEXtants have been eliminated in response to
the Navy's efforts to avoid repetitions of Tailhook. Or
perhaps references to these devices were being censored
by filtering programs and removed from training manuals. PGN]
I can't remember the acronyms, but for many years now, US military acquisition has been adjusting to using standard commercial products in places where military spec was not warranted. I'd like to believe that it's due to commercial products being ISO9001 compliant and highly reliable, thus meeting many needs. (ex: ASUS motherboard monitor fan rotation, power supply voltages and all). But I agree that off the shelf parts just don't have the ACCOUNTABILITY and MAINTAINABILITY that's required by military contracts, so I doubt any integrator/contractor will risk using too many leading edge parts. I'd like to believe there are some checks-and-balances to the procurement system and at some point, someone's head risks being on the chopping block, so untrustworthy parts get blocked (lest they lose the contract and all future business!). As to software, I'm unsure off the shelf is allowed since it does not meet security levels; needs to support all the proprietary military interfaces & protocols and such. On the bright side, SUN makes militarized systems (a friend noted Suns in tanks)... Jeffrey Jonas jeffj@panix(dot)com
I work in the weapons safety area for the U.S. Navy. One of my great fears is having a weapon system come in running under Windows (any version). So far, I haven't seen that. Not that there aren't systems running under Windows, but (so far) not the systems directly pointing/firing weapons. We did have one system proposed to run under Windows (3.0 at the time, I think) that would have popped up a dialog box at the Tactical Action Officer's station saying "Fire Now!", but it never made it beyond engineering development. Actually, I figure the TAO would have looked down for advice and found "Memory Error at Krnl.exe!" but that is another issue. Software safety is one of our big concerns. We know how to analyze gears, springs and levers. 20 programs on 5 different kinds of processors under 10 different languages are a harder problem. The one saving grace with Windows is that we can ask the program manager how many times he has booted his computer today. Luckily, few of them have Macs. Off the shelf PCs are going into service. They are spinning up torpedos and tracking ships and correlating radar tracks. Acquisition reform can put Packard Bell in control of lots of things. But not yet Navy weapons.
Chiaki Ishikawa was wondering, if ... > I am not quite sure what the phrase in the Educom headline "off the shelf > PC", but I certainly wish that the Navy is not trusting weapon control or > cruise control to Windows 95. >From the "Secure Windows NT Installation and Configuration Guide", produced by the Naval Information Systems Security Office, PMW 161: "The Microsoft Windows NT Server 4.0 is the standard fleet NOS." "In response to fleet demand, the Navy has issued formal record message traffic (R 300944Z MAR 97, INFORMATION TECHNOLOGY FOR THE 21ST CENTURY) directing the migration to Microsoft's Windows NT 4.0 Server and Workstation OS no later than December 1999." Regards, Marc P.S.: I don't remember what the original location was. You may find my copy at ftp://door.sniff.ct-net.de/pub/security/paper/pubnavynt.zip Marc Binderberger, 97076 Wuerzburg, Germany marc@sniff.ct-net.de
> The U.S. Navy, facing pressure from Congress to cut spending, is > maintaining its cutting edge by replacing expensive custom-built systems > with off-the-shelf products. This is less alarming than it sounds. The fact is that the fraction of all semiconductors purchased by the US military has gone from over 50% to a fraction of 1%, so the military can no longer expect its market clout to cause vendors to design special hardware for it. This has resulted in a migration from highly custom boards to ordinary industrial-strength single-board computers with commodity CPUs, running commercial real-time operating systems where appropriate. Nope, no Windows95 controlling missile launch. You should be more alarmed at the prospect of all the military systems in the field for which spare parts simply cannot be purchased — how many years until no 5 volt chips are produced? Will reliance on computerized control result in the early demise of many weapons systems, at great cost (and risk) to the taxpayer? -- greg
I just can't wait for the day when one of the class of '00 finds herself in mid-Pacific with the blue-screen-o-death on the Wintel98 box that was supposed to display the GPS output :-) Later, someone quoted Henry Spencer that: : Having a supposedly-reliable navigation aid that is lying to you is : much worse than having to get by without it. Which is related to why I miss the old VaxVMS debugger's habit of admitting that it didn't really know what the current value of a variable was. The "modern" spiffy IDE's I occasionally have to use will blandly lie through their little cyber-teeth and claim preposterous results at equivalent times. Of course, the only real threat to my life from such shenanigans has to do with blood-pressure :-) Mike albaugh@agames.com
I heard on NPR yet another manifestation of the Galaxy IV malfunction: the inability of some pharmacies to verify insurance coverage during prescription refill requests. Elderly persons were told to pay cash or use a credit card to cover the full retail price, not just a co-payment. When some people could not do so, some pharmacies apparently dispensed one or two day supplies (probably suspending existing rules...quite in contrast to that Chicago hospital emergency room....) Ron Adams, Principal - Logistics, The SABRE Group, P.O. Box 619615 M/S 4311, DFW Airport, TX 75261 http://www.sabre.com/its rba2@acm.org
I think the recent satellite failure vs. paging failures merits further study and, perhaps, even regulatory action. Consider this scenario. 1) You buy paging service from a company with a local presence, i.e., they have a local office, people working here, etc. 2) You call a local phone number to enter a page. 3) A local radio transmits the signal to your pager. Those unfamiliar with the process would tend to assume that the process of sending a page works locally, but in fact, it gets transmitted through one or more satellite links and through facilities in multiple ground stations. (At least this is the way many paging systems work.) Hospitals, doctors, and other emergency personnel (and those who depend on them) are dependent on paging systems. Many businesses are dependent on paging systems. Many of these customers could be well served if there was a standalone "local" part of the system that works without communicating with the home office. Should these customers have been more informed of the "weak" links in the paging system? Should the paging companies have provided an autonomous local system or a local backup network? I would say it's obvious that such a system could be provided, and even a ground-based backup for the satellite link could be provided, but it's a matter of cost. i.e. the system could be more robust, but it will cost money. I think that the road ahead is paved with lawyers for the paging companies. If your business or some service you need depends on pagers, you had better consider what kind of backups you have. You might also want to have a talk with your paging company to see what kind of backups and failure points they have. Perhaps if enough customers press them on the issue, they'll work on their backups. Of course, if you asked them last week about backup systems, they would have probably assured you that they have redundancy and backup systems. Actually this points out another problem. How do you really find out how good the contingency plans are for that service you buy from a multi-billion dollar multinational company? How do you know that the new CFO for the company won't farm out some vital component of the system to some location in a foreign company halfway around the world with shaky telecommunications links, potential political unrest, or some area affected by natural disasters? Perhaps the only safe bet is to have a penalty clause for outages that is so severe that you make more money if the system is down than if it's up. You should also consider your side of the paging (or other telecommunications) system. Did you consolidate something in some remote location to save money? What happens with the phone lines or that site breaks down? However, as one comedian pointed out last night on cable, perhaps there is a bright side and drug dealing has decreased the past day or two. Mickey McInnis - mcinnis@austin.ibm.com
Actually, I believe that the satellite is owned by some division of General Electric, but is *operated* by PanAmSat. (My pager, BTW, was one of those affected.) Obvious Risk: I wonder if the embedded systems on the communications satellites that we all depend on now are Y2K-compliant? Dave Weingart, AccuStaff Inc. dweingart@chi.com 1-516-682-1470 [As you recall, there is apparently still a problem that some receivers will fail at midnight between 21 and 22 August 1999, resetting to 6 Aug 1980. See RISKS-18.24.]
I think some of the confusion I've seen in recent comments about GPS jamming comes from a failure to distinguish pure jamming (making GPS unavailable) from GPS spoofing (transmitting signals that cause a GPS receiver to report an erroneous position). Spoofing, as far as I understand it, is in principle a malicious form of differential GPS (in which a ground-based transmitter of fixed, very-well-known position emits signals based on the difference between its known position and its GPS-derived position. I've seen such transmitters referred to as "pseudolites" because they apparently appear to GPS receivers as members of the GPS satellite constellation.) Someone who knows this stuff cold might give a much better explanation. In the meantime, the US Naval Academy has announced that middies will no longer have to learn to navigate by sextant, evidencing a touching faith in the invulnerability of GPS transmitters and receivers under combat and disaster conditions... Paul Wallich <pw@panix.com>
On Tuesday, May 19, at approximately 11:50 pm, the UC Berkeley campus lost power for a few hours. Apparently what happened is that there were some bad insulators in the main campus substation which needed to be replaced urgently. The campus attempted to switch over to the backup power source (a generator facility which can provide roughly 80% of the power) but that failed, causing a blackout until the generator could be repaired. In the CS department we also learned something of how things fail. Being a rather large department, cardkeys are used to control access to many floors and rooms. Some cardkey locks have their own power supply, others don't. Those with power are unable to reach the controlling computer, and default to "unlock with any cardkey", while those without power default to locked. It is interesting that the machine rooms, wiring closets, etc, all had power and therefore were all unlocked, while many of the stairway doors (to get to the upper floors) were locked. This suggests that we need to put the controlling computer on a UPS and check the backup power supplies for all locks. Another interesting failure damaged our file servers. Our two big Auspex servers have short term (<30 minute) UPS power supplies, which actually worked this time. (Previously, we have had the UPSs fail). However, there were not enough plugs in the UPSs, and the consoles for the machines were not plugged in to the UPS power supplies. The admins failed to find a 9<->25 pin serial adapter in time to hook up a notebook before the UPSs ran out of power. Fortunately we have very good system administrators, and with the exception of a blown power supply which powers some of the disks, service was restored by the next day.
(written May 11, but our news server refused moderated groups until today...) The general election in Germany is not until September, but a fight is going on in Berlin about the new election software. It was purchased from a town in the west of Germany, Hamm. The software was developed by programmers at city hall. It seems that the software is cool and runs under Windows 95 (did I hear someone shuddering out there?), but that there are problems interfacing to the "ancient" 16-bit software currently in use in Berlin for tallying the results from the boroughs. The "Tagespiegel" ran a large headline about the possibility of no election data in Berlin because of the 16-bit/32-bit incompatibility. A few days later we had the angry replies from Hamm, if Berlin would just get their act together and upgrade their Windows 3.1 machines everything would be just fine. The ward leaders have now replied that the software is probably okay, they just have a lot of training to do. I see more than Windows problems here, Hamm has 190,000 inhabitants, Berlin has about 3.4 million. Could be a slight scale-up problem here, stay tuned... Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin, FB Informatik, Luxemburger Str. 10, 13353 Berlin, Germany http://www.tfh-berlin.de/~weberwu/
>From the article by Michael Stutz, "Security Bugaboo in MS Outlook?" in Wired News, posted by James Glave: The bug arises when a user creates an encrypted message and then tries to cancel it — the message is not cancelled, but is sent, sans encryption. Isn't there another risk here, namely, that a message thought to be canceled was not? The consequences of that could be as bad as third party interception. For example, suppose an employee is angry at their boss and composes an inflammatory message with a notice of resignation. Then, after blowing off some steam, decides to cancel the message. Dorothy Denning - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Date: Tue, 12 May 1998 08:52:03 -0700 >From: James Glave <james@wired.com> >Subject: Encrypting e-mail — or not > >The risk here is that an e-mail that was intended to be sent encrypted is >instead sent as cleartext, thanks to a completely avoidable bug in the >interface. Obviously the interface testers dropped the ball here in a big >way. > >http://www.wired.com/news/news/technology/story/12249.html > >Security Bugaboo in MS Outlook? >by Michael Stutz, 12 May 1998 > >The user interface of Microsoft's Outlook 98 e-mail application is the cause >of a new security-related bug, where users could be fooled into thinking >that an unencrypted communication is actually encrypted — thus sending >potentially sensitive information in plaintext over the wires. "The problem >manifests itself two ways," said Scott Gode, Microsoft product manager for >Outlook. "One is that the message is not digitally signed, and the second is >that the message is not encrypted." VeriSign Inc. makes the digital >certificates that are used with the S/MIME encryption in Outlook 98; these >certificates are used to encrypt and create digital signatures for messages >sent with the program. The bug arises when a user creates an encrypted >message and then tries to cancel it — the message is not cancelled, but is >sent, sans encryption. When a recipient replies to the message, thinking >that it was an encrypted communication, the reply e-mail is also sent with no >encryption. "All further messages sent in reply from either party are sent >as unencrypted plaintext messages. And there's no notification to anybody >along the way at any time," said Russ Cooper, consultant and moderator of >the NT Bugtraq and NT Security mailing lists. Cooper discovered the bug >while testing the S/MIME crypto features of Outlook 98. The flaw is not in >VeriSign's crypto implementation, rather it's in Outlook 98's user >interface. > >"This is mainly a user interface issue," said Gode. "The architecture and >integrity of what we're doing is not flawed — it's just the way that the >software responds to the dialog box." "It looks to me that this is very >specific to this implementation," said Glenn Langford, group manager for >desktop applications at security and crypto software company Entrust >Technologies. "This kind of thing wouldn't happen in our scenario, because >in an Entrust environment, what we're doing is not just issuing certificates >-- we're doing the certificates, the key management, toolkits, and the e-mail >plug-in implementation all at the same time," he said. The weakness of the >VeriSign situation, he said, is that it's up to the implementor of the e-mail >package — in this case, Microsoft — to do the security properly, because >there's no toolkit running on the client platform. So if there's a bug >involving the e-mail package, even though the VeriSign application functions >perfectly, there's a security hole. Bruce Schneier, crypto expert and >president of Counterpane Systems, is fascinated by the bug. "It's yet >another example of cryptography broken by bad user design," he said. "This >works counter-intuitively." "They've gotta fix it — they can't wait for >the next version, in my opinion," Cooper said. Microsoft, however, is >unable to reproduce the bug. "We've been able to reproduce the problem of >[a message] not being digitally signed," Gode said, "but have not been able >to reproduce the problem of [a message] not being encrypted, which is >obviously the more potentially damaging of the two." Gode said that the >company had been aware of the bug from other sources since late April, about >a month after Outlook 98 was released. He said that the company has >contacted Cooper — who made his description of the bug public on Friday -- >with the hope of getting more data so that they could reproduce it. As to >what causes the second part of the bug, where the message is sent >unencrypted, Gode said that any number of possibilities could be involved, >including how Cooper configured his machine — or an error on Microsoft's >part. "It could be a legitimate thing that we messed up on," he said. "I'm >not ruling that out, but because we can't reproduce it and because we're not >hearing this from other people, it's hard to say at this point." How could >such a simple bug have slipped through development testing? "People don't >notice, because code is complicated," said Schneier. "This is the big >problem with the Net. Look at Netscape Navigator: > >It comes out, bugs are found, bugs are fixed; more bugs are found, more bugs >are fixed — you'd think it gets better, but then a newer version of >Navigator is released, with 80 percent more source code, more lines of >code," he said. "There's absolutely no substitute for public scrutiny," >Schneier said. "But you only get scrutiny to the level of what's public." >And so if any portion of the code is unavailable for scrutiny, the security >risk is increased. "Not just the security portion of a code can compromise >security," Schneier said. "Just because the digital signature and key >management [portions of the source code] are correct, doesn't mean that you >can't write a user interface that breaks the security." Not everyone thinks >this bug is so catastrophic. "It would be a bug of a different magnitude if >the user who sent the original message had every reason to believe that it >were sent encrypted," said Ted Julian, an analyst at Forrester Research. As >for when the bug will be fixed, Microsoft said it will play it by ear. "If >[the problem] is severe and if it's something that it turns out we're able >to reproduce — and we think it could cause problems to other users — that >might necessitate some sort of little patch that we could make available on >the Web," said Gode. "If it remains just the digital signing problem, that >would be something we'll probably just have people live with for now until >an interim release — if there is one — or until the next version comes >out." Check on other Web coverage of this story with NewsBot > >James Glave, Senior Technology Writer >Wired News http://www.wired.com (415) 276-8430 >
Like Ken McGlothlen (see RISKS 19.74), I also received an "Announcing ZDNet Mail" notice. It told me an account was already setup for me, and that all I needed to do was visit their WEB site and enter my old ZDNet username and password, which ZDNet unfortunately included (problem #1) as plain text in their notice directly to me. Problem #2 is that prior to this notice, I tried to unsubscribe from ZDNet, but even though I only recall *one* point-of-subscription, I've had to visit 2 separate points-of-unsubscription (ZDNet "Software Express" and ZDNet "ANCHORDESK") and am nowing trying to deal with a 3rd point-of-unsubscription (ZDNet "Update"). In all fairness to ZDNet, they're not the only ones with *one* point-of-subscription that results in (unbeknownst to the subscriber) *multiple* points-of-unsubscription. Problem #3 (stupid me) is that while preparing this report, I visited the ZDNet Mail Web site, went out of my way NOT to enter the "Member" zone using my old username and password, and instead entered the "non-Member" zone to see want type of information they would want from me. Arrggg, the non-Member page still recognized me and instantly announced "xxxxx, thank you for joining ZDNet .... Access your new ZDNet Mail account ...." Zero warning going in, and no final OK/Cancel option. Problem #4, there is no apparent information on how to unsubscribe from problem #3. Problem #5, unlike e-mail based subs/unsubs, I have few transaction records from all of the unfortunate web-based subs/unsubs and encounters. ZDNet is like quick-sand - every move I make to get out, I sink farther in. Thomas Gilg <tomg@cv.hp.com>
Please report problems with the web pages to the maintainer