A fire at The Planet's data center in Houston TX on 31 May 2008 was blamed on a faulty transformer. About 9,000 servers and 7,500 customers were affected by the outage over the weekend. B3ta.com (a high-profile British comedy site) is a notable casualty. [Power was restored on 2 Jun. PGN] http://www.theregister.co.uk/2008/06/01/the_planet_houston_data_center_fire/
As an introduction, the domestic electricity supply in the UK is generally very good, with no brownouts - outages are very rare. I realise that this contrasts with the supply in some other countries. This means that when power does fail here, we're sometimes not ready for it. This week, The Sizewell B nuclear electricity generating station in Suffolk, UK went offline, and was followed shortly afterward by a coal-fired electricity generating station, Longannet in Fife, also going offline. The nuclear reactor went offline when a failsafe was triggered by a faulty reading on a control panel. The loss of capacity was worsened when several smaller generation facilities went offline for periods of time during the next few hours. The National Grid took measures to protect the supply, by lowering supply voltages and eventually shutting off supply to parts of the nation. Details at http://www.theregister.co.uk/2008/05/29/blighty_leccy_crisis/ However, the Teeside *Evening Gazette* notes that there were many false fire alarms over a wide area of the country due to the power outages, and at least one real fire (although the reported "power surge" cause may not be related to the power failure). http://www.gazettelive.co.uk/news/teesside-news/2008/05/28/n-plant-shutdown-blacks-out-tees-84229-20984943/ As the UK's electricity supply is expected to be outstripped by demand in the next few years, incidents like these may increase. (http://www.independent.co.uk/news/business/news/utility-giant-rwe-warns-of-uk-electricity-shortages-526919.html) Alistair McDonald, InRevo Ltd (http://www.inrevo.com) Tel 07017 467 396 Author of the SpamAssassin book: (http://www.packtpub.com/spamassassin/)
Computer Security: Beware of Error Messages At Bank Sites Brian Krebs's blog at *The Washington Post* website If you own or work at a small to mid-sized business, and are presented with an error message about data synchronization or site maintenance when trying to access your company's bank account online, you might want to give the bank a call: A criminal group that specializes in deploying malicious software to steal banking data is presenting victims with fake maintenance pages and error messages as a means of getting around anti-fraud safeguards erected by many banks. Dozens of banks now require business customers to log in to their accounts online using so-called "two factor authentication" methods, which generally require the customer to enter something in addition to a user name and password, such as a random, one-time-use numeric code generated by a key fob or a scratch-off pad. But one of this past year's most prolific cyber gangs—which targets virus-laden e-mail attacks against specific individuals at small to mid-sized businesses—has devised a simple but ingenious method of circumnavigating these security measures. When a victim whose PC is infected with their data-stealing malware attempts to log in at a banking site that requires two-factor authentication, the fraudsters modify the display of the bank site in the victim's browser with an alert saying "please allow 15 to 30 minutes for your request to be synchronized with our server." By intercepting the victim's password along with the one-time code—and assuring that the victim will never be able to use that one-timecode—the thieves can quickly use the one-time code to log in as the victim and proceed to drain the bank account. http://blog.washingtonpost.com/securityfix/2008/06/beware_of_error_messages_at_ba_1.html?nav=rss_blog [See Brian's outstanding blog, which notes the case of a fake error message inserted by malware during May 2008 in a spoof of the U.S. Tax Court, and further discussion. PGN]
Bank of New York Mellon Corp. officials last week confirmed that a box of unencrypted data storage tapes holding personal information of more than 4.5 million individuals was lost more than three months ago by a third-party vendor during transport to an off-site facility. [Source: Computerworld, 30 May 2008] http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9091318&source=rss_news50 Note the incredibly sophisticated encrypted technique. It is so sophisticated that Eudora does not recognise it as a word.
Runoff elections are expensive, which has led to various approaches to avoiding them by having voters express priorities among the various candidates. However, an important paper by Kenneth Arrow (RAND Corp, 1948) provides mathematical evidence that no voting system that ranks preferences among more than two candidates can guarantee logically fair nonparadoxical results. A nice example of a "winner-turns-loser" paradox with Instant Runoff Voting (IRV) is given by William Poundstone, Why Elections Aren't Fair (And What We Can Do About It), Hill & Wang, 2008, by considering hypothetically what might have happened in the 1991 Louisiana governor's race if IRV had been used. I oversimplify slightly (and ignore the political positions that might have made this logical!): 34% of the voters were for Edwin Edwards, 32% for David Duke, 27% for Buddy Roemer. Under IRV, Roemer would have been eliminated, and his votes reallocated—which could have resulted in Edwards winning. Suppose Edwards managed to have swung 6% of Duke's voters to have switched to Edwards. Then Duke would have been eliminated, and the reallocation could have resulted in Roemer being the winner. There's a nice review article on Poundstone's Gaming the Vote, and Spencer Overton's Stealing Democracy: The New Politics of Voter Suppression, Norton, 2008, in *The Nation*, 2 Jun 2008, written by Peter C. Baker. http://www.thenation.com/doc/20080602/baker
Source: Kim Zetter <email@example.com>, 29 May 2008 [PGN-ed] <http://blog.wired.com/27bstroke6/evoting/index.html> Bruce Haggard, an election commissioner in Faulkner County, Arkansas, is baffled by a problem that occurred with two voting machines in this month's general state elections. The machines allocated votes cast in one race <http://www.thecabin.net/stories/052408/loc_0524080001.shtml> to an entirely different race that wasn't even on the electronic ballot. The problem resulted in the wrong candidate being declared victor in a state House race. “I don't understand how it could possibly happen,'' Haggard told Threat Level. [It is easy to NOT UNDERSTAND if you haven't been reading RISKS for the past 20 years, or not been paying attention to the media coverage. PGN] The problem occurred with two touch-screen voting machines made by Election Systems & Software, which were the only machines used in Faulkner County's East Cadron B voting precinct. Haggard says the night before the election, officials noticed that the electronic ballot on two machines slated to be used at East Cadron B was missing the State House District 45 race. So officials printed up paper ballots to be used just for that race in that precinct. Voters cast electronic ballots on the voting machines for other races, then cast paper ballots for the District 45 race. At the end of the day, Dr. Terry Fiddler (D) had beat Linda Tyler (D) for the House seat with 794 votes to Tyler's 770. But a post-election examination revealed that despite the fact that the electronic ballots on the two machines at the East Cadron B precinct didn't display the District 45 race, the machines recorded votes for that race anyway. After some examination, officials determined that the machines had taken votes that were actually cast in a different race—the Cadron Township Constable race—and given them to the non-existent District 45 race instead. Luckily, Haggard says officials were able to determine this is where the votes came from because the touch-screen machines produce a voter-verifiable paper audit trail. Those paper trails showed correctly that there was no District 45 race on the ballot and, thus, that there were no votes cast on the machines for the District 45 race. But memory cards taken from inside the machines, showed that the machines recorded votes in the District 45 race. Officials were able to determine that those District 45 votes actually belonged to the Cadron Township Constable race because the same number of votes that were allocated to the District 45 race in the memory cards matched the number of votes that voters had cast in the Cadron Township Constable race, which appeared on the voter-verifiable paper audit trail. “Somehow the recording software had tabulated it into the wrong race, Thank goodness for the paper trail. We went to the paper trail and could show how people actually voted.'' Haggard doesn't have a clue how the switch could have happened but says that it was either a problem with the ballot definition file that election officials created before the election that tells the machines where to allocate votes or in the voting machine software itself. Once the bogus votes in District 45 were subtracted from the totals, Fiddler lost 51 votes in the race, showing that Tyler had actually won the House seat. [...] This is not the first time that ES&S voting systems have had vote-flipping problems. In Ohio during last November's general election ES&S tabulation software flipped the vote totals <http://blog.wired.com/27bstroke6/2007/11/votes-flipped-i.html> for two candidates. Officials noticed the problem when they compared the vote totals produced from the memory cards to the totals that appeared on paper printouts from the machines. ES&S machines in Ohio also had a separate problem last November when voters, among them the secretary of state, reported that their machine had dropped a candidate's name from the race <http://blog.wired.com/27bstroke6/2008/03/the-mysterious.html> and displayed a gray bar in his place. ES&S machines were also at the center of the controversy over the 13th Congressional District race in Florida in 2006 when more than 18,000 ballots cast in Sarasota County showed no vote cast in the CD-13 race after hundreds of voters had complained that the machines failed to respond to their touch. An investigation by the Government Accountability Office indicated that the machines likely weren't to blame in that case, though critics have questioned the thoroughness of that investigation. *See also:* * Votes Flipped in Ohio Race that Used E-voting machines <http://blog.wired.com/27bstroke6/2007/11/votes-flipped-i.html> * Ohio's Election Portends Trouble <http://www.wired.com/science/discoveries/news/2006/10/71999> * Report: Magnet and PDA Sufficient to Change Votes on ES&S Voting Machine <http://blog.wired.com/27bstroke6/2007/12/report-magnet-a.html>
Middletown Area High School's yearbook listed Max Zupanovic as "Max Supernova," Kathy Carbaugh as "Kathy Airbag" and Alessandra Ippolito as "Alexandria Impolite," just to name a few. The mistakes were found on four of the yearbook's 176 pages, co-editor Amanda Gummo said. Ed Patrick of Taylor Publishing, which printed the book, said his company is responsible for the errors and will provide free stickers printed with the correct names. "It happens all the time, every year," Patrick said. "Look at any yearbook in the country." [Source: AP news, 2 Jun 2008] http://apnews.myway.com/article/20080602/D91222DO1.html [Another example of blind acceptance of a spelling-checker's suggestions. I do think the publisher's comment about it "happening all the time" is a little unprofessional. AS] [My yearbooks generally had zero defects (except for my college freshman yearbook—which included a fictitious student named Duke Miasma. But then that was a feature, and not a defect. And that was before spelling checkers, when people learned how to spell. PGN] Al Stangenberger, Center for Forestry, Univ. of California at Berkeley 145 Mulford Hall # 3114, Berkeley, CA 94720-3114 (510)642-4424
Jonathan A. Zdziarski, May 2008 I did a talk recently at O'Reilly's Ignite Boston party about the exciting iPhone forensics community emerging in law enforcement circles. With all of the excitement came shame, however; not for me, but for everyone in the audience who had bought an iPhone and put something otherwise embarrassing or private on it. Very few people, it seemed, were fully aware of just how much personal data the iPhone retains, in spite of the fact that Apple has known about it for quite some time. In spite of the impressive quantities of beer that get drunk at Tommy Doyle's, I was surprised to find that many people were sober enough to turn their epiphany about privacy into a discussion about full disclosure. This has been a hot topic in the iPhone development community lately, and I have spent much time pleading with the different camps to return to embracing the practice of full disclosure. The iPhone is shrouded in secrecy on both sides - Apple (of course) uses their secrets to instill hype (and gloss over many otherwise obvious privacy flaws), while the iPhone development community uses their secrets to ensure they can exploit future versions of the firmware to find these flaws (along with all the other fun stuff we do). The secrets on both sides appear to have not only hurt the product, but run the risk of devolving an otherwise amazing device into the next surveillance fear. With the military and federal agencies testing the iPhone for possible use, some of the long-held secrets surrounding the iPhone even run the risk of affecting national security. ... http://www.zdziarski.com/papers/fulldisclosure.html
I'm surprised this item appeared in RISKS. It appears to be a generalised complaint about iTunes software; there is no evidence of a dialogue with Apple (so how can Max say "never"?) plus nothing specific in terms of version numbers or details of how to reproduce the problem. I suspect that if there was a general flaw in iTunes that caused disk space to be retained, that such a defect would be well publicised. A quick search on google returns only problems with the wrong detection of iPod capacity. The piece finishes with a vague conjecture that because this is a UI problem, it must exist on both OSX and windows platforms. How the location of the defect was tracked to the UI code, and how it affects OSX is, apparently, left as an exercise for the reader. The risk? Just because someone knows the list submission address does not make their submissions valid. Alistair McDonald, InRevo Ltd (http://www.inrevo.com) Tel 07017 467 396
[For those of you who did not dig it out, here is the text, for the RISKS archives.] Software incompatibility was part of a chain of events leading to the wrong patient getting an appendectomy. The mistake occurred on 14 Nov 2007, when two female patients were scheduled for computed tomography, or CT scans. The first patient underwent an appendectomy that evening because of the CT results. But the surgery was unnecessary. The next day, a radiologist discovered the patient's CT scan was actually that of a second patient. However, the patient's information had already been entered into the computer system for the CT scan. After the second patient's scan was completed, a radiology technician noted the error, removed the first patient's information and entered information on the second patient. When the first patient's information was deleted from the computer in the scan room, it was not deleted from the computer system used by the radiologist. “This was due to an incompatibility of the software between the two systems.''
BKSCPWSA.RVW 20080219 "Secure Programming with Static Analysis", Brian Chess/Jacob West, 2007, 978-0-321-42477-8, U$49.99/C$61.99 %A Brian Chess %A Jacob West %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2007 %G 978-0-321-42477-8 0-321-42477-8 %I Addison-Wesley Publishing Co. %O U$49.99/C$61.99 416-447-5101 800-822-6339 firstname.lastname@example.org %O http://www.amazon.com/exec/obidos/ASIN/0321424778/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321424778/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321424778/robsladesin03-20 %O Audience a+ Tech 2 Writing 2 (see revfaq.htm for explanation) %P 587 p. + CD-ROM %T "Secure Programming with Static Analysis" Part one is an introduction to software security and static analysis. The authors define static analysis as any means of assessing the programming or code without executing the program. Chapter one states that defensive programming (coding in such as way as to deal with unexpected submissions) will protect against errors, but possibly not against a deliberate adversary, and that adding security features to an application will not necessarily make for a secure program. There is a general outline of various types of software problems, and the advantages of using static analysis early in the development process. Chapter two describes the different types of static analysis and their uses. How to use static analysis as part of overall code review is covered in chapter three. Chapter four details the internal structures and functions of static analysis. Part two examines software problems that have been all too common in our application environment. Chapter five looks at the right and wrong ways to handle input. The ubiquitous buffer overflow gets two chapters: six discusses string issues, while seven deals with integer (particularly counter and pointer) situations. Error and exception handling is detailed in chapter eight. Special application environments and requirements make up part three. The Web is handled, in a generic manner, in chapter nine. Chapter ten specializes in XML (eXtensible Markup Language) and Web services. Privacy, personally identifiable information, and pseudorandom number generation all get put into chapter eleven. The special issues of privileged programs and processes are noted in chapter twelve. Part four demonstrates static analysis in practice. This is a set of instructions for using the Fortify Code Analyzer and Audit Workbench programs, which are provided on the CD. Chapter thirteen is for Java, and fourteen for the C language. (Since the rest of the book has been detailed, helpful, and quite free of taint of bias, this final sales pitch seems acceptable.) Code review and analysis gets mentioned in other works on secure programming, but this guide goes into technicalities that can be of considerable use to the developer. Chess and West have also made a very solid case that static analysis is a more effective way to find highly significant faults, and correct them earlier in the process. I commend this both to developers, and to those in security who need to better manage a secure development process. copyright Robert M. Slade, 2008 BKSCPWSA.RVW 20080219 email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer