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…
Cambridge Evening News of 24th May 1999 reports the following story: Swimmers taking a dip in Ely's newly-refurbished Paradise Pool were stranded when a high-tech locker-system broke down, leaving many without their clothes and belongings. Shivering swimmers were wrapped in silver foil blankets after the incident yesterday, when the electronic lockers shut down after a power failure. People were forced to wait for an hour-and-a-half until mechanics arrived at the scene. Youngsters who had come by themselves were given money to make a call home. Free drinks and food were also handed out. New swimmers were stopped from using the pool, which was closed for a short time while the problem was dealt with. The system which replaces the "key and coin" scheme usually found in public pools means that swimmers can access their locker with a tag fitted with an electronic microchip. The new and improved leisure pool, which recently underwent a UKP1.9 million renovation, has only been open for little more than a month. Apart from wondering whether this risk had ever been considered by either the designers or the people who procured this system, one is left wondering what the benefit was on this system over the traditional key and coin scheme, which appears to work perfectly well at many pools in the area and has no failure mode which leaves every locker locked. Paul Oldham, Milton, Cambridge, UK http://the-hug.org/paul/ [Perhaps the system was designed by the Davy Jones Locker Company. PGN]
For the past few days, the European lightning strikes charts at http://www-imk.physik.uni-karlsruhe.de/~gmueller/metbest.html are showing an empty map, with the inscription: "Due to technical reasons (lightning strike) no lightning charts are available". It doesn't say what part of the system was struck. Amos Shapir, nSOF Parallel Software, Ltd., Givat-Hashlosha 48800, Israel Tel: +972 3 9388551 Fax: +972 3 9388552 [Reminds me a little of lightning striking the launch pad at Wallops Island that accidentally launched a missile that had been prepared to be launched in order to test the effects of lightning. PGN]
For as many as a dozen times during an hour-and-a-quarter period during the midafternoon of 17 May 1999, repeated failures in a computer processor at the Philadelphia International Airport caused the radar-osaurus system to fail, losing partial data associated with each flight. The outage required air-traffic controllers to resort to the even older paper-slip backup system. As usual, the official spokesperson said ``There was no impact to safety.'' [Source: an article in USA Today, 23 May 1999, which noted that a power failure earlier in May had caused a 23-minute outage of radar scopes and radio contacts in the same place; PGN-ed]
While I was being transported by gurney to an operating room in February of 1998, a hospital delivery robot (essentially a large, automated supply cart) met the elevator when it arrived on the operating room floor. The robot knew that the elevator was occupied, and instructed us to clear the way so that it could enter. However, as the elevator had a gurney in it, there was not enough room to clear the way. The robot would not back away from the elevator to let us out, and we could not close the elevator doors to try to go to a different floor, because the doors were being blocked by the robot. Finally, a medical technician man-handled the robot out of the way so that the gurney could be pushed out of the elevator, leaving it to try to figure out its new orientation and try again. The Risk? Not programming the robot to allow for a situation that _must_ be common in its environment (gurneys in elevators). Lyle H. Gray
There's a site at Nottingham U., UK, where weather satellite images are received from a geostationary satellite (Meteosat), timestamped and prepared in several different formats. (ftp.ccc.nottingham.ac.uk) I download some images regularly off this site a few time a day. One morning last week, several images were missing; the next image available, was timestamped "FEB 28 2000, 2330" (though it seemed to be a current one). The next one was timestamped "FEB 28 2000, 2400". Oh well, back to the debuggers... (the rest of the images on that day had their correct timestamps). Amos Shapir, nSOF Parallel Software, Ltd.,Givat-Hashlosha 48800, Israel Tel: +972 3 9388551 Fax: +972 3 9388552 [Perhaps they were running a Y2K leap-year experiment. PGN]
My husband, a historian, downloaded a lot of official German government documents for a talk he is preparing on reunification. Many of the documents are in some Microsoft format or other. The most amusing one was stored in .doc format on their web pages in the proofreading version. That is, one can see that they have replaced all references to DDR with Ost (East), and so on. A quick look at the properties of the file is hilarious: "The style of this file is stilted, pompous, noun-laden, non-concise and in general not useful. Must be rewritten!" Interestingly enough, since no author is filled in in this field, Microsoft decides that I, as the license holder, am the author of the document. Other documents, for which no organisation is entered, believe that my organisation is responsible. The moral of the story: if you are using such products for net publication, make sure that there are no little surprises hiding in the text! Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin, FB, Informatik, 13353 Berlin, Germany http://www.tfh-berlin.de/~weberwu/
Our esteemed moderator is up to his eyeballs in biometric responses and has asked me to look them over and make a summary. Here goes: David Kinny [a] and C. Scott Ananian [b] mention possible issues with contact lenses and object to being required to remove them. According to Ananian, newer contacts have both color and texture on them (for cosmetic reasons, of course). IriScan claims to be able to deal with contact lenses but doesn't give precise details of how this works [1]. I would refer readers with these kinds of detailed technical questions to IriScan's Web pages. Ananian discusses future generation contact lenses, which presumably will take us further away from natural-looking eyes. I imagine that, in the limit (say, reflective lenses), contacts would have to be removed to make a positive authentication. Also writes Ananian: > Finally, although we are assured that iris images are deleted > immediately after processing, we all know the permanence of data on > today's digital hardware. If those images are swapped to disk or > ever written to a file during processing, a thief might acquire not > just one but *several* iris images with appropriate scrubwork over > the magnetic media. Combined with appropriate contact lens > technology... > --s > [note that this opens up an interesting avenue regarding the alleged > 'irrevocability' of one's biometric; here's something I can > (potentially) change at will, despite being an almost inseparable > part of the vison-corrected me] The vendors would likely claim that no contact lens will allow you to assume somebody else's indentity and they might be correct. However, if relatively opaque lenses become fashionably normal, the efficacy of iris scanners would be greatly reduced. Steve Feinstein [c] discusses the issue of 'cloning' someone in order to produce identical irises. Vendor studies of identical twins show that irises are truly personal — the exact iris patterns form as a function of development, although certain gross features (i.e., color) are genetic. William Leary [d] and Marcus Rowland [e] discuss scenarios whereby an ATM user is vulnerable during the 2-4 seconds they are being scanned. If you hear a noise behind you, you either look around (safety first, after all) and then restart the authentication later, or you resolutely stare forward, allowing an assailant a known time window where you are more vulnerable to a mugging. Given how current ATMs requires you to stare at the screen right now to follow their instructions, I don't think iris scanners exacerbate this problem. Paul Czyzewski [f] mentions a general privacy concern, i.e., that iris scanners could be installed everywhere we currently have security cameras and might be able to scan your "involuntarily". This could be a big step toward an Orwellian future. As it stands today, the technology only seems to work under controlled circumstances. Unless the government bans sunglasses, you should be relatively safe well into the future. Finally, Mark Hayman [g] brings up the scenario where current ATMs will, upon multiple bad PIN entries, "eat" your ATM card. Hopefully, iris-scanning ATMs will not employ an analogous strategy. Dan Wallach, Rice University [1] http://www.iriscan.com/basis.htm [a] dnk@OMIT.cs.mu.OZ.AU [b] cananian@lesser-magoo.lcs.mit.edu [c] saf@netcom.com [d] leary@emc.com [e] mrowland@ffutures.demon.co.uk [f] paulc@shell11.ba.best.com [g] mjh@castle.on.ca [Incidentally, Bruce Schneier makes some compelling arguments against biometrics, although he is obviously for strong authentication. See http://www.counterpane.com/crypto-gram-9808.html#biometrics PGN]
What's the Problem? My question at the top of this still stands. I know you can all answer that and some of you have but when compared to what we have What is the problem? The system we have now of easily duplicated cards with insecure PINs surely has more proven risks than those posed by biometrics. Sure sometime in the future security measures for these devices may well be compromised but by then hopefully those measures will have moved on. Sure some people will be "biometrically challenged" but are there not "ATM challenged" people out there now who are missing out? If we wait for the perfect system the waiting will never end. There are risks but it seems to me not as many as with our current system of cheques, credit cards, ATM cards and PINs. So again I ask, What is the problem? Dave Upton http://www.geocities.com/researchtriangle/1362
One of the risks of a purely biometric system is that biometrics are sometimes destroyed in accidents. This is often a major concern in hospital patient tracking systems, since most of those accidents lead directly to the patient being brought to the hospital, where the alternate lookup method needs to be invoked. Interestingly, this risk is obvious to the medical industry, because of the scenarios which they examine when designing their systems. I suspect that there will be alternate methods in place, if the banks deploying have realized that having only biometrics in their ATMs may violate the Americans with Disabilities act.
[From a recent letter clearly showing an Evil Plot to tar me with my Canadian citizenship forever:] Dear Dr Kabay: This is in reference to the note you sent regarding your address in Vermont. I can understand your dismay on seeing that Canada appears in your address when you live in Vermont. Our new ... system has a slight flaw in it at this time. Because you are a Canadian citizen our files show Canada as your country. This ... triggers the word Canada to appear in your address. I am assured this will be corrected shortly. ... For the record, this illustrates (1) a design flaw in which a hidden assumption comes to light with an exceptional case; (2) bad quality assurance; (3) the paucity in this database of Canadians who have moved to the USA. M. E. Kabay, PhD, CISSP / Director of Education, ICSA, Inc. <http://www.icsa.net>
Netscape has a security vulnerability related to Javascript in a <TITLE> of a bookmarked page, which is executed with the privileges of the user when the bookmark file is next processed. See <URL:http://linuxtoday.com/stories/6211.html> for more info.
I once worked on a software product for which an update was required to support the new Imperial Era name ("Heisei") after death the previous Emperor (a.k.a "Showa"). At the time I asked why the developers hadn't just put the Imperial names and dates into a ini file which could be edited after the death of the Emperor who was frankly getting on when the software was released. The reply was that it had been thought of but by building this feature into the product it could have caused offense by publicly anticipating the death of Emperor. Anyway, when he finally passed away, people continued to use the old Imperial era year for some time in conjunction with the new until it was supported by software and printed on forms etc. In the month after the new era name was announced there were enormous sales of rubber stamps with the characters for the new era name. And guess what, I bet in 99% of Japanese software applications the era name and start/end dates is still hard coded into the logic of the program as it is just a convenient format for display and never a basis for calculation which is done using the western date.
<craig@deforest.org> writes: > Roy Wright and Daniel Graifer have pointed out that MS Visual J++ > sometimes uses a single return carriage to end a line, breaking some > compilers. Actually, Daniel Graifer's original report concerned the Visual C/C++ suite, not J++. The problem reported was that the Microsoft Visual editor would display a single unix-style linefeed character <LF> as end-of-line, but that the integrated compiler was not treating the <LF> character as end-of-line. Thus, the compiled code did not match what the editor displayed, or what the programmer expected. This is not a failure to obey a standard; it is a failure of two related applications, the editor and the compiler, to treat the *same* input in a the *same* manner. It is all the more unfortunate because the two applications are "integrated", and should be consistent at least with each other. (They can't be consistent with the standard, because C++-style "//" comments in C code are nonstandard.) Jim Thompson <jim.thompson@pobox.com>
How quickly we forget! Twenty years ago it was PC/DOS vs mainframe and UNIX operating systems grumbling about this same issue. We still add the CRLF when converting from EBCDIC to ASCII as we pull data down from a mainframe to out PC network. Software companies DO create problems willfully for whatever purpose ... and sometimes they get double benefit for their efforts.
As a service to RISKS readers who have to deal with the problem of vulnerabilities in the MS Office software suite exploited by Macro Viruses, I direct you to... http://officeupdate.microsoft.com/downloadDetails/o2ksec.htm <quoted without permission> The download file, O2ksec.exe, contains the Microsoft Office 2000 Macro Security white paper. This white paper is a Word document that can be opened by either Word 97 or Word 2000. The Microsoft Office 2000 Macro Security white paper discusses how you can prevent the introduction of macro viruses into your computer using Office 2000. For example, Office 2000 introduces digital signatures to help users distinguish legitimate code from undesirable code, such as viruses. If you open an Office document and see a macro security warning with digital signature information, you can feel reasonably confident that the person (or corporation) who signed the macros wrote them. You can choose to trust all macros signed by this person by checking the Trust all macros from this source checkbox. From then on, when you open a document that contains macros signed by this trusted source Office enables the macros without showing a security warning for the document. If you use the Office 2000 digital signature features as advised in this white paper, you will not see annoying security warnings for any of the macro solutions that you write or use. You will only see a security warning when it is justified; that is, when you open a document with unexpected macros or viruses. Before you go rushing off to get this Word document, I would like to bring up the following points: 1/ the document comes as a self extracting and installing executable (165 KB executable to install a 177 KB document into your "My Documents" directory... how thoughtful!). We all know how no one could ever hack the MS Web site and replace the installation program with a Trojan to do additional tricks, The document does not contain any macros, fortunately. At least someone was thinking a little ahead. 2/ the improved protection only comes if you upgrade to the next greatest and latest software I don't know about you, but if I was a large corporation with a macro virus problem, I would resent having to do yet another upgrade just to get protection that should have been in the software in the first place. 3/ the process of signing and certification relies on trust. I trust that when you sign your macros that you cannot in any possible way loose control of your private key. You private key will be stored on your computer, which we all know that on a Windows based computer, is completely secure... well, let's not step off that bridge, shall we? Fortunately, the document warns "Certificate owners should guard their private keys carefully. Their reputations are on the line." or shall we say that "their reputations are on-line" With that warning, we all know that no one will overlook their security. 4/ "A Certificate Authority can issue you a digital certificate for code signing for a fee. " This basically means that we have to pay money to some anonymous "trusted" authority to get our digital certificates... this starts to go into the realm of privacy. We all know that this is completely safe and that the rumours of back doors built into the encryption systems for international versions of US software is completely false... (http://www.iptvreports.mcmail.com/ic2kreport.htm , a must read if you are into security and privacy issues) There's many more issues that can be delved into with MS's current approach to reduce (I cannot say "eliminate" because patching up a system that has a bad security model in the first place will never solve the problem) the problem with macro viruses. If this system is "used properly", I believe that it will help reduce some of the problems with macro viruses, but I don't believe that it will work for long. Some bright spark will find yet another hole to take advantage of and the system won't protect you. The other flaw in this system is that there is an assumption that users will be educated enough to understand what all this means, certificates, trust, signing...yada yada yada. Not to knock the average user, but this will be a very very large vulnerability. The real solution is to disable macros in MS Office software permanently with no way to turn it back on. You can actually do it in office 2000, as long as you are running Windows 2000 or NT4SP4 or greater. (Do I hear another upgrade cycle spinning in here?) Don't get me wrong, at the end of the day I am happy to use MS software in spite of the problems. I understand that the software is not secure. I keep my AV software updated. I learn about where a document comes from or I never enable the macros. If I keep the limitations in mind, I have no surprises or disappointments. In fact, the last successful virus attack I have ever suffered was back in '92 when I received an infected floppy disk from someone I trusted to know better. He got me twice! Whoops... Maybe I'm too paranoid..., yeah that's it. Paul Walker, senior consultant, james martin + co paul.walker AT jamesmartin.com
Here's a harmless one, but it still shows that things don't always go right; New Zealand's new national Museum, Te Papa, in Wellington, is a "modern" museum - highly interactive. I arrived as the doors opened, walked up to a touch-screen information kiosk, and it said "At least one device or service failed...... check the Event Log." Ah, I thought, this is the NT we all know so well! A touch on OK and it booted, so the load failure was something minor. Now, if it had been a plane, or a ship, or a high-speed elevator, or..... Gregor Ronald, Christchurch, New Zealand http://www.caverock.net.nz/~gregor Home: gregor@caverock.net.nz Work: ronaldg@chchpoly.ac.nz
BKWNTSAC.RVW 990409 "Microsoft Windows NT 4.0 Security, Audit, and Control", James G. Jumes et al, 1999, 1-57231-818-X, U$49.99/C$71.99/UK#45.99 %A James G. Jumes %A Neil F. Cooper %A Paula Chamoun %A Todd M. Feinman %C 1 Microsoft Way, Redmond, WA 98052-6399 %D 1999 %G 1-57231-818-X %I Microsoft Press %O U$49.99/C$71.99/UK#45.99 800-6777377 fax: 206-936-7329 %P 318 p. %S Technical Reference %T "Microsoft Windows NT 4.0 Security, Audit, and Control" The primary audience described in the introduction seems to be security professionals. However, system administrators, technology managers, and CIOs are mentioned as well. The attempt at breadth of coverage usually does not bode well in works like these. Chapter one discusses an information security model based upon the business (and other) objectives of the institution in question. While valid as far as it goes, and even possibly helpful when formulating security policy, this by no means provides a structure from which to view either security policy or procedures, let alone implement a complex set of controls. The widget company, beloved of management writers, is described in chapter two. For the purposes of assessing security in real world working environments, this particular widget company seems to be astoundingly simple and homogeneous. Chapter three starts out talking reasonably about security policy, starts to get flaky in risk assessment (I would definitely worry about a .45 chance of an earthquake), and tails off into trivia. Monitoring, in chapter four, looks first at system performance and diagnostics, and then gets into event logging without really going into the concepts. Many areas of physical security are left uncovered in chapter five. Chapter six discusses domains, trust relationships, and remote access permissions. Dialogue boxes for user accounts and groups are listed in chapter seven. There is some mention of the commonly "received wisdom" in regard to these topics, as there is in chapter eight regarding account policies, but nothing very significant. File system, share, and other resource control is covered in chapter nine. Chapter ten is a bit of a grab bag without much focus. The registry is reviewed in chapter eleven. Chapter twelve looks briefly at power supplies and backups. Although it talks about auditing, chapter thirteen is more of a checklist of security features to think about. Appendix A is a bit better in this regard: it lists recommended settings across a number of functions for six different types of systems. There is some discussion of options as the various functions are addressed, so, in a sense, this is a start towards full coverage of NT security. It has a long way to go, though. In addition, the deliberation comes at the cost of a loss of some detail in terms of security implementation. copyright Robert M. Slade, 1999 BKWNTSAC.RVW 990409 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer