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…
[Incoming stone was actually Rosetta stone? PGN]
To make a long story short,
The Minor Planet Center, the world clearinghouse for information about
newly discovered asteroids, raised the alarm last week to track a
threatening celestial body. This would be one of the closest approaches
ever by a sizable asteroid — its distance away being less than half the
diameter of the Earth. They announced that a previously unknown asteroid
would miss the Earth by just 5,600 kilometers. Then Denis Denisenko, of
Moscow's Space Research Institute (IKI), made an interesting discovery. He
noticed that the incoming asteroid's track matched that of the European
space probe Rosetta on a scheduled flyby of Earth. The Rosetta craft was
launched from Europe's Guiana Space Center in early March of 2004; the
purpose of the space probe is to place itself in low orbit around the
comet Churyumov-Gerasimenko at a distance of 675 million kilometers from
the sun. To get there, the billion-dollar craft will spend ten years
boosting its velocity (using the gravity assist technique) with no fewer
than three flybys of Earth and one of Mars. [Source: Bill Christensen,
Near-Miss Asteroid Found to be Artificial, 12 Nov 2007; PGN-ed. Bill was
reminded of Arthur C. Clarke's Rendezvous with Rama.]
http://www.space.com/businesstechnology/071112-technov-asteroid-mistake.html
[Mark Brader noted a BBC item:
http://news.bbc.co.uk/1/hi/sci/tech/7093402.stm
and *The Register* did an amusing take:
"Muscovite skywatcher Denis Denisenko revealed that the menacing meteor
was in fact [STRUCK THROUGH: a European Union space battleship bent on
world domination] the European Space Agency Rosetta probe, passing close
to Earth for a long-planned gravity-assist "slingshot" manoeuvre.]
http://www.theregister.co.uk/2007/11/13/rosetta_asteroid_spacecraft_patrick_moore_cockup/
[Despite many reports calling it a tanker,] The Cosco Busan was actually a container ship, and the fuel on board was solely for the purpose of running the ship. http://gcaptain.com/maritime/blog/ship-types-101-san-francisco-bay-bridge-oil-tanker-collision/ The Coast Guard blames the pilot and the captain, and notes that its radar resolution was inadequate to detect the impending collision. http://www.latimes.com/news/local/la-me-spill16nov16-ap,0,2939939.story Other reports of the 7 Nov 2007 incident indicate that some of the ship's sensors malfunctioned, the GPS was misinterpreted by the captain, and the pilot believed the captain rather than a radio warning.
This article from the BBC news site is about a small village in Wales which had seen a sudden increase of heavy traffic through its narrow streets, causing a lot of damage. Quote: "Residents were convinced that satellite navigation was to blame for the damage". It has become so bad that "In August, the Vale of Glamorgan council became so concerned over lorries being sent along narrow roads near St Hilary, it began trials of a sign warning drivers to ignore sat-nav directions." Read the full story at: http://news.bbc.co.uk/1/hi/wales/south_west/7088105.stm
http://blog.wired.com/cars/2007/11/is-safety-techn.html
In this blog post on the autopia blog, filed under "Safety" no less, Matthew
Phenix reports his experience with a Volvo S80, focusing on the wide array
of electronic "safety devices". He generalizes his impression with these
devices - those of the S80 and others - with the words
"Do I feel safer knowing other drivers' cars are doing the things — like
checking mirrors and applying enough pressure to the brake pedal — they
should be doing themselves? Not really."
I couldn't agree more to this statement.
After the recent reports about GPS/SatNav-related issues (RISKS-24.66,
"Another sat-nav accident: car destroyed, driver escapes", RISKS-24.65,
"Don't let your navigation system fool you" and many others), Phenix'
article covers a much broader area.
The Volvo "CWBS" has appeared in RISKS-24.33 ("Volvo's self braking car").
http://www.nytimes.com/2007/11/17/technology/17code.html?em&ex=1195448400&en=729de9307626c4e6&ei=5087%0A Very recently Adi Shamir sent the following announcement to few friends (reproduced here with full permission from Adi Shamir). One (possibly hidden and on purpose) bug in any high-level microprocessor as used in any modern configuration can possibly leak secret keys used by Public-Key Infrastructures (PKI). Be careful, there is a major risk. J-JQ [This attack is noted by John Markoff, Adding Math to List of Security Threats: Electronic System Could Be at Risk, *The New York Times*, 17 Nov 2007, National Edition B4. PGN] - - - - - - - - Research Announcement: Microprocessor Bugs Can Be Security Disasters Adi Shamir, Computer Science Department, The Weizmann Institute of Science, Israel With the increasing word size and sophisticated optimizations of multiplication units in modern microprocessors, it becomes increasingly likely that they contain some undetected bugs. This was demonstrated by the accidental discovery of the obscure Pentium division bug in the mid 1990's, and by the recent discovery of a multiplication bug in the Microsoft Excel program. In this note we show that if some intelligence organization discovers (or secretly plants) even one pair of integers a and b whose product is computed incorrectly (even in a single low order bit) by a popular microprocessor, then ANY key in ANY RSA-based security program running on ANY one of the millions of PC's that contain this microprocessor can be trivially broken with a single chosen message. A similar attack can be applied to any security scheme based on discrete logs modulo a prime, and to any security scheme based on elliptic curves (in which we can also exploit division bugs), and thus almost all the presently deployed public key schemes will become vulnerable to such an attack. The new attack (which we call a "Bug Attack") is related to the notion of fault attacks discovered by Boneh, Demillo and Lipton in 1996, but seems to be much more dangerous in its implications. The original fault attack required physical possession of the computing device by the attacker, and the deliberate injection of a transient fault by operating this device in an unusual way (in a microwave oven, at high temperature, with high frequency clock, or with a sudden spike in the power supply). Such attacks are feasible against smart cards, but are much harder to carry out against PC's. In the new bug attack, the target PC can be located at a secure location half a world away, and the attacker has no way of influencing its operating environment in order to trigger a fault. In addition, millions of PC's can be attacked simultaneously, without having to manipulate the operating environment of each one of them individually. We now describe the basic idea of the new attack. We assume that the RSA decryption (or signature generation) is using the Chinese Remainder Theorem (CRT) which speeds up the operation by a factor of 4 compared to naive implementations, that each multiplication of big numbers proceeds by breaking them into the largest words which can be handled by the native multiplier in that microprocessor (typically 32 or 64 bits), and that all pairs of such words from the two numbers will be multiplied in some order. Knowing the target's public key n, the attacker can easily compute a half size number c which is guaranteed to be between the two secret factors p and q of n. For example, a number c which is the square root of n (rounded to the nearest integer) always satisfies p<c<q, and any number close to c is also likely to satisfy this condition. The attacker now chooses a message m which is equal to c, except that two low order words in it are replaced by a and b, and submits this "poisoned input" to the target PC. The first step in the CRT computation is to reduce the input m modulo p and q. Due to its choice, m will be randomized mod the smaller p, but remain unchanged mod the larger q. The next step in RSA-CRT is always to square the reduced inputs mod p and q, respectively. Since a and b are unlikely to remain in the randomized value of m (mod p), the computation mod p is likely to be correct. However, mod q the squaring operation will contain a step in which the word a is multiplied by the word b, and by our assumption the result will be incorrect in at least one bit. Assuming that the rest of the two computations mod p and q will be correct, the final result of the two exponentiations will be combined into a single output y which is likely to be correct mod p, but incorrect mod q. The attacker can then finish off his attack in the same way as the original fault attack, by computing the gcd of n with y^e-m, where e is the public exponent of the attacked RSA key. With very high probability, this gcd will be the secret factor p of n. This completely breaks the security of this key. How easy is it to verify that such a single multiplication bug does not exist in a modern microprocessor, when its exact design is kept as a trade secret? There are 2^128 pairs of inputs in a 64x64 bit multiplier, so we cannot try them all in an exhaustive search. Even if we assume that Intel had learned its lesson and meticulously verified the correctness of its multipliers, there are many smaller manufacturers of microprocessors who may be less careful with their design. In addition, the problem is not limited to microprocessors: Many cellular telephones are running RSA or elliptic curve computations on signal processors made by TI and others, FPGA or ASIC devices can embed in their design flawed multipliers from popular libraries of standard cell designs, and many security programs use optimized "bignum packages" written by others without being able to fully verify their correctness. As we have demonstrated in this note, even a single (innocent or intentional) bug in any one of these multipliers can lead to a huge security disaster, which can be secretly exploited in an essentially undetectable way by a sophisticated intelligence organization.
In this year's New York City Marathon on 4 Nov 2007, runners had chips in
their shoes that were intended to record when they crossed the starting line
and the finish line. This compensates those runners for the time it takes
to reach the starting line. However, the electronic timing system failed to
record 2,300 runners out of a field of more than 38,000. Because good
results in the NY race would enable qualification for the Boston Marathon,
surmounting this problem this was rather crucial to some of those runners.
Fortunately for them, the Boston officials accepted the self-reported times
recorded by the timers of those individuals and accepted by NY. The
"technical problem" was caused by interference (unspecified) that reportedly
disrupted the system for about three minutes at the start on one of three
starting areas. One woman's recorded time was indeed off by almost three
minutes, which may have been just enough to let her qualify for Boston.
(The official results are supposed to be posted on 19 Nov.) [Source:
Abigail Lorge, Timing Glitch Affected Thousands in Marathon, *The New York
Times*, 8 Nov 2007; PGN-ed]
[Considering which weekend this was ("fall back"), I'm amazed that the
timing wasn't an *hour* off... HB]
On election day, 6 Nov 2007, the results were reportedly reversed in one race, for trustee, in Hamilton Township, Lawrence County, Ohio, as a result of "a programming error" in ES&S software. Because the final two candidates for the Ironton City Council race were within four votes of one another, that race was also being reevaluated. In Proctorville, the mayor's race had a single vote separating the leaders, and the council race had a tie for the second seat. In Symmes Valley, the fiscal office winner also had a one-vote margin. And so on. [Source: Mark Shaffer *The Ironton Tribune*, 8 Nov 2007; PGN-ed] http://www.irontontribune.com/articles/2007/11/08/news/news170.txt [Of course one of the main problems with many current electronic voting machines is that recounting is not particularly meaningful if the votes are already incorrectly recorded, in the absence of a definitive independent audit trail. PGN]
An Illinois woman (identified only as C.B.) is suing the St. Louis Cardinals (damages at least $25K) for allowing a text message that falsely suggested her 17-year-old daughter (A.B.) has an "STD") (of course, implying a sexually transmitted disease, rather than a "standard"!) to be posted on the Busch Stadium jumbotron during a game, apparently requested by a school classmate of A.B. "The lawsuit, filed Wednesday in St. Louis Circuit Court, claims the 17-year-old girl was so traumatized by the message last year during a class trip that she stayed out of school the rest of the semester and took her finals in a school office to avoid ridicule." More than 48,000 people attended the game. [Source: Lawsuit filed over text message on St. Louis Cardinals board, KMOV, 9 Nov 2007; PGN-ed] It seems that anyone can text a cell-phone message and have it displayed, for a small fee. The expected uses are presumably proposing marriage, announcing an engagement, wishing happy birthday, and other similar occasions. However, this service clearly opens up all sorts of opportunities for misinformation, but also opportunities for intentionally having defamatory messages posted so that you can sue. Incidentally, KMOV reminded its viewers that at the first home game of 2006, a proscribed four-letter word appeared on the screen, which management attributed to a "technical error". The KMOV website has lots of further discussion.
Sending out machine translation without reading the result resulted in a diplomatic incident: http://www.guardian.co.uk/g2/story/0,,2206335,00.html?gusrc=rss&feed=technology "So when indignant officials at the Dutch foreign ministry received an email from a group of Israeli journalists that began, "Helloh bud, enclosed five of the questions in honor of the foreign minister: The mother your visit in Israel is a sleep to the favor or to the bed your mind on the conflict are Israeli Palestinian," they might perhaps have guessed what had happened. Sadly, they did not." The Guardian claims that the journalists used the popular translation engine Babelfish, but this appears to be incorrect. Babelfish doesn't handle Hebrew. Hebrew sources indicate that they may have used Babylon. Shoshannah Forbes http://www.xslf.com [Also noted by Mark Brader. PGN]
We've seen many reports of financial institutions sending e-mail virtually indistinguishable from phishing and spam. Lately, I've been in the market for new computer security hardware and software. Security companies seem to have taken email lessons from the worst financial institutions. Some common problems in security company emails: * "Click here if your email program has trouble displaying this email" * Images and links that point to third party web sites. * Unsubscribe links that point to third party web sites These security companies are undercutting user security education. We have a hard time keeping users from clicking on links in suspicious emails; we don't need security firms reinforcing bad behavior. Rex Sanders, USGS http://tinyurl.com/84kdo :-)
Stephen Smoliar's blog contains various items that might interest RISKS readers. There is one rather egregious example of a spelling corrector: http://therehearsalstudio.blogspot.com/2007/04/dangerous-mix-of-globalization-and.html The most recent, today, considers some of the problems that the San Francisco Public Library is experiencing in its attempts to modernize: http://therehearsalstudio.blogspot.com/2007/11/speak-out-against-defective-technology.html
Tom Watson's message (Risks 24.82) about redacting account numbers attracted my attention (sorry I'm running behind). Besides the risk associated with switching methods (access to old and new redacted numbers revealed complete number), there is a risk with choice of redaction schemes--and many knuckleheads are choosing wrongly nowadays. Credit-card systems seem to provide cultural leadership in account-number hashing. The idea is to show people enough digits so they know which of their cards you want to refer to, but too few to let an observer guess the whole number. Four digits works well. By the birthday paradox, it's not likely you'll get collisions when customers have much less than 100 cards. Even the shortest credit-card numbers are 12 digits long. The first few digits identify the bank so they're easy to guess. The last digit is a checksum so it says something about the rest, but an adversary will still have to guess, say, four digits. Most cards have 15 or 16 digit numbers now, making you guess seven or eight digits; an adversary will likely guess someone else's number. With (US) Social Security numbers and bank account numbers things are different. The last four digits of the SSN are the critical ones! The first five are easy to guess (they encode issuing location and date). People think that it's smart to ape the last-four-digits scheme used with credit-card numbers, but we don't show an SSN hash because people have multiple SSN's, we show it to help distinguish people with similar names. For that purpose the first few digits are adequate and much less sensitive. Bank account numbers present a similar problem. The first digits often identify branch and account type (I will pass over ABA check routing numbers which are trivial to guess) so the trailing digits are generally more sensitive. Most people need to see enough digits to tell which account out of several they have with one bank (checking/savings/etc.) is the subject of communication. For many banks, the best plan would be to show some leading digits from the account number--even though they'll be the same for many customers they'll be different for each account of any one customer. It appears that someone at Watson's bank was aware of this years ago and set up the best system. Then (perhaps along with some other "upgrades") some dimwit decided that since it's good to show "last four digits" with credit cards, it must also be good to show the last four digits of checking account numbers. This kind of failure is why RISKS DIGEST will never lack for material!
Just the thing for those hostage and robbery situations - I don't think: http://www.kvue.com/news/local/stories/110907kvueverizonalarm-bm.1f46e16ee.html "The alarm is not ear-splitting, but it is loud enough to be heard at least several yards away" Verizon claims the FCC requires this. The FCC says it's not that stupid.
Twenty-Third Annual Computer Security Applications Conference (ACSAC) Practical Solutions To Real World Security Problems December 10-14, 2007 Miami Beach Resort and Spa Miami Beach, FL, USA Cristina Serban, PhD, CISSP 2007 ACSAC Conference Chair Hotel and Conference Registration at http://www.acsac.org/ [This message is unfortunately less timely than it ought to be. 19 Nov is the deadline for early registration and the discounted hotel rate. PGN]
[Dres is a long-time RISKS contributor, educator, and former FAA Advanced Automation director. He has been relatively quiet in RISKS lately. PGN] ICRAT 2008: Papers due 31 January, 2008 See www.ICRAT.org. June 1-4, 2008 at George Mason University, Fairfax, VA ICRAT is an excellent forum for young researchers within air transportation to share their work, expand their professional network, and gain new knowledge and inspiration. This third edition of ICRAT includes one day of tutorials, two days of technical presentations and a doctoral symposium where PhD students can expose their research problems to get advice from established scientists in the field. Parallel invited workshops on Single European Sky ATM Research and US NextGen initiatives are also expected. ICRAT 2008 is jointly organized between EUROCONTROL Experimental Centre and George Mason University, and is sponsored by the US Federal Aviation Administration, NASA, the European Commission, and by EUROCONTROL. Financial support for participating in this conference is available to a limited number of young scientist and PhD students. We expect to be able to be able to cover travel expenses, room and board for students from the U.S. whose papers are accepted.
BKNTSCHK.RVW 20070921 "Network Security Hacks", Andrew Lockart, 2007, 0-596-52763-2, U$29.99/C$38.99 %A Andrew Lockart %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 2007 %G 0-596-52763-2 978-0-596-52763-1 %I O'Reilly & Associates, Inc. %O U$29.99/C$38.99 707-829-0515 fax: 707-829-0104 nuts@ora.com %O http://www.amazon.com/exec/obidos/ASIN/0596527632/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0596527632/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0596527632/robsladesin03-20 %O Audience i Tech 2 Writing 1 (see revfaq.htm for explanation) %P 298 p. %T "Network Security Hacks, 2nd Edition" Chapter one lists twenty-two tips for using a number of utilities and programs to enhance the security of UNIX systems. The explanations are clear and specific, although you would probably have to be really familiar with UNIX administration to get the full benefit of these suggestions. Windows gets fourteen hacks in chapter two. While useful, these could have had more explanation in some cases, in regard to the limitations and pitfalls of the recommendations. A variety of tools that address aspects of confidentiality are listed in chapter three. Almost all of the firewall tools discussed in chapter four are for UNIX, although some do have Windows versions. (The Windows firewall is discussed, but so poorly that one almost suspects that the whole purpose is to force the reader to use the suggested alternative.) Advice on securing various services and applications (mostly from Guess What Operating System) is given in chapter five. Again, the bulk of the network security tools discussed in chapter six are for UNIX, with some Windows editions. The wireless tips, in chapter seven, work best with UNIX. The same is true with the logging tips in chapter eight, although there is mention of arranging to have Windows report to a syslogd. Network monitoring, and some analysis thereof, is in chapter nine. Tunnels and VPN (Virtual Private Network) products are detailed in chapter ten. Most of the network intrusion detection material in chapter eleven concerns Snort. (You are not my NIDS, you are a Snort!) Chapter twelve lists a few recovery and response tools. If you run a UNIX system and network, this book enumerates many useful tasks, settings, and tools that will help to make your systems and network more secure. copyright Robert M. Slade, 2004, 2007 BKNTSCHK.RVW 20070921 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm
Please report problems with the web pages to the maintainer