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…
http://news.com.com/2100-1001-826124.html Andrew Colley, CNET News.com, 30 Jan 2002 SYDNEY, Australia--Amec Engineering, which designed the Beverly uranium processing plant in Western Australia, has blamed buggy software for a radioactive spill that occurred at the site last December, confirming early suspicions that computers played a role in the accident. "After a detailed assessment of the incident it is now clear that the problem was caused by a computer programming error that has since been corrected," said Stephen Middleton, spokesman for the plant's operator, Heathgate Resources. According to Amec's report, the glitch cut power to the plant's fluid-distribution control system during a routine service exercise. At the time, the mechanism should have shut down pumps moving fluid into the plant. "Before they could be shut down manually, pressure built up in the pipelines leading into the plant and one ruptured," Middleton said. According to Middleton, Amec has re-examined the entire system, retested the plant's pipes and corrected the "computer logic error." He refused to name the software technology responsible for the error. [It doesn't sound to me like a software error that pipelines had no pressure gauges or relief valves; but it's always hard to say how correct media reports are. Does Australia have freedom of information laws or other means of access to see Amec's report? Adam]
Labor Department finds error in unemployment compensation tax forms An error has been found on tax forms sent to Connecticut residents who collected unemployment compensation last year, the state Department of Labor announced Friday. About 5,000 forms — less than 3 percent of the 176,000 tax forms sent — contain information pertinent to individuals other than the named unemployment compensation recipient. [...] [Source unspecified, 25 Jan 2002] The article doesn't go into much more detail, but it sounds like a classic mix and merge problem, with the headers for the mailing labels being off by one (or more...) from the other data fields. Nothing on the CT Web site about this yet.
The Microsoft e-mail newsletter MSDN Flash, Volume 6, Number 2, January 22, 2002, contains advertising text including the text (Copied almost literally; note: I added one extra space after the word "over" to circumvent the Microsoft filters.) > Plus, VSLive! San Francisco provides over 180 hours of > content in three technical conferences: The standard Microsoft "Adult Content Filter" includes the rule that a message body containing the text "over 18" is Adult Content. [SPACE added by PGN in hopes of avoiding filtering?] As result, the MSDN Flash was rejected by Outlook, as being unwanted adult content. I Wonder how many Microsoft customers have read this number of the Flash. Geert Jan Dekker, National Aerospace Laboratory (NLR), P.O. Box 153,8300 AD Emmeloord The Netherlands +31 527 248435
An oldie but a goodie. AP reports that HP's annual report filed Tuesday mentions the names "David and Lucite Packard Foundation", "Edwin van Pronghorns", "Eleanor Hewlett Limon", and "Mary Hewlett Gaffe", instead of "Lucile", "Bronkhorst", "Gimon", and "Jaffe", respectively. http://www.siliconvalley.com/docs/news/tech/085146.htm
In a story that is probably unique, R.D. Bridges recovered his sister's stolen iMac using Netopia's Timbuktu Pro, a program that allows computers to be remotely controlled and is widely used by computer-help technicians. Bridges, who lives in Clear Lake, a suburb of Houston, had installed the software to help his sister, who lives across town, when she ran into problems. [...] http://www.wired.com/news/mac/0,2125,50025,00.html Tracing a Stolen iMac Using Timbuktu http://www.macscripter.net/unscripted.html
Here is a true story that illustrates several familiar RISKS. My sister-in-law Karen Rakow was quite surprised recently to discover that according to a web site called slatkinfraud.com, she and her husband Robert had pocketed more than $5 million from a Ponzi scheme in which they were involved. All of this was false — including the part about having a husband named Robert. The accusation on the web site hyperlinked to Karen's business and to her list of clients, and it even named one of her clients, so this was a big problem for her. A little research revealed what had probably happened: a person named Karen Rakow was named in some court papers, and an Internet search for "Karen Rakow" had turned up a link to a person with that name, who the slatkinfraud.com people proceeded to accuse. [RISK #1: Accusing person of a crime based only on similarity of their name to that of a real suspect.] [RISK #2: Trusting Internet searches to give semantically correct (and not merely textually similar) results.] So Karen asked the slatkinfraud.com people to remove the references to her, her business, and her clients from their web site. They replied by saying they had done so, but in fact they had only removed some of the references. Karen complained again, and they replied that "Our assistant webmaster has made another search and believes that all references to you and your company have now been removed from the site. But we have 60 megabytes of material at slatkinfraud.com, so manual searches are not the most efficient way of doing this." [RISK #3: Using technology to build artifacts that are too large for you to manage.] [RISK #4: Making unverified modifications that you cannot easily undo.] Eventually all of the offending references were found and removed (we think). Here is the really interesting part: the webmaster of slatkinfraud.com is a well-known computer scientist who definitely should have known better. [RISK #5: Thinking that RISKS only apply to newbies.]
The BBC has this story about Kodak giving in to customer's demands that they honour a wesite promotion for cameras mistakenly listed for [much] less than they should have been. Seems their automatic e-mail response constituted an acceptance of the sale. As a Web developer, I'll certainly keep this in mind in the future. http://news.bbc.co.uk/hi/english/sci/tech/newsid_1795000/1795624.stm
A report via APP that appeared on Australian IT (http://australianit.news.com.au/articles/0,7204,3602608%5E15306%5E%5Enbv%5E,00.html) states that the Australian Bureau of statistics has been unable to provide data on people leaving or arriving in Australia (information collected on arrival/departure cards) for the last 18 months because of "technical difficulties" in upgrading from a manual to an automated system. This data is particularly useful to the tourism industry. Apparently the "technical" difficulties are related to the outsourcing of the computer system. Hmmm...sounds like there are more than "technical" difficulties, but unfortunately the outsourced company is not named.
Yet another Microsoft Outlook exploit is on the loose... and this time the arrogance of the recommended solution is breathtaking. The problem is the built-in support for UUENCODED text within the body of a message. Prudent programmers will use a starting pattern such as "\n\nbegin ([[:octal:]]+) ([^\n]+)\n" and subsequently verify that each line has the expected format. Even checking only the first few lines (e.g., verifying that the first character correctly encodes the length of the rest of the line) essentially eliminates any chance of a false hit. Sadly, it will surprise few people that Microsoft cuts straight to the heart of the matter. If your line starts with "begin " (possibly with two spaces), Outlook/Outlook Express WILL interpret the rest of the message as a UUENCODED attachment. It doesn't need a preceding blank line, nor a following octal number. It doesn't need subsequent lines that actually look like UUENCODED data. There are some reports on slashdot that later versions of O/OE have discarded the "view source" command, with the effect that the rest of the message is permanently lost to the user. The use of this bug as a DOS attack on mailing lists that use a 'digest' approach is left as an exercise for the reader. Naturally, it hasn't taken long for the malware writers to jump on the bandwagon. All you need to do to get around the "strip executable attachment" killjoys is to put the malware right in the body of the message! Just start a line with "begin 666 www.myparty.yahoo.com" and you're off and running! Microsoft's official position, at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q265230 , is stunning in it's <s>feeble-mindedness</s> simplicity. We, and by "we" I mean every person on the planet who may ever send a message to an O/OE <s>victim</s> user, or have a message forwarded to such users, are advised (with editorial comments) to: * not start messages with the word "begin" (actually, it's *any* line starting with the word "begin". And that's effectively a ban on the word "begin" for anyone using a mail agent with transparent line wrapping, e.g., the web mail portals that some ISPs are pushing.) * capitalize the word "begin," even when used within a sentence. E.g., "We will Begin the new project when Bob returns from his vacation. * Use a different word such as "start" or "commence." E.g., all training materials for new Visual Basic programmers shall henceforce refer to "start/end" loops instead of "begin/end" loops. Microsoft's justification for suggesting a significant change to the English language instead of fixing their bug is given as: "In a SMTP e-mail message, a file attachment that is encoded in UUencode format is defined when the word "begin" is followed by two spaces and then some data,..." Needless to say there is no citation given for this "fact." That's probably related to the fact that UUENCODE was defined by UUCP, not SMTP, and that every encoder/decoder I have seen requires a leading blank line and a octal file permissions code. But the damage is done - since malware is exploiting this bug we now get to put into place filters that don't just strip executable attachments or properly formatted UUENCODED blocks, we also have to strip *improperly* formatted UUENCODED blocks! Bear Giles
Effect: Using database functions in Excel with autofilter on and hidden columns. Deleting rows will scramble the rows of the database. How to see it: in Excel (all versions I tried fail) make a Database area, that is, make a table with few rows and few columns, say 5 rows, 5 columns for example. Fill it with whatever you want. Maybe fill the row 1 with "c1", "c2", "c3", ... as those will be the names of the fields of the Database. Also, fill 1 column only with 0 and 1. Select the table (with 1 more empty row) and define the name for the area "Database". Chose the option AUTOFILTER ON, hide a column (not the one with 0 and 1), using the automatic filter on the column with 0 and 1 ask for only the rows with 0 in that column. Delete a row in the middle. unhide the column that was hidden, remove the filtering and see that Excel did not delete the row in that column but did delete the row in the other columns. Therefore the rows after the deleted one are all reporting misleading information. I think this is serious. After some use the Database will be more or less scrambled. Note that this would not happen if the autofilter was off regardless the number of hidden columns Any advice? Was this bug reported before? Alberto <abit@maths.anu.edu.au>
About 40 years ago, Ed Lorenz re-ran a weather forecasting model using rounded figures and discovered Chaos Theory. Maybe Microsoft is hoping that Excel's (mis)behaviour will lead to an equally important discovery :-).
According to the BBC (http://news.bbc.co.uk/hi/english/uk_politics/newsid_1802000/1802956.stm), "Voters in Liverpool and Sheffield will be able to cast their ballot by sending a mobile phone text message in May's local elections." These elections will significantly empower real people as members of local councils. Some more choice quotes from the article: "The pilots will be crucial in building public confidence and testing technical robustness to ensure that the integrity of the poll is maintained." "In some wards in Liverpool and Sheffield voters will be able to cast their ballot by digital television as well as via their mobile phones." "In Swindon there will be a touch-tone phone voting system, while Gateshead, North Tyneside, Stevenage and Chorley will pilot elections where people can only cast their ballot by post." "The text messaging system will work by voters being given PIN numbers to use if they want to vote by text message." "Opponents of online voting argue it is too easily exploited by electoral fraudsters..." Endless potential RISKs discussed here previously may now be realised. Doubtless some new ones will come to light, too.
Officials in Florida's Miami-Dade County have approved a $24.5 million contract to replace the county's punch-card voting system with touchscreen equipment, in time for Nov 2002. The touchscreen machines make it impossible to vote for more than one candidate in each race, known as overvoting, and alert voters if they fail to select any candidate, or undervote. Two other counties that were at the heart of the controversy -- Palm Beach and Broward — also plan to use touchscreens. 30 Jan 2002 [source not specified] [And as we have noted here before, today's touchscreen systems provide essentially ZERO hard evidence that your vote is counted as cast, and not for someone else or for no one. With just a little insider fraud, what a remarkable opportunity for rigging elections! PGN]
This is really nothing new. The article Epstein linked to mentions the Microsoft "astroturf" campaign, but as early as the spring of 1998 a high-profile case of good-natured ballot stuffing was widely remarked upon: the People Magazine poll for Most Beautiful People. A campaign to write-in Howard Stern regular "Hank, the Angry Drunken Dwarf" had already boosted him to second place, until on 28 April 1998 Slashdot picked up the story and Hank shot to number one (by a margin of over 10 times his nearest rival). People played along to an extent, adding Hank as an official ballot choice, but complaining about vote-stuffing. That same spring I was witness to an episode more like Microsoft's effort. The game company I worked for, Kesmai, had a game up for an online award based on a reader survey. The director of the department that included testing (the section I was in) instructed us to "vote early and often" until Kesmai's offering topped the list. (Kesmai no longer exists, having been bought by Electronic Arts in early 2000 and folded into the struggling EA.com online game venture.) All our effort was ultimately for naught, as by the next morning someone *else* had apparently been hard at work stuffing the votes. We pondered writing a Perl script but never did so. The real risk in both of these cases is the assumption that a) one's own poll is too small or specialized to attract a ballot-stuffing campaign or b) that you can effectively detect rogue voters in an anonymous system.
This is yet another in the "people treating Caller ID when the information was never meant to be trusted" series. As stated in past issues, anyone with a PBX system can program their system to deliver any given name and phone number as the CNID (Calling Number ID) information for any outgoing call from that system. In most businesses, this is used so that outgoing calls appear to be from that company's "main" number for incoming calls rather than from the actual phone line used to place the call. A new trick many telemarketers are using to get around the new answering machines and phone company features that automatically shunt "Private" and "Out of Area" calls to telemarketer blocking features is to select a name at random out of the phone book and use that name and phone number for their outgoing CNID information. I know I regularly receive telemarketing calls that show up on my CID box as being from some person purported to be in the 619 area code... This is no different from the way many spammers have recently taken to grabbing valid e-mail addresses and using those as "From" addresses for their missives. (I can't tell you the number of bounced e-mail reports I get for an e-mail address I stopped using some two or three years ago now, all with typical SPAM subject lines and originating from an open SMTP relay somewhere in the South Pacific.) Alas, I don't believe misrepresentation of CNID information is any type of crime, as, as stated before, it was never meant to be secure or any type of authenticated representation of who is actually calling... RISKS: Believing that either CNID information or the "From" line on e-mail actually represent the true originator of the call or message in question...
As a result of the recent discussion about security on the Kaiser Web site, my friend there has gone through the Web site registration process. In a previous private e-mail, she noted that the Medical Record Number (MRN) is not enough information to allow doing more than a few relatively innocuous things like checking appointment times. Here is her most recent message, outlining the results of the Web registration process: > I received a letter in the mail including an activation code: > > (Dear... > Thanks...) > The PIN you've chosen will always let you into the site. The next time you > visit our site, we'll also ask you for your one-time activation code. > > (Instructions)... It will start the more confidential features of the Web > Site, like answers to your personal health questions. > > We've sent you this Code by US Mail to make sure that no one is pretending > to be you online. > > (If you have problems......) > > They never asked me for an address online so if the MRN and the name didn't > match or the address was wrong, this wouldn't have made it to me. Sounds like Kaiser has actually done a pretty good job. Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/
BKCISPET.RVW 20011122 "CISSP Examination Textbooks", S. Rao Vallabhaneni, 2000, , U$213.00 %A S. Rao Vallabhaneni srvbooks@aol.com %C P.O. Box 681354, Schaumburg, IL 60168-1354 %D 2000 %I SRV Professional Publications %O U$99.00 per volume 847-330-0126 www.srvbooks.com %P ~500 p. per volume %T "CISSP Examination Textbooks" (vol 1 Theory, vol 2 Practice) I should probably declare a bias. I am newly indoctrinated as a CISSP (Certified Information Systems Security Professional) instructor, so, presumably, anyone who decides to study for the exam out of a book, and not take the course, reduces my chances of getting assigned to teach a course by approximately 0.016 percent. Having said that, then: These books will not help you study for or write the CISSP exam. These books may, in fact, make your study more difficult, and your chances of passing the exam more remote. At the very best, the time (and significant amount of money) you spend studying these books will be wasted, when you could have been reviewing other, more useful material. If I went back through the files I might be able to find one, but, off the top of my head, I cannot recall a technical book with a poorer structure, organization, or grasp of the titular material. Many authors fail to do full research. A large number present the content in a disorganized manner, forcing the reader to do more work. Some have their own idiosyncratic definition of the topic, and may be slightly misleading in what they deliver. Seldom do the confluences of those aspects reach the depths of uselessness seen in these volumes. While the (ISC)2 (International Information Systems Security Certification Consortium) CBK (Common Body of Knowledge) domain structure can be problematic, the "Theory" volume does not seem to follow either the (ISC)2 study guide nor the CBK course outline. Point or section numbering is inconsistent, making it difficult even to follow the material. Tables and illustrations are unclear, and either baldly repeat surrounding text, or have no relation to it. (Tables are often carelessly broken between pages, making reading of the charts and also surrounding text extremely difficult.) There are endless mistakes in spelling, grammar, and sentence or paragraph structure. Non-standard terms are used, and not defined. Occasionally small variations in phraseology seem to imply different topics that further (and pointless) study reveals to be identical. Major heading are sometimes simply printed, and are not explained or introduced. Certain topics and phrases are heavily emphasized, although not defined, and many of these are the most minor of issues in terms both of security and of the CISSP exam. Much of the technical material is confused, such as an analysis of the correspondence between "ISDN and OSI networks," which is something like comparing apples and juice extractors. The text contradicts itself frequently: a simple list of firewalls on one page does not relate to another three pages later. Some technologies have only one aspect explained, others are touched on without mentioning inherent dangers, others are so confused that closely related topics end up being set in opposition to each other. (The malware definitions, needless to say, are appalling.) The "Practice" volume is a set of multiple choice questions supposedly similar to those you would encounter on the CISSP exam itself. Only those on the exam committee would be able to say, for certain, how close these questions come to the real thing, but I can say that, in terms of information security, a great many of these questions simply make no sense. The quality of the second volume seems to approximate that of the first. I must say that, while the books and the Web site do carry a disclaimer that the tomes are not endorsed by (ISC)2, I am slightly appalled that (ISC)2 has not objected to the use of this particular name. In fact, these books appear on the (ISC)2 resource list. Which, itself, carries a disclaimer that such a listing does not imply any endorsement. Even so, the simple association gives the work a cachet that is wholly undeserved, and probably misleading. (I should also note that, as a relatively new CISSP I don't have a solid idea of how the books on the reference list at https://www.isc2.org/cgi-bin/content.cgi?page=36 got there.) I should also note, in strict fairness, that one of my fellow instructors used these books and self-study to pass his own exam, and said that he found them very useful. But, in my own opinion, and at the risk of repeating myself, if you are studying for the CISSP: Do not buy these books. If you have bought these books, do not read them. copyright Robert M. Slade, 2001 BKCISPET.RVW 20011122 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