RISKS-LIST: Risks-Forum Digest  Friday 8 January 2010  Volume 25 : Issue 90



ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy



***** See last item for further information, disclaimers, caveats, etc. *****

This issue is archived at <http://www.risks.org> as

  <http://catless.ncl.ac.uk/Risks/25.90.html>

The current issue can be found at

  <http://www.csl.sri.com/users/risko/risks.txt>



  Contents:

NIST-certified USB Flash drives with hardware encryption cracked (PGN)

Skype: the case of disappearing telephone numbers (Chrisf J Brady)

Libel by Twitter? (Al Stangenberger)

Risks of USB chargers for cell phones (Paul Pomes)

Y2K+10: look at the Hex (Dave Hansen)

Y2K+10: what's underlying? (Chris Smith)

Y2K+10: The problems with sticky tape (Peter Houppermans)

Weight of a Land Rover incorrectly input into UK VCA database

  (Matthew Wilson)

Re: Eurostar RISKS (Richard Pennington)

Leaves on Tracks (Curt Sampson)

Re: LED Traffic Lights are efficient (Dick Mills, Terrence Enger)

Re: Silent Hybrid Nearly Causes Carbon Monoxide Poisoning

  (Walt Strickler)

NDSS Program (Internet Society)

Abridged info on RISKS (comp.risks)



----------------------------------------------------------------------



Date: Fri, 8 Jan 2010 10:47:27 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: NIST-certified USB Flash drives with hardware encryption cracked



Certain USB drives using AES encryption have a major flaw that allows a way

to bypass the login rules: "The SySS experts wrote a small tool for the

active password entry program's RAM which always made sure that the

appropriate string was sent to the drive, irrespective of the password

entered and as a result gained immediate access to all the data on the

drive."  In essence, despite the use of AES 256-bit encryption, the password

checker program always put out the same bitwise-identical POSITIVE response

to a successful password check, which was trivially reproducible.  [Source:

The H Security, 4 Jan 2010; Thanks to John Curran; PGN-ed]

http://www.h-online.com/security/news/item/NIST-certified-USB-Flash-drives-with-hardware-encryption-cracked-895308.html



  [Misleading title; make sure you understand what is `certified' and what

  that means (or doesn't mean) with respect to systems in the large.  PGN]



------------------------------



Date: Thu, 7 Jan 2010 17:10:04 -0800 (PST)

From: Chris J Brady <chrisjbrady_at_private>

Subject: Skype: the case of disappearing telephone numbers



The latest version of Skype (partly owned by eBay) is causing major

irritations amongst web designers and users. By default when downloaded and

installed it also installs a small utility unbeknown to the user. This

utility effectively reformats any telephone &/or fax. nos. on a web page

including adding a little flag icon and also embeds a link behind these to

link to Skype. Theoretically clicking on the telephone no. then initiates a

Skype call to that no.



Unfortunately there are some side effects.



Web designers are especially upset that the reformating effectively destroys

the look of a web page, especially if a web site has been designed to a

corporate style when Skype then reformats parts of every page to suit

itself.



Secondly in many cases the telephone &/or fax nos. are simply deleted from

the web page displayed never to be seen again. Even more irritating is that

telephone nos. disappear when web-based emails are viewed such as when using

Yahoo Mail and/or Google Mail. That is until a cure is implemented.



And the cure is to remove the embedded utility - not easy. And/or remove

Skype entirely. Both are reported to be effective.



The risk of course is trusting Skype when the company (partly owned by eBay)

has deliberately chosen to allow this feature to be installed by default

without any user choice in the matter.



------------------------------



Date: Mon, 04 Jan 2010 19:31:53 -0800

From: Al Stangenberger <forags_at_private>

Subject: Libel by Twitter?



Interesting legal commentary on the problem of crafting a comment within

Twitter's 140-character limit for messages.  The forced brevity can cause

the unwary to make statements but not to qualify them as opinion due to the

maximum message length.

  http://writ.news.findlaw.com/hilden/20100104.html



------------------------------



Date: Wed, 30 Dec 2009 20:40:54 -0800

From: Paul Pomes DVM <Dr.Pomes_at_private>

Subject: Risks of USB chargers for cell phones



My wife recently purchased a no-name third-party USB charger for her Droid

cell phone. When the included cable is connected to the USB port of her

laptop, the phone charges normally albeit somewhat slowly.  Connecting the

cable to the included voltage-sensing wall transformer starts a menagerie of

interesting effects: opening applications, creating garbled text messages,

changing settings, etc. No doubt this is due to floating signal lines with

induced voltages that is triggering this storm of activity.



It takes little imagination, however, to visualize more sinister

applications. A very small amount of logic, specific for each cell phone

model the charger is marketed for, could be embedded inside the plastic

transformer block. After a few minutes delay the phone could be probed for

sensitive information and the results sent to an electronic dead-drop. The

risk is a classic trade-off of security vs convenience. Having a single

charger for our Kindles, cell phones, PDAs simplifies the number of

ancillary chargers we need to tote around. Mixing the mission of power

supply and data conduit opens a covert channel.



Paul Pomes, DVM (formerly a network and computer security engineer until I

got tired of meetings) http://www.FurryFriendsVet.com

http://PaulPomes.livejournal.com http://www.facebook.com/Paul.Pomes



------------------------------



Date: Fri, 8 Jan 2010 12:14:15 -0500

From: Dave Hansen <iddw_at_private>

Subject: Y2K+10: look at the Hex



A lot of the problems seem to share a common characteristic -- instead of

2010, the date appears to be 2016.



Debora Weber-Wulff wrote:

> Seems that the software thinks that it is the year 2016 and not

> 2010, so all of the cards are no longer valid. A friend pointed out to me

> that 2016 is 11111100000 in binary.



It's more interesting to look at both numbers in hexadecimal: 2009 is 0x7d9

while 2016 is 0x7e0.  A little BCD math, perhaps?



------------------------------



Date: Fri, 8 Jan 2010 11:12:28 -0500 (Eastern Standard Time)

From: Chris Smith <smith_at_private>

Subject: Y2K+10: what's underlying?



  "Seems that the software thinks that it is the year 2016 and not 2010, so

  all of the cards are no longer valid. A friend pointed out to me that 2016

  is 11111100000 in binary."



I - and I suspect many others - would be interested in knowing the

underlying error behind this problem. One the best reasons to read RISKS is

to expand your personal list of bugs to watch out for.



I can see at least one strong possibility. It relates to the point that chip

cards - and especially contactless chip cards - are very low power, low

resource, devices. The hardware and software developers optimize

*everything*.



Expressing the problem as though a two-digit year were in use, the problem

was that 9 was followed by 16, not 10. But in hexadecimal, $09 was followed

by $10 - but it should have been $0A.



Chip cards could reasonably use BCD (binary coded decimal), where a decimal

number is stored in a byte as two separate digits, one per nibble. At some

point, if the chip provides a current year value, it would provide it as 10

(hex $10, binary 0001000). But if a terminal thinks this is a *binary*

field, it will misinterpret it -- starting in the year 2010. Any conversion

from 10 to 2010 would have been done by the terminal.



It is also worth noting that card systems in general make heavy use of

BCD. The numbers on your magnetic card stripe, for example, are all BCD.



Note that this raises the possibility that the *terminal* is at fault for

misunderstanding the data format, not the card. But it also makes clear -

consistent with reports - that even if the card is the problem, the terminal

can correct the difficulty with a customized conversion routine, as long as

it can accurately identify which cards have the problem.



Note that BCD is sufficiently common in small processors that the 6502

processors actually had a 'decimal mode', where adding $01 to $09 resulted

in $10, and adding $01 to $99 both gave $00 and set the carry flag.



------------------------------



Date: Fri, 08 Jan 2010 09:56:19 +0100

From: Peter Houppermans <peter_at_private>

Subject: Y2K+10: The problems with sticky tape (RISKS-25.89)



The "German" credit card problem is interesting from a number of angles:



* Disaster Recovery: imaging you're abroad and your cash becomes

  inaccessible, but this time not because your bank fails.  At least the

  good news is that that's easier to solve, and a fallback was available.

  Uncomfortable idea when you're traveling.



* Technology migration risk: I guess it's now properly publicly known that

  the so-called safe chip is easy to defeat by simply avoiding it.  This

  presents an interesting issue with respect to card cloning as you actually

  do not need access the chip itself.  Copy the magnetic strip and make sure

  any chip on the target card malfunctions (expect a surge in nail varnish

  sales).  The fallback option has now reduced the level of trouble for the

  end user, but I suspect a surge in that method of old, magnetic strip

  cloning, is unavoidable.



* Think before you report: my immediate reaction was "uh oh" when I saw the

  sticky tape reporting, because I knew what would happen next: tight

  (anti-fraud) mechanical tolerances in ATMs resulting in transfer of sticky

  tape from card to mechanism, thus gumming up the works (and possibly

  retaining the card in the process).  Sure enough: in the evening those

  same sources reporting the "solution" were now labeling it a "problem"

  without the slightest hint of irony..



------------------------------



Date: Fri, 8 Jan 2010 10:25:25 -0000

From: "Matthew Wilson" <matthew_at_private>

Subject: Weight of a Land Rover incorrectly input into UK VCA database



It appears that the UK's Driver and Vehicle Licensing Agency - DVLA - have

routinely been giving older series Land Rovers a revenue weight of 3499 kgs,

which puts them in the commercial class 7 bracket of vehicle.  The Land

Rover (apart from some specialist version of the vehicle) should be a class

4.



It seems this weight choice was done when the computer database was set up

and this 'random' value chosen.



Now that the garages where you submit your vehicle to gain a MOT certificate

to prove it roadworthy have been computerised, entering the chassis

number/VIN (vehicle identification number) of the vehicle causes the test to

be refused as the incorrect weight retrieved from the database flags a class

7 test.  The vast majority of MOT garages are only equipped for class 4

vehicles, not class 7.



Lots of additional info about this here:

  http://www.glencoyne.co.uk/motclass.htm



I think a classic case of garbage in garbage out...



------------------------------



Date: Fri, 8 Jan 2010 00:50:02 -0000

From: "Richard Pennington" <richardhelen_at_private>

Subject: Re: Eurostar RISKS (Thorn, RISKS-25.89)



Here are a few comments on Anthony Thorn's piece about the Eurostar failures

on 18 Dec 2009.



Firstly, one of my colleagues traveled on the last Eurostar train to pass

through the Channel Tunnel from France to England before the trains failed.

He reports that his train was obviously losing power and finished the

journey traveling very slowly.



Secondly, I have seen no public report into what the difference was between

the "winterisation" applied to the Eurostar trains this year (when there was

a massive common-mode failure) and in the 15 previous years of reliable

operation (in all sorts of weather conditions including a very cold spell in

February 2009).



Thirdly, I have seen no public report into what happened to the signaling

system.  In particular, why did the controllers keep sending more trains

into a tunnel which was already blocked by the previous failed trains?  [As

a result, they ended up with five trains trapped in the tunnel, all with

identical failures.  There is one track in each direction, with crossovers

for use in emergencies.]  I can understand that a total electrical failure

(which appears to have occurred in each of the five failed trains) would

prevent communications between the trains and the controllers - although

that in itself raises an obvious single point of failure - but what happened

to the trackside signalling systems, and why did they not send a message

back to the controllers?  And how long did it take the controllers to

realise that there were no trains coming out of the other end of the tunnel?



------------------------------



Date: Fri, 8 Jan 2010 19:57:03 +0900

From: Curt Sampson <cjs_at_private>

Subject: Leaves on Tracks (was Re: LED Traffic Lights are efficient...



On Sun, 27 Dec 2009 05:38:43 -0500, Jerry Leichter <leichter_at_private> writes:



> Every fall [in the NY area], we get delays in mass transit because of wet

> leaves on train tracks. I never recalled hearing of such problems years

> back....



He goes on to say that this problem has been attributed to the change from

friction braking to regenerative braking. I believe that this may not be

entirely, or even substantially correct.



The problem itself is not so very new to my knowledge: I clearly recall it

being reported in the UK (on Thatcher-era passenger stock), in 1991, the

first year that I lived there. Further, R. A. Wood's 1999 paper "Train

Detection by Track Circuit: the Effect of the Wheel/Rail Interface"

discusses leaves (among other track contaminants) and blames the issue on

two quite different modernisation issues.



The first is the switch from steam to diesel locomotion ("Leaves were rarely

a problem in steam days, for the simple reason that flammable vegetation at

the side of the track was incompatible with machines that ejected burning

cinders into the air."--section 2) and better bogies ("The main factor

appeared to be the greatly improved suspension systems of modern

bogies. Instead of bouncing, scraping, and sliding around the track, the

wheel on a modern bogie runs straight and true along the rails, with a

significantly reduced scrubbing action between wheel and rail."--section 3).



So there's the correction. Additionally, I must say, I do feel a little

frisson when I think about a fire hazard mitigating another risk.



Curt Sampson <cjs_at_private> +81 90 7737 2974



------------------------------



Date: Sun, 27 Dec 2009 09:47:25 -0500

From: Dick Mills <dickandlibbymills_at_private>

Subject: Re: LED Traffic Lights are efficient (Johnson, R 25 88)



> John Johnson (R 25 88): "The problem is also evident on motor vehicles

  with LED signal and stop lights.  Snow is not melted away by the signal

  and stop lights and accumulation blocks the lights."



Neither can incandescent stop and signal lights melt snow if they are not

used often; such as long stretches of driving on the open highway.  Nor

could they melt snow when there was a generous air gap between the bulb and

the lens cover.



I can't recall any mention of this risk in the pre LED era. What's new?



Likely predates RISKS, but this old fogey recalls the introduction of the 2

filament tail-light/brakelight bulb in common use for at least 50 years.

This was introduced to address the problem mentioned here.  At night, when

visibility is lowest, and the tail lights would be on, the heat of the tail

light would defrost the lens so the brakelights were more visible.



Just as an aside - on LED lights - I saw an ad that said that LED brake

lights were safer since they lit up more quickly, at least a tenth of a

second. I poo-poo'd this until I thought a bit.  60 mph is 88 feet/second

1/10 second is 8.8 feet saving even half that much in a panic stop is quite

significant !



P.M. Wexelblat PhD, Erst of the Dept. of Computer Science

University of Massachusetts Lowell, One University Ave, Lowell, MA 01854



------------------------------



Date: Fri, 08 Jan 2010 09:41:00 -0500

From: Terrence Enger <tenger_at_iseries-guru.com>

Subject: Re: LED Traffic Lights are efficient (Seaman, RISKS-25.89)



> LEDs are desirable because they inexpensive to operate due to their high

  efficiency.



LEDs *are* highly efficient, but I suspect that desirability comes far more

from the long lifetime.  It is not much work to unscrew a bulb and screw in

a new one, but getting into position to do that is not so easy.



So, the cost of energy to melt the precipitation is not obviously a

show-stopper for a simple-minded heater.  We know from past experience that

the power for one light is at least adequate.  And the cost of installation

can probably be brought into the same order of magnitude as the cost to

...um... change a light bulb.



------------------------------



Date: Fri 1 Jan 2010 07:34:44 -0700

From: waltstrickler_at_private

Subject: Re: Silent Hybrid Nearly Causes Carbon Monoxide Poisoning (R-25.88)



So I have a (maybe obvious) question: Why would a car whose engine is

running need synthetic engine noise? The letter to the editor even said that

it was running at full throttle, but the author seems to have missed the

irony.



I suspect that this is not a risk of the hybrid being silent, but of the

fact that the Prius is turned off by taking the RFID (Radio Frequency

Identification Device) that enables it out of range, or by performing the

unintuitive (and not usually necessary) act of pushing the START button for

3 seconds. In this case, the RFID was probably left in a purse, which was

left in the car, and the car was most likely in battery-charging mode when

left in the garage. The 4 hours mentioned in the letter seems like a long

time to charge the batteries, but perhaps this one had been converted to a

plugin hybrid with much larger battery capacity.



------------------------------



Date: Mon, 4 Jan 2010 14:07:25 -0500 (EST)

From: Internet Society <craemer_at_private>

Subject: NDSS Program



17th Annual Network and Distributed System Security (NDSS) Symposium

The Dana on Mission Bay, San Diego, California, 28 Feb -- 3 Mar 2010



New research on 24 topics to be presented



The NDSS '10 program committee has selected 24 original research papers for

presentation in San Diego.  Topic areas include:



* Distributed Systems and Networks

* Web Security and Privacy

* Intrusion Detection and Attack Analysis

* Anonymity and Cryptographic Systems

* Security Protocols and Policies

* Languages and Systems Security

* Malware

* Spam



A complete list and summaries of each paper can be found at:

www.isoc.org/isoc/conferences/ndss/10/program.shtml



Keynote by former White House counterterrorism and cyber security czar

Richard A. Clarke.  Special panel discussion on Ethics in Networking and

Security Research.



Registration Information: www.isoc.org/ndss10

Organized by the Internet Society



------------------------------



Date: Thu, 29 May 2008 07:53:46 -0900

From: RISKS-request_at_private

Subject: Abridged info on RISKS (comp.risks)



 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.

=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)

 if possible and convenient for you.   The mailman Web interface can

 be used directly to subscribe and unsubscribe:

   http://lists.csl.sri.com/mailman/listinfo/risks

 Alternatively, to subscribe or unsubscribe via e-mail to mailman

 your FROM: address, send a message to

   risks-request_at_private

 containing only the one-word text subscribe or unsubscribe.  You may

 also specify a different receiving address: subscribe address= ... .

 You may short-circuit that process by sending directly to either

   risks-subscribe_at_private or risks-unsubscribe_at_private

 depending on which action is to be taken.



 Subscription and unsubscription requests require that you reply to a

 confirmation message sent to the subscribing mail address.  Instructions

 are included in the confirmation message.  Each issue of RISKS that you

 receive contains information on how to post, unsubscribe, etc.



=> The complete INFO file (submissions, default disclaimers, archive sites,

 copyright policy, etc.) is online.

   <http://www.CSL.sri.com/risksinfo.html>

 The full info file may appear now and then in RISKS issues.

 *** Contributors are assumed to have read the full info file for guidelines.



=> .UK users should contact <Lindsay.Marshall_at_private>.

=> SPAM challenge-responses will not be honored.  Instead, use an alternative

 address from which you NEVER send mail!

=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.

 *** NOTE: Including the string "notsp" at the beginning or end of the subject

 *** line will be very helpful in separating real contributions from spam.

 *** This attention-string may change, so watch this space now and then.

=> ARCHIVES: ftp://ftp.sri.com/risks for current volume

     or ftp://ftp.sri.com/VL/risks for previous VoLume

 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive

 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.

   Lindsay has also added to the Newcastle catless site a palmtop version

   of the most recent RISKS issue and a WAP version that works for many but

   not all telephones: http://catless.ncl.ac.uk/w/r

 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .

==> PGN's comprehensive historical Illustrative Risks summary of one liners:

    <http://www.csl.sri.com/illustrative.html> for browsing,

    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing

==> Special Offer to Join ACM for readers of the ACM RISKS Forum:

    <http://www.acm.org/joinacm1>



------------------------------



End of RISKS-FORUM Digest 25.90

************************



Received on Fri Jan 08 2010 - 15:21:19 PST





]]>
Fri, 8 Jan 2010 15:21:19 PST
RISKS List Owner



http://lists.jammed.com/RISKS/2010/02/0000.html






From: RISKS List Owner <risko_at_private>




Date: Sun, 14 Feb 2010 14:40:15 PST






RISKS-LIST: Risks-Forum Digest  Sunday 14 February 2010  Volume 25 : Issue 94



ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy



***** See last item for further information, disclaimers, caveats, etc. *****

This issue is archived at <http://www.risks.org> as

  <http://catless.ncl.ac.uk/Risks/25.94.html>

The current issue can be found at

  <http://www.csl.sri.com/users/risko/risks.txt>



  Contents:  Happy Valentine's Day!  (My heart is still in RISKS.)

Electronic Systems That Make Modern Cars Go (Jim Motavalli)

Toyota Braking Problem Link (Gene Wirchenko)

How computers took over our cars (Amos Shapir)

Ex-Toyota lawyer points to electronic throttle control (PGN)

Motor racing solution to Toyota runaway (Dave Crooke)

Mercedes Benz E Class Commercial (Richard S. Russell)

Medical privacy: They never, ever learn (Geoff Kuenning)

Who Owns Your PC? (Lauren Weinstein)

EMV busted (David Magda)

Website glitch drives up parking penalty (Nick Rothwell)

The Century Bug will repeat ... (Jonathan de Boyne Pollard)

Making the grade or changing the grade? (Jeremy Epstein)

Phishing Scam Cripples European Emissions Trading (Danny Burstein)

Meta-spearphishing (Jeremy Epstein)

CAPTCHA with the answer in the ALT text (jidanni)

Re: GPS Control Software Glitch: NANU Issued (Andy Piper)

Re: Unsearchable Stores (Bob Bramwell)

Abridged info on RISKS (comp.risks)



----------------------------------------------------------------------



Date: Sat, 6 Feb 2010 14:41:34 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Electronic Systems That Make Modern Cars Go (Jim Motavalli)



Source: Jim Motavalli, *The New York Times*, 4 Feb 2010

http://nytimes.com/2010/02/05/technology/05electronics.html



The electronic systems in modern cars and trucks -- under new scrutiny as

regulators continue to raise concerns about Toyota vehicles -- are packed

with up to 100 million lines of computer code, more than in some jet

fighters.  ``It would be easy to say the modern car is a computer on wheels,

but it's more like 30 or more computers on wheels,'' said Bruce Emaus, the

chairman of SAE International's embedded software standards committee.  Even

basic vehicles have at least 30 of these microprocessor-controlled devices,

known as electronic control units, and some luxury cars have as many as 100.



  [Nice article on "throttle-by-wire" cars, eschewing physical linkages.  PGN]



------------------------------



Date: Thu, 11 Feb 2010 12:09:57 -0800

From: Gene Wirchenko <genew_at_private>

Subject: Toyota Braking Problem Link



It appears that the problem was software:



  Toyota to recall 400,000 Prius cars over software glitch.  Following

  driver complaints about poor braking performance, Toyota plans to recall

  around 400,000 Prius hybrid cars to replace software controlling the

  antilock braking system.

  http://www.itbusiness.ca/it/client/en/home/news.asp?id=56365



------------------------------



Date: Thu, 11 Feb 2010 17:56:55 +0200

From: Amos Shapir <amos083_at_private>

Subject: How computers took over our cars



Increasingly, computers are in control of our cars, says Paul Horrell, and

that is changing our relationship with the open road

  http://news.bbc.co.uk/1/hi/magazine/8510228.stm



------------------------------



Date: Thu, 11 Feb 2010 7:33:14 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Ex-Toyota lawyer points to electronic throttle control (USATODAY.com)



Nancy Leveson commented to me, ``When is the auto industry (and everyone

else) going to learn that you cannot `exhaustively test' software and

introduce modern safety engineering techniques that are appropriate for

digital systems and not just use those developed for the electro-mechanical

systems of the past?''



------------------------------



Date: Sun, 31 Jan 2010 13:38:00 -0600

From: Dave Crooke <dcrooke_at_private>

Subject: Motor racing solution to Toyota runaway



It occurred to me that I've had a throttle stuck wide open twice in the

past[*], and neither incident was at all dramatic; the recent Toyota problem

is only deadly due to the misapplication of the PC-style "soft power button"

concept to a safety critical system. This is compounded by the use of a

non-standard control interface in an environment that is otherwise highly

standardized - that very standardization is a "key" safety feature.



Home-made dashboards with non-standard layouts and pushbutton ignition

switches are common in motor racing, and a simple, robust solution was

implemented decades ago - all race cars are required to have a *mechanical*

switch which cuts power to all drive-train systems, with standard color,

labeling and placement.



Perhaps in future cars with ignition buttons like this Toyota, or software

controlled drive-trains like in a hybrid, there could be a mandatory

standard requiring a hard-wired engine cutoff knob on the right hand side of

the steering column, thus implementing the UI everyone (who doesn't drive a

Saab) is familiar with?



Also ... I would have expected that the US federal "PRND21" standard for

automatic transmission controls would require that a car could always be

freely shifted from D or R to N to guard against just this circumstance ...

any US auto engineers available to comment?



* For Lindsay Marshall's amusement: one in Tyne Tunnel at rush hour, when it

was used by the A1.



------------------------------



Date: Thu, 4 Feb 2010 23:27:06 -0600

From: "Richard S. Russell" <richardsrussell_at_private>

Subject: Mercedes Benz E Class Commercial



An ad for the Mercedes Benz E Class touts its "safety" features, among which

is that it can "even stop itself if [the driver] becomes distracted".

  http://www.youtube.com/watch?v=3DgjfzHY5-2sM



Right. Because nothing could EVER go wrong with THAT.



Richard S. Russell, 2642 Kendall Av. #2, Madison  WI  53705-3736

608+233-5640 RichardSRussell@private http://richardsrussell.livejournal.com/



Any idiot, upon seeing the first automobile, could easily predict that it

would revolutionize transportation. Only someone with exceptionally keen

insight could have foreseen that it would also revolutionize the sex lives

of teenagers.  Isaac Asimov



------------------------------



Date: Mon, 08 Feb 2010 10:55:58 -0800

From: Geoff Kuenning <geoff_at_private>

Subject: Medical privacy: They never, ever learn



I've been buying some medications through an online pharmacy run by my

health plan.  They seem to have added a new feature: when it's refill time,

an automated system calls you and walks you through reordering.  All in all,

I found it to be a pretty convenient system.



Of course, Federal law requires them to protect my privacy; as I understand

it, they can't legally reveal my prescriptions even to a family member.  So

when they got to the point of telling me what was available for refill, the

automated voice kindly told me that they needed to verify my identity, then

asked me to enter my birthdate and one other super-secret piece of

information... my ZIP code.



Um, yeah.  My wife *definitely* isn't going to know that one.



    Geoff Kuenning   geoff@private   http://www.cs.hmc.edu/~geoff/



Keep trying, and keep the best.



------------------------------



Date: Thu, 11 Feb 2010 17:21:19 -0800

From: Lauren Weinstein <lauren_at_private>

Subject: Who Owns Your PC?



           Who Owns Your PC? New Anti-Piracy Windows 7 Update

               "Phones Home" to Microsoft Every 90 Days



            ( http://lauren.vortex.com/archive/000681.html )

            ( http://lauren.vortex.com/WAT-KB971033.jpg )



Greetings.  Sometimes a seemingly small software update can usher in a whole

new world.  When Microsoft shortly pushes out a Windows 7 update with the

reportedly innocuous title "Update for Microsoft Windows (KB971033)" -- it

will be taking your Windows 7 system where it has never been before.



And it may not be a place where you want to go.



  [Very long but worthy item TRUNCATED for RISKS.  Check out the original.

  PGN]



------------------------------



Date: Thu, 11 Feb 2010 18:29:12 -0500

From: David Magda <dmagda_at_private>

Subject: EMV busted



Seems that the EMV standard has been compromised:



> "Chip and PIN is fundamentally broken," Professor Ross Anderson of

> Cambridge University told ZDNet UK. "Banks and merchants rely on the words

> 'Verified by PIN' on receipts, but they don't mean anything."



	http://news.zdnet.co.uk/security/0,1000000189,40022674,00.htm



More reports:



	http://resources.zdnet.co.uk/articles/0,1000001991,40022669,00.htm

	http://www.telegraph.co.uk/science/science-news/7215920/

	http://www.physorg.com/news185118205.html



Anderson's paper is available:



	http://www.lightbluetouchpaper.org/2010/02/11/chip-and-pin-is-broken/



EMV is called often called "Chip and PIN", as well as "Chip Card" in Canada.



Some financial institutions put a lot of stock in the security of this:



> You are responsible for the full amount of all authorized activity or

> other Transactions resulting from use of the Card or Connect ID and PIN or

> Password by any person, including any entry error or fraudulent or

> worthless deposit at an ABM or other machine. You are responsible for the

> full amount of all unauthorized activity or other Transactions which occur

> before we receive notification that your PIN, Password or Card was lost or

> stolen or that your Connect ID, PIN or Password may have become known to

> an unauthorized person.  On receiving such notice from you we will block

> the Card's, PIN's or Connect ID's ability to access our services and/or

> the use of a Card or the Account.



https://www.tdcanadatrust.com/tdvisa/pdf/select.pdf  (column 9)



In many cases, the banks' (now no longer trust-worthy) logs are the

definitive record:



> Our records will be conclusive proof of use of a Card or the Account or

> electronic services and will be considered your written request to perform

> the Transaction. Even though you may be provided with a Transaction

> receipt, verification or confirmation number, or interim statement by or

> through an ABM or other machine, the following applies to all Transactions

> or other activity on the Account:



> * our acceptance, count and verification of Transactions or deposits

> will be considered correct and binding unless there is an obvious error

> [...]



(Ibid.)



Some are a bit more reasonable, but if your card has been cloned (and put

back in your wallet/purse), you may not notice the problem until too late:



> If someone uses your Visa Card and your PIN or your Visa Account number

> with any other security code to make unauthorized purchases or otherwise

> obtain the benefits of your Visa Card, you will not be responsible for

> those charges provided that you (i) are able to establish to our

> reasonable satisfaction that you have taken reasonable steps to protect

> your Visa Card [...] and (ii) cooperate fully with our

> investigation. [...]



> You are not responsible for unauthorized use of your Visa Card or your

> Visa Account number in transactions in which neither a PIN nor a security

> code is used as the cardholder verification method.



http://www.rbcroyalbank.com/cards/documentation/pdf/ch-agreement.pdf



------------------------------



Date: Fri, 12 Feb 2010 12:49:30 +0000

From: Nick Rothwell <nick_at_private>

Subject: Website glitch drives up parking penalty



A driver's parking penalty fee escalates after the council payment web site

repeatedly reports that she has nothing to pay - because she entered her car

registration number in lower case.



http://www.guardian.co.uk/money/2010/feb/12/southwark-council-car-registration



------------------------------



Date: Sun, 24 Jan 2010 19:00:03 +0000

From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups_at_private>

Subject: The Century Bug will repeat every hundred years, sometimes

  every ten years, because we forget or ignore what we should have learned.



In RISKS-25.89 ("Y2K+10 problem 4: SpamAssassin tags '2010' e-mail as

spammish") M. Burstein wrote that the problem was that "It seems the 'year

date' was hard/hand coded, as opposed to making a comparison to 'today's'

date." and observed that "The SpamAssassin folk have a new version which

corrects this problem."  In fact, they do not.  The replacement rule

incorporates the same problem as before, scheduled to occur simply ten years

further into the future, in January 2020.  This mistake has not been learned

from, let alone corrected.



This is a core problem.  The human race forgets or ignores problems that it

has already solved.  Back in the 1990s I was quietly predicting that by the

year 2010 people would have forgotten all of the issues that had to be dealt

with for the 1999-to-2000 transition, and would have gone back to (say)

using two-digit year numbers.  In part this would have been because people

were erroneously calling it a "Millennium Bug", causing the erroneous

inference that it was something that only ever arose every thousand years

and could be forgotten once the year 2000 was past.  Michael C. Battilana

(www.cloanto.com/usrs/mcb), D. R. Ladd (writing in the letters page of New

Scientist on 1998-03-14), J. R. Stockton, and others besides, all more

loudly than I pointed out that the bug was due every century, and that the

foolish name "Millennium Bug" tended to disguise that.  But in part it would

also have been because we won't have turned to people making the same

mistakes all over again, saying "What you are doing is a bad idea, that cost

the world a lot of time, effort, and money the last time we had to clean up

the mess made.  Don't repeat it.".



And here we are, in 2010, showing that the world has not only not learned

from the mistakes of 10 (and more) years ago, but is even making mistakes of

the same type but with shorter periods than a century.  The developers of

SpamAssassin hit a problem caused by, in effect, ONE-digit year numbers

(with regular expressions that fix the first three digits of the year at

"200"), and rather than learn from the world's experience with the problems

of two-digit year numbers of a mere ten years ago, they simply put the bug

off for another ten years.  It's "Rollover Year" every ten years with

SpamAssassin.



And it's "Rollover Year" every century with others.  It's sad to note that

not only have some parts of the world forgotten the lessons of two-digit

year rollover of a mere ten years ago, and gone back to using two-digit

years, but other parts of the world never really even fixed the problem in

the first place.



Here's one example from personal experience.  Recently, I wrote an NNTP

server and updated an NNTP client.  Following RFC 3977, section 7.3.2, I

made the client use 4-digit years in all "NEWNEWS" commands that it sends.

I also made the server outright reject "NEWNEWS" commands that used 2-digit

years, on the grounds that the RFC 3977 semantics for 2-digit years differed

from the RFC 977 semantics, differed from the Single Unix Specification

semantics, and were quite silly (requiring, as they did, the inference of

year numbers that pre-date by several decades the very existence of

NetNews); and that surely everyone had long since switched to 4-digit years,

it being more than a decade since the specification for 4-digit years in

NNTP (which has been around since IETF draft specifications of the 1990s)

was invented and (supposedly, given that IETF standardization is supposed to

follow practice) put into practice.



I was quite saddened to discover in testing that the world of NNTP simply

ignored the Century Bug completely, and largely ignores RFC 3977 too.  I

have yet to find in production use (albeit that I've not finished testing)

an NNTP client that sends anything other than 2-digit years with the

"NEWNEWS" (and "NEWGROUPS") command, despite the strong recommendation in

RFC 3977 to the contrary, and I have yet to find an NNTP server (other than

my own) that actually recognizes 4-digit year numbers when sent, despite the

outright requirement in RFC 3977 for supporting this.



I haven't tested, but I strongly suspect that no-one even implements the RFC

3977 semantics for inferring four-digit years from two-digit ones, and the

world still implements the RFC 977 semantics, which date from 1986 and

mandate (for example) protocol commands as daft as asking for the NetNews

articles from the year 1961.  (The RFC 3977 changes to those semantics make

things yet dafter, mandating protocol commands as daft as asking for the

NetNews articles from the year 1912, and which introduce a new problem of

jitter resulting from poor implementations on the 31st of December and the

1st of January every year.)



I'm sure that RISKS readers can produce similar experiences in other fields.

So WHY haven't we learned the lessons here?  Why are people, only a mere ten

years on, forgetting the problem entirely and going back to employing

two-digit years?  Why are people even creating and perpetuating new

ONE-digit year rollover problems, that they then had to deal with this year,

and will even have to deal with again a few years from now?



JosephKK, in RISKS 25.85, on a different subject, touched upon one of what

is almost certainly many reasons.  Xe is right.  Current computer

programming courses are inadequate in several areas which are perennial

RISKS staple topics: bad handling of personal names; bad handling of dates,

times, and timezones; and bad handling of geographic locations.  I did a

quick review of a couple of IT textbooks at the time of RISKS 25.85 but

didn't turn up anything that explained the common IT errors to avoid with

personal names.  It would be interesting to hear from RISKS' resident book

reviewer, M. Slade, or anyone else, how many IT textbooks he has encountered

that explain, for example, how it doesn't match reality to design database

schemata (or laws!) specifying "Christian name" and "Surname" fields that

hold one, capitalized, word each; how many books explain that there is an

inherent ambiguity in a timestamp that doesn't include, or have implicit in

its specification, a timezone; and how many books explain that there are

practices that the world discovered, from the 1999-to-2000 transition, to be

bad, and that it is simple foolishness to repeat them.  How much of the

experience that we've gained with doing simple, everyday, things with

computers in the wrong ways, over and over again (as past issues of RISKS

will attest), have we written down, published, and taught, for the benefits

of those who will come after us?



On the subject of not learning lessons from situations that we've already

experienced years before, here's a final something to think about in

relation to the recent RISKS discussion of synthetic engine noise for

otherwise nearly-silent cars (Gezelter, RISKS 25.88; Strickler, RISKS 25.90;

and others): Look up and consider the decades-long legal battle in the

U.K. (and elsewhere) over the requirement for and use of the humble bicycle

bell.



------------------------------



Date: Thu, 4 Feb 2010 14:43:08 -0500

From: Jeremy Epstein <jeremy.j.epstein_at_private>

Subject: Making the grade or changing the grade?



Montgomery County Maryland public schools have learned that students

apparently installed keyloggers on teachers' computers, then used the

passwords they captured to log in and change their grades.  Besides

disciplining the students, they've given teachers two (ineffective)

instructions: to check grades, and to change their passwords.  The first is

ineffective because most teachers enter grades directly into the system, and

don't have hardcopies of the assigned grades to compare against.  (According

to the reports, there's an audit log, but no indication whether teachers are

being sent copies of their portions of the log to examine for anomalies.)

Changing the passwords is ineffective, of course, unless they're confidence

the keyloggers are cleaned up....



Source:

http://www.washingtonpost.com/wp-dyn/content/article/2010/01/28/AR2010012803494.html

http://www.washingtonpost.com/wp-dyn/content/article/2010/01/29/AR2010012902352.html

http://voices.washingtonpost.com/answer-sheet/montgomery-county-public-schoo/mcps-orders-password-changes-a.html?hpid=newswell



The RISK is quite similar to many other types of systems -- if there's no way

to cross-check data, then data attacks are much harder or even impossible to

detect.  That's true if you have a bank account and don't balance your

checkbook, a grading system if the teacher believes everything on the

screen, or an electronically cast vote.



------------------------------



Date: Thu, 4 Feb 2010 23:36:24 -0500 (EST)

From: danny burstein <dannyb_at_private>

Subject: Phishing Scam Cripples European Emissions Trading



(putting aside the whole issue of whether "cap and trade" and AGW is good,

bad, or indifferent...)



[Speigel Online]



Phishing Scam Cripples European Emissions Trading



Sneaky cyber-thieves have made millions by fraudulently obtaining European

greenhouse gas emissions allowances and reselling them. The scam has

hampered trading of the credits, which are seen as an important tool in

curbing climate change, in several European countries.  ....  According to a

report in the Wednesday edition of the Financial Times Deutschland, hackers

sent e-mails last Thursday to several companies in Europe, Japan and New

Zealand which appeared to originate from the Potsdam-based German Emissions

Trading Authority (DEHSt), part of the EU's Emission Trading System (EU

ETS). Ironically, the e-mail said that the recipient needed to re-register

on the agency's Web site to counter the threat of hacker attacks.



The cyber-thieves then exploited the user data that was entered into their

spoof Web site to transfer emissions allowances to other accounts, mainly in

Denmark and Britain, from which they were quickly resold. The new owners of

the allowances would have assumed that they had acquired them legally.

... The crime has hampered the registering of trades in allowances across a

wide swath of the European Union.

    --------------

rest:

 	http://www.spiegel.de/international/europe/0,1518,675725,00.html



------------------------------



Date: Wed, 10 Feb 2010 12:33:22 -0500

From: Jeremy Epstein <jeremy.j.epstein_at_private>

Subject: Meta-spearphishing



I received the following message today (links removed for obvious

reasons) with a subject line "Russian spear phishing attack against

.mil and .gov employees".  What's interesting is that it's carefully

written (good grammar), explains the real issue with Zeus, references

a real project ("2020 project" which is at DNI) and then provides

links to innocent (but presumably compromised) sites to download a

"fix".  In fact, the first paragraph is taken from a legitimate site:

http://intelfusion.net/wordpress/2010/02/08/russian-spear-phishing-attack-against-mil-and-gov-employees/

and the signature at the bottom is a legitimate researcher/company -

but of course the email didn't come from him, as shown by the email

headers.



This is definitely the best example I've seen of a phish....



>Russian spear phishing attack against .mil and .gov employees

>

>A `relatively large' number of U.S. government and military employees

>are being taken in by a spear phishing attack which delivers a variant

>of the Zeus trojan. The email address is spoofed to appear to be from

>the NSA or InteLink concerning a report by the National Intelligence

>Council named the `2020 Project'. It's purpose is to collect passwords

>and obtain remote access to the infected hosts.

>

>Security Update for Windows 2000/XP/Vista/7 (KB823988)

>

>About this download: A security issue has been identified that could

>allow an attacker to remotely compromise a computer running Microsoft®

>Windows® and gain complete control over it. You can help protect your

>computer by installing this update from Microsoft. After you install this

>item, you may have to restart your computer.

>

>Download:

>http://REMOVEDTHEDOMAIN.org/downloads/winupdate.zip

>or

>http://www.REMOVEDTHEDOMAIN.com/file/tj373l

>

>___________

>Jeffrey Carr is the CEO of GreyLogic, the Founder and Principal Investigator

>of Project Grey Goose, and the author of “Inside Cyber Warfare”.

>EMAILREMOVED_at_private



------------------------------



Date: Wed, 03 Feb 2010 08:01:13 +0800

From: jidanni_at_private

Subject: CAPTCHA with the answer in the ALT text



Hmmm, a accessible CAPTCHA

http://en.wikipedia.org/wiki/CAPTCHA#Accessibility

with ALT text for each letter,

<img alt='0' src="0.gif"><img alt='9' src="9.gif">...

(Seen on http://www.mofnpb.gov.tw/PubOpinionMail.php?cat_id=99)

Well I suppose they aren't giving away the store by putting them

all in one string, but it is still nice for we text browser users.



------------------------------



Date: Mon, 01 Feb 2010 10:53:57 +0000

From: Andy Piper <andy_at_private>

Subject: Re: GPS Control Software Glitch: NANU Issued (PGN, RISKS-25.93)



 > Mostly affects military users, but also implications for some civilians.



Good old RISKS!



My old TomTom Go 300 has been having trouble telling which road I am on for

the last couple of weeks. Usually it's out by about 20 yards - enough that

sometimes it gets the road right and sometimes wrong. I thought maybe it was

a hardware fault, but now I am not so sure.



How long until we have a flurry of new SatNav-got-it-wrong related posts?



------------------------------



Date: Sat, 13 Feb 2010 16:57:07 -0400

From: Bob Bramwell <bob_at_private>

Subject: Re: Unsearchable Stores (Brader, RISKS-25.92)



  There's no way to enter an apostrophe on the GPS. (quoting John Varela)



Equally irritating is the inability to search for names which contain

digits on my iPod Classic.  Since I have a large number of classical

music tracks with titles along the lines of:

       BWV 198: Lass Fürstin, Lass Noch Einen Strahl

this makes life unnecessary awkward.



The risk, I suppose, is that next time I'll look for a product that provides

a better user interface - assuming such a thing exists.



Bob Bramwell +1 902 531 2289

		

------------------------------		



Date: Thu, 29 May 2008 07:53:46 -0900

From: RISKS-request_at_private

Subject: Abridged info on RISKS (comp.risks)



 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.

=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)

 if possible and convenient for you.   The mailman Web interface can

 be used directly to subscribe and unsubscribe:

   http://lists.csl.sri.com/mailman/listinfo/risks

 Alternatively, to subscribe or unsubscribe via e-mail to mailman

 your FROM: address, send a message to

   risks-request_at_private

 containing only the one-word text subscribe or unsubscribe.  You may

 also specify a different receiving address: subscribe address= ... .

 You may short-circuit that process by sending directly to either

   risks-subscribe_at_private or risks-unsubscribe_at_private

 depending on which action is to be taken.



 Subscription and unsubscription requests require that you reply to a

 confirmation message sent to the subscribing mail address.  Instructions

 are included in the confirmation message.  Each issue of RISKS that you

 receive contains information on how to post, unsubscribe, etc.



=> The complete INFO file (submissions, default disclaimers, archive sites,

 copyright policy, etc.) is online.

   <http://www.CSL.sri.com/risksinfo.html>

 The full info file may appear now and then in RISKS issues.

 *** Contributors are assumed to have read the full info file for guidelines.



=> .UK users should contact <Lindsay.Marshall_at_private>.

=> SPAM challenge-responses will not be honored.  Instead, use an alternative

 address from which you NEVER send mail!

=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.

 *** NOTE: Including the string "notsp" at the beginning or end of the subject

 *** line will be very helpful in separating real contributions from spam.

 *** This attention-string may change, so watch this space now and then.

=> ARCHIVES: ftp://ftp.sri.com/risks for current volume

     or ftp://ftp.sri.com/VL/risks for previous VoLume

 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive

 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.

   Lindsay has also added to the Newcastle catless site a palmtop version

   of the most recent RISKS issue and a WAP version that works for many but

   not all telephones: http://catless.ncl.ac.uk/w/r

 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .

==> PGN's comprehensive historical Illustrative Risks summary of one liners:

    <http://www.csl.sri.com/illustrative.html> for browsing,

    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing

==> Special Offer to Join ACM for readers of the ACM RISKS Forum:

    <http://www.acm.org/joinacm1>



------------------------------



End of RISKS-FORUM Digest 25.94

************************



Received on Sun Feb 14 2010 - 14:40:15 PST





]]>
Sun, 14 Feb 2010 14:40:15 PST
RISKS List Owner



http://lists.jammed.com/RISKS/2009/12/0001.html






From: RISKS List Owner <risko_at_private>




Date: Tue, 15 Dec 2009 11:20:25 PST






RISKS-LIST: Risks-Forum Digest  Tuesday 15 December 2009  Volume 25 : Issue 87



ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy



***** See last item for further information, disclaimers, caveats, etc. *****

This issue is archived at <http://www.risks.org> as

  <http://catless.ncl.ac.uk/Risks/25.87.html>

The current issue can be found at

  <http://www.csl.sri.com/users/risko/risks.txt>



  Contents:

A Deluge of Data Shapes a New Era in Computing (John Markoff via PGN)

Forensics, COFEE, and Decaf (PGN)

Encryption Considered Harmful (Curt Sampson)

Toronto subway line closed for 6 hours after tunnel pierced by gas line crew

  (Tony Harminc)

Happy Holidays? (Zach Tudor, Jeremy Epstein)

Re: The Joy of satellite navigation failures (Michael D. Sullivan)

Re: Teleportation via Skyhook (Jonathan de Boyne Pollard)

Re: Android Mythbusters (Phil Colbourn)

Re: Toyota uncontrolled acceleration (Jeremy Epstein, Graham Reed)

Abridged info on RISKS (comp.risks)



----------------------------------------------------------------------



Date: Tue, 15 Dec 2009 7:17:12 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: A Deluge of Data Shapes a New Era in Computing



John Markoff, Science Times, *The New York Times*, 15 Dec 2009



A superb article by John Markoff this morning pays a wonderful and

well-deserved tribute to Jim Gray's notion of a "fourth paradigm" -- that

computing is fundamentally transforming the practice of science.  (The first

three paradigms are experimental, theoretical, and computational.)  "In

essence, computational power created computational science, which produced

the overwhelming flow of data, which now requires a computing change.  It is

a positive feedback look in which the data stream becomes the data flood and

sculptures a new computing landscape."



I love the quote from John Wilbanks: ``I Have Seen the Paradigm Shift,

and It Is Us'' (his chapter title).



Please read Markoff's pithy article.  I still read *The NYT* in hardcopy,

and believe in supporting the future of real news, analysis, and thoughtful

writing.  Thus, I try not to exceed fair use guidelines in RISKS.  However,

you can find the article with minimal browsing.  PGN



------------------------------



Date: Tue, 15 Dec 2009 6:41:52 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Forensics, COFEE, and Decaf



COFEE (Computer Online Forensic Evidence Extractor) has been distributed

through Interpol only to law enforcement agencies for the past 2.5 years.

COFEE consists of about 150 tools used to collect digital evidence at crime

scenes.  (``Microsoft has been pouring free COFEE to law enforcement

officers since at least mid 2007.'')  However, it has recently been

accidently released more widely.  Perhaps not surprisingly, a subverting

program called Decaf has now been released that monitors Windows systems for

the presence of COFEE, and automagically executes some countermeasures that

effectively dilute the benefits of COFEE (but apparently without any nasty

side-effects to the system).  [Source: Dan Goodin, *The Register*, 14 Dec

2009; PGN-ed, with thanks to Jeremy Epstein for spotting this item.]

http://www.theregister.co.uk/2009/12/14/microsoft_cofee_vs_decaf/



An excerpt from *The Register* article:



  ``We want to promote a healthy unrestricted free flow of internet traffic

  and show why law enforcement should not solely rely on Microsoft to

  automate their intelligent evidence finding,'' one of the two hackers

  behind Decaf told *The Register* in explaining the objective of the

  project.



------------------------------



Date: Tue, 15 Dec 2009 13:05:08 +0900

From: Curt Sampson <cjs_at_private>

Subject: Encryption Considered Harmful



In RISKS-25.86, under the subject "Massive New UK Internet Wiretapping Plan

Announced," Lauren Weinstein <pfir_at_private> writes,



> [Notes on a British ISP perpetrating a man-in-the-middle attack on their

> customers.]

>

> Notably, the answer to these dilemmas is contained in a single word, which

> you've seen me use many times before: *encrypt*!



Unfortunately, this is just wrong.  That single word is not the answer, and

in fact is an even worse problem in disguise.



We must be careful about giving out very dangerous advice.



> In fact, a spokesman related to the new Virgin ISP spying project

> notes that, "encryption of the data packet would defeat us."



It will only do so until they get someone just a wee bit smarter to use

attack methods that have been available in open source software for some

time [1,2].  What they'll do is this:



Alice (the user at this ISP) will attempt to connect to Bob (some

file-sharing source). But of course, Mallory (the ISP) has control of

every packet flowing between them, and can decide to drop them, forward

them, and even change them.



When Alice connects to "Bob" for the first time, she'll get a notice that

Bob is using a self-signed certificate that she's never seen before, and

would she like to accept it or not. She'll say yes, a little lock icon

will appear, and she'll exchange sensitive material in the comfort that

it's all being encrypted.



And it is. Twice. Unfortunately, it was Mallory who generated and sent

her "Bob's" certificate, set up his own encrypted connection to Bob

(pretending to be Alice), and who is now proxying that connection.

(There's a nice little picture of this at [3].) When Alice sends an

encrypted packet to "Bob," Mallory decrypts it, examines the content,

changes it as he wishes, re-encrypts it, and sends it on to the real

Bob.



In short, encryption without authentication is not only useless against

an attacker who forwards your packets, but is in fact dangerous, because

it looks as if you're safe when you're not.



This is the very reason that recent versions of Firefox have made it

much more difficult to accept self-signed certificates. Johnathan

Nightingale, in [4], mentions that your ISP is not the only danger here;

there are open source, point-and-click tools available[1] to attackers

to subvert your router or other hosts on your own network to perform

this same attack.



It is ever more important, now that attackers are heading in on all

sides, that we discourage as much as possible the use of encryption

without authentication.



Unfortunately, this is still widespread, even amongst those who you'd

think would be reasonably savvy about such things. I know far too many

industry professionals who would never think about using unencrypted

telnet to connect to a remote system, but who happily run SSH clients

with "StrictHostKeyChecking off" and blithely accept the credentials of

any remote system for which they don't already have a public key.



1. http://ettercap.sourceforge.net/

2. http://www.pburkholder.com/sysadmin/SSL-mitm/

3. http://www.pburkholder.com/sysadmin/SSL-mitm/webmitm.jpg

4. http://blog.johnath.com/2008/08/05/ssl-question-corner/



Curt Sampson +81 90 7737 2974 http://www.starling-software.com



------------------------------



Date: Mon, 14 Dec 2009 14:18:40 -0500

From: Tony Harminc <tony_at_private>

Subject: Toronto subway line closed for 6 hours after tunnel pierced by

	gas line crew



The computer risks to this story are peripheral, but it strikes me that it's

a classic "category error" of the sort that leads to some of the medical,

aviation, and GPS misadventures we have seen.  [I suppose the computerized

Ontario One Call registry is as close as it gets to being computer-related.]



On November 18 2009, a work crew digging a trench for a natural gas line on

Jackes Avenue discovered that they had broken through into the top of a

Toronto Transit Commission (TTC) subway tunnel. Work was stopped, and the

subway line -- the city's busiest -- was isolated at that point, with

turnbacks splitting the line into two for a six hour period that included

evening rush hour, until emergency structural repairs could be made. There

were no injuries, but thousands of commuters had unplanned long walks or

crowded shuttle bus rides.  Permanent repairs are still ongoing, and work in

progress can be seen from subway trains passing the spot.



The fundamental problem appears to be that the crew thought they were

working on a road, but they were actually digging their trench on a

bridge. The subway line in question was opened in 1954, and originally this

midtown section was in an open cut for several blocks, with sloped grassed

sides, and with minor roads carried over the line on flat bridges with low

railings. Over the subsequent decades, much of the open cut has been covered

over right up to the bridge edges, in some cases with parks, and tennis

courts, in others with various buildings including parking structures and

high rise apartments. In the case of Jackes Avenue, the original distinctive

railings have been removed, though on other streets one or both remain.



While there are disagreements between the TTC and the construction company

engaged by Enbridge, the gas distributor, to work on its pipes, it appears

that the work crew followed accepted procedures for digging a trench on a

road; they obtained a city permit for the dig, contacted Ontario One Call,

the province-wide agency run by various utilities (gas, electrical, phone,

etc.) to locate underground services, and cut both sides of a trench using a

concrete saw.  Evidently they were removing some of the sawed concrete at

one end when they broke through, and realized they had a problem. The TTC is

not a member of Ontario One Call, and it's not clear if large-scale objects

like subway tunnels and bridges would be expected to be listed with such an

agency.



I have lived in this area for a long time, and saw the covering over of the

subway through the years, and so it is inconceivable to me that anyone could

not know there are bridges there. But to someone not familiar with the area,

there are few visual clues that there's anything different about those bits

of road; perhaps the absence of large trees nearby is the biggest. Even the

characteristic low green railings, while iconic to me, would doubtless have

no special meaning to others, and in any case are no longer there on Jackes

Avenue..



Your favourite mapping website can show you aerial and street views of the

bridge in question, and some of its neighbours. Rather than include

ephemeral URLs, I'm giving nearby street addresses, which I imagine will

last longer. There are also various news sites with maps and diagrams of the

incident, with unknown web lifespans.



* 38 Jackes Avenue, Toronto" (the site of the incident, no railing on

  either side)



* 26 Woodlawn Avenue East, Toronto" (the next bridge south, with an

  original railing on the south side only, serving no obvious purpose)



* 24 Summerhill Avenue, Toronto" (one further south, with original

  railings on both sides)



* 20 Roxborough Street East, Toronto" (further south, and suddenly it's

  quite obvious this one is a bridge)



Would you dig a hole in a road at any of these sites? Not that last one,

surely. But any of the others? What would it take to change your world view,

once you were thinking it was just another road, and that the locate call

had come back all-clear? The sound of subway trains rumbling underneath? An

unexpected layer of concrete under the paving?  Breaking through and seeing

a train...?



  [Enbridge seems to be entrenched in its endeavors.  But the risks are

  seemingly ENdless, so I thought it might be interesting to include this

  item.  PGN]



------------------------------



Date: Tue, 15 Dec 2009 12:47:50 -0500

From: Zach Tudor <zachary.tudor_at_private>

Subject: Happy Holidays?



A friend is a Senior VP of risk management at Citi.  I e-mailed to tell him

I wouldn't click on the link in this card, especially given the amount of

spear phishing that targets bank (especially Citi Bank) customers.  He

replied that it was the marketing folks that came up with the idea (and he

joked that "you security folks" are so touchy).  I was glad that he at least

knew about it, and that it wasn't a hook!



------------------------------



Date: Tue, 15 Dec 2009 13:09:47 -0500

From: Jeremy Epstein <jeremy.epstein_at_private>

Subject: Happy Holidays?



IEEE sent out something similar for their annual salary survey.  I pointed

out the same thing - they said that the outsourced marketing company they

use required unique URLs for each person.  Amazing how one side of an

organization doesn't know what the other side is doing....



------------------------------



Date: Sun, 29 Nov 2009 01:00:24 -0500

From: "Michael D. Sullivan" <mds_at_private>

Subject: Re: The Joy of satellite navigation failures (Loughran, R-25.85)



Steve Loughran entertainingly takes apart a BMW ad for suggesting that its

GPS will guide the user home, noting issues concerning satellite coverage,

map quality, etc.  One difference between auto makers' built-in GPS

navigators and the ones available from TomTom, Garmin, Magellan, etc., is

that at least some auto makers don't rely solely on GPS satellites for their

navigation systems, but incorporate dead reckoning as well.  I don't know

whether BMW's nav systems do this, but my VW 2005 Touareg's nav system uses

dead reckoning in addition to GPS.  It can correctly track my car's location

to the lowest level of my office building's underground garage and follow it

through underwater tunnels.  It never gets thrown off in urban canyons or in

heavily tree-shaded rural areas where GPS reception gets a bit dicey.  So

for a carmaker's built-in navigation system, the actual location of the car

shouldn't be a serious issue, if the carmaker has taken advantage of the

data available in the in-car electronic environment.



Maps, on the other hand, are a problem.  Many mapping data suppliers have

included intentional errors, usually of a harmless nature, that give their

products "creativity" and thus provide copyright protection.  Sometimes,

these errors can be serious, however, if the driver does not exhibit

appropriate skepticism.  Near my home there is a road that dead-ends at a

homeowner's driveway.  Some online and GPS maps, however, show the road

continuing through the driveway and right past the home through a forest to

a public street a few hundred feet away.  If somebody decided to rely on

that map late at night, a serious accident could occur.  Likewise, in

another nearby location some online and GPS maps show a road continuing

through between two other roads when in reality that lot contains only a

footpath; the road restarts with the same name on the other side.  I've also

run into a situation where my car's nav system told me that a footbridge was

a road.  And, of course, even with updated discs no nav system is going to

have totally current mapping data as roads expand and reroute.  I just drove

between DC and Philly, and the road construction on I-95 left even the

August 2009 update disc behind.



The key to the BMW ad is that the GPS will "guide" you home.  It will not

unerringly direct you.  "Guidance" inherently needs to be evaluated as to

whether it is reasonable and correct.



I don't think Steve would want nav systems to provide all of the disclaimers

he amusingly asserts with respect to the ads, at least on an ongoing basis.

It would be hard to pay enough attention to pick the wheat from the chaff if

the nav system were to say, "Unless you are in Scotland or the Lake District

or Alaska or woodlands or canyonlands or an urban area, or you don't have

the latest mapping disc, or any number of situations where this system's

guidance is questionable, in 400 meters, bear right," . . . and thereafter,

"Take next right turn, unless you meet the criteria stated previously, in

which case you are on your own."



------------------------------



Date: Wed, 02 Dec 2009 05:33:55 +0000

From: Jonathan de Boyne Pollard <J.deBoynePollard_at_private>

Subject: Re: Teleportation via Skyhook (Wood, RISKS 25.85)



"What surprises me is that [Skyhook Wireless doesn't] appear to have a

fallback to IP geolocation." says Charles Wood.  I expect that that is

because the people at Skyhook Wireless read RISKS.  I pointed out the

problems of IP address geolocation five years ago (almost to the day), in

RISKS-23.63, mentioning then that they are well known, but less well known

than they should be.  To recap: the data are either coarse-grained, or

subject to IP address churn; and in either case they eventually become dated

to the point of uselessness.



To emphasize these points, I report the following: I today ran the DNS query

against "clientcontinent.cr.yp.to.", that I mentioned in RISKS-23.63, from a

computer in Europe.  Dan Bernstein's database, still based upon the 2001

IANA IPv4 address space allocation list, reports that the machine is in

North America.



"The example in the teleportation post would very easily have been solved by

use of IP geolocation", says Charles Wood.  No, no, and no again.  I

strongly emphasize that IP addresses are *not* a reliable mechanism for

determining the geographical location of a machine.  Posit that I, with the

computer in Europe mentioned above, were in the same situation as M. Wood of

having no Skyhook Wireless mapping information available. Had Skyhook

Wireless fallen back to IP address geolocation using (say) the same source

data as Dan Bernstein, Skyhook Wireless would have placed me on entirely the

wrong continent.  Even if its data were more recent, the degree to which

Bernstein's database is now dated, and was dated even back at the time of

RISKS-23.63, shows how quickly the data quality of *any* such IP address

geolocation dataset erodes over time.



There's a fairly simple point here, and yet it's one that I regularly

observe people missing again and again.  IP addresses, postcodes, and the

like, were not invented to directly encode geographical locations.  That is,

simply, not their purpose.  IP addresses are used for routing network

traffic around Internet, and postcodes are used by postal services to route

mail through a postal system.  They are designed for *those* purposes.  The

"locations" that they do encode are locations in the topographies of

Internet network connections and of postal system sorting and delivery

systems, which are often *very* different to actual geography.  Any

correspondence that they might have to actual geographical locations should

be considered fortunate, and unreliable.  Don't expect postcodes to always

work in navigation systems.  Don't expect your computer's IP address(es) to

identify what country, or even what continent, you are in.  They weren't

designed for that purpose, aren't maintained and updated for that purpose,

and often produce highly erroneous results when (mis-)used for that purpose.



So one should not, really, be surprised at Skyhook Wireless avoiding this

well-known (but still, five years on, not well-known enough, it seems) error

in this instance.



------------------------------



Date: Sun, 29 Nov 2009 16:50:46 +1100

From: phil colbourn <philcolbourn_at_private>

Subject: Re: Android Mythbusters (RISKS-25.85)



> Executive summary: Android is a screwed, hard-coded, non-portable

  abomination.



I'm not sure the Executive summary cited in RISKS-25.85 is justifiable:



1. Android is open source although Google do add closed source applications.

2. It has been ported to many devices and even PCs, laptops and netbooks.

3. In order to keep boot times low and software base minimal, it is expected

   that the OS be customised for the target device - it is not designed as a

   general purpose OS in the same way that, say, Ubuntu is. It is an

   embedded OS.

4. People are free to port 'normal' Linux to their device if they choose to.

5. Design choices about what aspects of the Linux kernel or GNU libraries

   are implemented is a design choice. I suspect that the designers wanted

   to reduce the attack surface.



I think the biggest issue is the lack of open source Google Apps, which

includes MarketPlace.



The key point is that Android OS is Open Source - do with it as you please.



------------------------------



Date: Sat, 28 Nov 2009 20:38:09 -0500

From: Jeremy Epstein <jeremy.j.epstein_at_private>

Subject: Re: Toyota uncontrolled acceleration (Lesher, RISKS-25.82)



JC Cantrell wrote:

>Well, that is why I buy a manual transmission. When that clutch is in, I

>KNOW I can stop the car...



Well, at least so long as your clutch is a physical device, and not a "fly

by wire".  I don't know if such things exist, but I can think of many

reasons why a fly-by-wire clutch would be a good thing - maybe software

could reduce the opportunities for stalling, or switching into the wrong

gear, or burning it out by riding the clutch.  And once that happens, then

how long before the fly-by-wire clutch decides you really shouldn't be going

into neutral at highway speeds, so it refuses to engage... and silently

stops the fail-safe mechanism Cantrell describes.



--Jeremy



------------------------------



Date: Sat, 28 Nov 2009 18:47:19 -0500

From: Graham Reed <greed_at_private>

Subject: Re: Toyota uncontrolled acceleration (Cantrell, RISKS-25.85)



On Mon, 9 Nov 2009 12:41:33 -0800 (PST) JC Cantrell <jccant_at_private> wrote:

> Well, that is why I buy a manual transmission. When that clutch is in, I

> KNOW I can stop the car...



This is getting away from the computing RISKS, but I have had clutch failure

on manual vehicles.  This failure mode leaves the controls unable to

disengage the clutch, which means the engine cannot be decoupled from the

transmission.



I use generic terms because one such incident was on a motorcycle with a

hydraulic clutch.  I had a cooling system fault, and was approaching

boil-over in a traffic jam.  Deciding the hard shoulder was better than a

full breakdown in the traffic lane, I began my maneuver.  Only to find that

the clutch lever had no resistance--the hydraulic fluid was too hot, and it

had boiled.  (The clutch fluid was nearly due for changing at the time, and

contaminants in it were not helping the situation.)



Fortunately, I've practiced shifting gears without the clutch, and was able

to gear down enough to get off the road.  Getting into neutral wasn't much

more difficult.  I even used the kill switch to stop the motor, even though

there was nothing wrong with the ignition key circuit; I was well into

emergency procedures, and forgetting "normal" operating modes.



I've also had cable clutches fail to disengage due to thermal expansion.



Still, with a true manual, you can always get to neutral with the shift

lever, even without a clutch.



It's the more expensive stuff, like those "flappy paddle" boxes, that adds

automatic gearbox failure modes (in the control system and actuators) to the

existing failure modes of a manual box (broken shift forks, dogs, splines,

and so on) and clutch (hydraulic or spring failure).



------------------------------



Date: Thu, 29 May 2008 07:53:46 -0900

From: RISKS-request_at_private

Subject: Abridged info on RISKS (comp.risks)



 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.

=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)

 if possible and convenient for you.   The mailman Web interface can

 be used directly to subscribe and unsubscribe:

   http://lists.csl.sri.com/mailman/listinfo/risks

 Alternatively, to subscribe or unsubscribe via e-mail to mailman

 your FROM: address, send a message to

   risks-request_at_private

 containing only the one-word text subscribe or unsubscribe.  You may

 also specify a different receiving address: subscribe address= ... .

 You may short-circuit that process by sending directly to either

   risks-subscribe_at_private or risks-unsubscribe_at_private

 depending on which action is to be taken.



 Subscription and unsubscription requests require that you reply to a

 confirmation message sent to the subscribing mail address.  Instructions

 are included in the confirmation message.  Each issue of RISKS that you

 receive contains information on how to post, unsubscribe, etc.



=> The complete INFO file (submissions, default disclaimers, archive sites,

 copyright policy, etc.) is online.

   <http://www.CSL.sri.com/risksinfo.html>

 The full info file may appear now and then in RISKS issues.

 *** Contributors are assumed to have read the full info file for guidelines.



=> .UK users should contact <Lindsay.Marshall_at_private>.

=> SPAM challenge-responses will not be honored.  Instead, use an alternative

 address from which you NEVER send mail!

=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.

 *** NOTE: Including the string "notsp" at the beginning or end of the subject

 *** line will be very helpful in separating real contributions from spam.

 *** This attention-string may change, so watch this space now and then.

=> ARCHIVES: ftp://ftp.sri.com/risks for current volume

     or ftp://ftp.sri.com/VL/risks for previous VoLume

 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive

 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.

   Lindsay has also added to the Newcastle catless site a palmtop version

   of the most recent RISKS issue and a WAP version that works for many but

   not all telephones: http://catless.ncl.ac.uk/w/r

 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .

==> PGN's comprehensive historical Illustrative Risks summary of one liners:

    <http://www.csl.sri.com/illustrative.html> for browsing,

    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing

==> Special Offer to Join ACM for readers of the ACM RISKS Forum:

    <http://www.acm.org/joinacm1>



------------------------------



End of RISKS-FORUM Digest 25.87

************************



Received on Tue Dec 15 2009 - 11:20:25 PST





]]>
Tue, 15 Dec 2009 11:20:25 PST
RISKS List Owner



http://lists.jammed.com/RISKS/2010/01/0004.html






From: RISKS List Owner <risko_at_private>




Date: Fri, 29 Jan 2010 11:07:25 PST






RISKS-LIST: Risks-Forum Digest  Friday 29 January 2010  Volume 25 : Issue 93



ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy



***** See last item for further information, disclaimers, caveats, etc. *****

This issue is archived at <http://www.risks.org> as

  <http://catless.ncl.ac.uk/Risks/25.93.html>

The current issue can be found at

  <http://www.csl.sri.com/users/risko/risks.txt>



  Contents:

Doug Maughan's CACM article & Roadmap for Cybersecurity Research (PGN)

UI fix freezes NYSE, affects 975 stocks (T Byfield)

False positives galore in SARs (Geoff Kuenning)

DC Metro - only kills average of 1 customer each 3 years (Paul Robinson)

GPS Control Software Glitch: NANU Issued (PGN)

How Not to Design Authentication (Alexander Klimov)

Radiation Offers New Cures, and Ways to Do Harm (David Hollman)

Warning: Your Cell Phone May Be Hazardous to Your Health

  (Christopher Ketcham via PGN)

Driver watching laptop movie kills woman (Walter Roberson)

It depends on which bus you take (Paul Robinson)

Driving and walking through buildings (Pete Kaiser)

Re: Teleportation via Skyhook (Tony Lima)

Re: Extending TCP/IP into space (Mark Jackson)

Abridged info on RISKS (comp.risks)



----------------------------------------------------------------------



Date: Thu, 28 Jan 2010 16:19:18 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Doug Maughan's CACM article & Roadmap for Cybersecurity Research



Doug Maughan's Inside Risks column on the Cybersecurity Roadmap and the

underlying security issues will appear in the Feb 2010 *CACM*.  An html

version is now up on my Inside Risks website:



  Douglas Maughan,

  The Need for a National Cybersecurity Research and Development Agenda

  *Communications of the ACM*, February 2010

  http://www.csl.sri.com/neumann/insiderisks08.html#220



It includes hotlinks to the roadmap and various other relevant documents on

the Department of Homeland Security Science and Technology cybersecurity

website.  (The roadmap document is currently the first item in the list.)



   http://www.cyber.st.dhs.gov/documents.html



------------------------------



Date: Thu, 28 Jan 2010 01:11:45 -0500

From: t byfield <tbyfield_at_private>

Subject: UI fix freezes NYSE, affects 975 stocks



Ars Technica reports (Jon Stokes, "How a stray mouse click choked the NYSE &

cost a bank $150K," 27 Jan 2010):



  On November 14, 2007 at 3:20pm one of Credit Suisse's trading algorithms

  suddenly went haywire, and, in a few moments, sent hundreds of thousands

  of bogus requests to the exchange. This sudden surge of requests, which

  were cancellations for a large batch of orders that the machine had never

  actually sent out, acted like a denial-of-service attack on some parts of

  the New York Stock Exchange. The messages clogged the tubes and caused

  parts of the exchange to freeze up, affecting trading in 975 stocks.



The article goes on to blame "a programmer [who] took it upon himself to

unilaterally improve [the Credit Suisse program] by adding a new user input

feature," which lacked "feedback and 'forgiveness'" and a lack of testing.



  On November 14, a few seconds after 3:20, a trader put a number in the box

  and then double-clicked the "up" arrow. This double-click was interpreted

  by SmartWB as two separate clicks, so the system dutifully sent out a

  second batch of cancel/replace orders in addition to the batch that was

  intended by the trader.  This sudden flood of cancel/replace orders, half

  of which were requesting cancellation of orders that had never been sent,

  overwhelmed the system and backed up five of the posts on the NYSE trading

  floor.



Without endorsing the programmer's impromptu improvement, it's fair to ask

why a "flood" of bogus orders from a single bank would overwhelm the system.



http://arstechnica.com/business/news/2010/01/how-a-stray-mouse-click-choked-the-nyse-cost-a-bank-150k.ars



------------------------------



Date: Thu, 28 Jan 2010 23:05:14 -0800

From: Geoff Kuenning <geoff_at_private>

Subject: False positives galore in SARs



I went to a talk today by a rather clueless Los Angeles company who is

partnering with the Washington, DC, police in a number of efforts, many

based on web-scraping.  One of the things they're proud of is a

(non-scraping) system that automatically delivers SARs ("Suspicious Activity

Reports") to interested parties.  For example, if an SAR has a location

that's within 1000 feet of a university, they send a text to everybody's

cellphone.  They're at least a little bit clever; for example, for a big

school they'll only contact the students living in the dorm(s) nearest the

incident.



OK, what's an SAR?  Just about anything.  If a little old lady sees a

"suspicious man on the corner" (e.g., waiting for a taxi) and calls it in,

that's an SAR.  Obviously, in these fear-everything days, any forgotten

package becomes an SAR-worthy possible bomb.  About 300-400 SARs go out per

day, though to be fair not every SAR goes to every person.



When queried, they informed us that of course most SARs are bogus, but

"three or four per year" are valid.  Hmmm...300*365/4 = 27,375.  That's a

pretty impressive false-positive rate.  They don't seem to see a problem

with crying "wolf" that often.  And one of their examples of a "true"

positive was a political protest by Greenpeace, involving a

not-very-dangerous stuffed polar bear.



Nor do they seem to have thought about security and privacy issues.  How do

they protect their database of who lives in which dorm?  Questions were cut

off before I got a chance to ask that one, but I'm not optimistic.



The RISK here is that everybody (developers and police) is so in love with

the shiny technology that nobody stops to notice that the emperor has no

clothes.



Geoff Kuenning   geoff@private   http://www.cs.hmc.edu/~geoff/



  [If you *can't* measure it, it's not science.

  Robert A. Heinlein, "The Door Into Summer"]



    [If you think you *can* measure it, something is probably wrong anyway.

    Peter G. Neumann, The ACM Risks Forum

    (Check your model and your assumptions at the door, eat a

    Heisenburger, and beware of many other risky challenges.)]



------------------------------



Date: Fri, 22 Jan 2010 00:18:27 -0800 (PST)

From: Paul Robinson <rfc1394_at_private>

Subject: DC Metro - only kills average of 1 customer each 3 years



The Washington Metropolitan Transportation Authority, which runs the

metrorail system in Washington, DC, has had exactly two accidents that

killed customers in the 34 years it has been operating.  From the system's

opening in 1976 until 1982, there were no passenger fatalities.



The first accident occurred when a derailed train was backed up, but the

other half of the train had also derailed, crashing it into a tunnel

abutment and killing 3 passengers.  The accident happened on January 13,

1982, at the same time as the Air Florida Flight 90 crashed into the 14th

Street Bridge.



The second accident where 9 people were killed was in June, so if you

average this, chances are either Metro won't kill someone until 2012, or,

since each time they do have an accident, they kill 3 times as many, we

could expect that since it was 6 years for the first accident, then 17 more

for the second, that sometime around 2055, another Metrorail accident will

kill 22 people!



And it's this sort of estimation that actuaries use to figure out insurance

rates. Given enough incidents you can do a pretty good job of figuring out

how often you'll have claims.



Actually, you're more likely to be killed on Metro if you're an employee

than a customer, based on the number of employee deaths they've had.  This

also brings up a question: is the low number of customer deaths and long

times between accidents a result of luck or some factors such as the

equipment as designed being relatively safe?



------------------------------



Date: Thu, 28 Jan 2010 16:06:38 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: GPS Control Software Glitch: NANU Issued



Mostly affects military users, but also implications for some civilians.

[TNX to Paul Saffo for spotting this one.  (Robin Williams' Nanu-Nanu

references probably unfamiliar to many readers.)  PGN-ed]



``Moving Three GPS Satellites into New Orbits will have a profound effect on

GPS capabilities for all civil, commercial, and military users worldwide.''

The GPS AEP Command and Control operational software update enables new

capabilities ... but requires absolute compliance with the published GPS

Interface Control Document (ICD).  Some of the new features that are

incorporated work only with authorized military receivers that have

successfully passed security tests.  However the live introduction of the

new functions is causing problems wherein some of these receivers are

intermittently not tracking Y-code, and non-compliant civilian receivers are

also reporting continuing problems.  Corrective action could encompass

either the Air Force rolling back the update or revising its software, or

the manufacturers modifying GPS software within the receivers to be totally

compliant with the ICD.



January 21, 2010

http://www.gpsworld.com/gnss-system/news/gps-control-software-glitch-nanu-issued-9414

http://www.gpsworld.com/gnss-system/news/new-243-gps-configuration-will-increase-accuracy-9368



------------------------------



Date: Wed, 27 Jan 2010 11:32:06 +0200

From: Alexander Klimov <alserkli_at_private>

Subject: How Not to Design Authentication



"Verified by Visa and MasterCard SecureCode:

 or, How Not to Design Authentication"

by Steven J. Murdoch and Ross Anderson

<http://www.cl.cam.ac.uk/~rja14/Papers/fc10vbvsecurecode.pdf>:



  Banks worldwide are starting to authenticate online card transactions

  using the `3-D Secure' protocol, which is branded as Verified by Visa and

  MasterCard SecureCode. This has been partly driven by the sharp increase

  in online fraud that followed the deployment of EMV smart cards for

  cardholder- present payments in Europe and elsewhere. 3-D Secure has so

  far escaped academic scrutiny; yet it might be a textbook example of how

  not to design an authentication protocol.  It ignores good design

  principles and has significant vulnerabilities, some of which are already

  being exploited.  Also, it provides a fascinating lesson in security

  economics.  While other single sign-on schemes such as OpenID, InfoCard

  and Liberty came up with decent technology they got the economics wrong,

  and their schemes have not been adopted.  3-D Secure has lousy technology,

  but got the economics right (at least for banks and merchants); it now

  boasts hundreds of millions of accounts. We suggest a path towards more

  robust authentication that is technologically sound and where the

  economics would work for banks, merchants and customers -- given a gentle

  regulatory nudge.



------------------------------



Date: Wed, 27 Jan 2010 09:47:25 +0000

From: David Hollman <dah8_at_private>

Subject: Radiation Offers New Cures, and Ways to Do Harm



Radiation Offers New Cures, and Ways to Do Harm

The New York Times, January 23, 2010



http://www.nytimes.com/2010/01/24/health/24radiation.html



This article goes into some detail about several failures in radiation

treatments which lead to severe injury and deaths in patients.

Although there was substantial human error involved, it seems that in

some cases computer crashes and lack of failsafe functionality were at

least contributing causes.



In one example, a crash of the controlling computer led a technician

to mistakenly believe that instructions to properly restrict the

amount of radiation received were saved, when in fact they were not.

This was then compounded by additional error as operators failed to

manually check whether the settings were correct. The patient was then

massively over-radiated on several occasions.



I wonder if the general flakiness in personal computers that we are

all used to results in an attitude that accepts such things as normal

and acceptable, even in people who should have been trained to know

better, and possibly even product designers and managers.  In this

example, such an attitude would probably have worse consequences than

the actual technical fault in the equipment.



------------------------------



Date: Thu, 28 Jan 2010 16:15:45 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Warning: Your Cell Phone May Be Hazardous to Your Health



  Ever worry that that gadget you spend hours holding next to your head

  might be damaging your brain? Well, the evidence is starting to pour in,

  and it's not pretty. So why isn't anyone in America doing anything about

  it?



[Source: Christopher Ketcham, February 2010 issue of *GQ*, PGN-ed]

http://www.gq.com/cars-gear/gear-and-gadgets/201002/warning-cell-phone-radiation



------------------------------



Date: Thu, 28 Jan 2010 13:05:22 -0600

From: "Walter Roberson" <roberson_at_private>

Subject: Driver watching laptop movie kills woman



[The article emphasizes that it was a porn movie being watched, but it seems

to me that the result could easily have been the same for many other genres

-- WDR]



State police say a truck driver was watching pornographic movies on his

laptop computer when his rig struck a disabled car on the New York State

Thruway near Buffalo last month, killing the driver.  Thomas Wallace of Ohio

was arrested Tuesday. He's been charged with second-degree manslaughter in

the death of 33-year-old Julie Stratton, a mother of two from a Buffalo

suburb. [...]  Investigators say Wallace also violated federal trucking

rules by sleeping no more than four of 27 hours before the crash.

  http://cnews.canoe.ca/CNEWS/World/2010/01/27/12640006-ap.html



------------------------------



Date: Fri, 22 Jan 2010 03:06:23 -0800 (PST)

From: Paul Robinson <rfc1394_at_private>

Subject: It depends on which bus you take



To go home from the Washington DC Metro I take either the 83 or 86 Metrobus

into Maryland.  The difference between the two routes is that the #86 takes

a detour into the Prince George's Plaza station.



There is a street that crosses both routes.  On the #86, the bus turns off

Baltimore Ave and eventually reaches 40th Avenue, turns onto Oglethorpe

street, where it turns on 42nd Ave.  On the 83, it continues on Baltimore

Ave and simply crosses Oglethorpe.



However, on board every bus running on the 83 and 86 lines is a display that

shows to the passengers every street where the bus is making.  It is

consistent, in that on every #86 bus, it indicates when it is at *Oglethorpe

Street*.  On every #83 bus, it indicates when it is at *Ogelthorpe Street*.



Maybe it's just a GSP, err I mean GPS error...



------------------------------



Date: Wed, 27 Jan 2010 12:15:48 +0100

From: Pete Kaiser <djc_at_private>

Subject: Driving and walking through buildings



Near where I live in Zurich, Friedackerstrasse meets Friedheimstrasse in a T

intersection.  But Google Maps and the street map overlay in Google Earth

show Friedackerstrasse making a 45-degree angle there.



The canopy of a tree at that intersection overhangs the entire actual

meeting point of the two streets, something perfectly evident to the human

eye in the aerial photograph.  I hazard the guess that software used to

detect roads on aerial photographs simply lost the streets there because of

the tree, leaving the algorithm to do something -- anything -- about that,

using some additional GIS data indicating that the streets really do

intersect.  And the algorithm routed (the mapping of) Friedackerstrasse

through the house on the northeast corner.  (It also routes a nearby

pedestrian walk squarely through the apartment building it abuts.)



In practice this one case isn't a large risk because you can't really get

lost because of it, but it provides some insight into how the software

works, and how it fails when it fails.  Where else are streets re-routed,

nonexistent segments added, or existing ones omitted?  And other features?

It's not hard to imagine how this might be important.



This error, combined with the (here well known) principle "there's never

just one bug", must give us pause.



------------------------------



Date: Wed, 27 Jan 2010 16:59:18 -0800

From: Tony Lima <tony_at_private>

Subject: Re: Teleportation via Skyhook (Bliesener, RISKS-25.89)



Actually this is a user error.  Opera Mini uses transcoding to present the

web page on mobile devices.  That means every single bit transmitted and

received is processed through Opera's computers.  That's the reason for the

Norwegian IP address.



Gary should have paid a few bucks for Opera Mobile which does not use

transcoding, relying on more traditional on-device html interpretation.



I spent quite a bit of time testing both versions.  Opera Mini is, indeed,

very fast, but it always struck me that users were giving up way too much

privacy.



Tony Lima Associates, Los Altos, CA, USA, 650-243-1286



------------------------------



Date: Wed, 27 Jan 2010 15:12:21 -0500

From: Mark Jackson <mjackson_at_private>

Subject: Re: Extending TCP/IP into space (Randall, RISKS-25.92)



When the Shuttle overflies the runway when returning from the next ISS

mission, we'll know why.



Mark Jackson - http://www.alumni.caltech.edu/~mjackson



------------------------------



Date: Thu, 29 May 2008 07:53:46 -0900

From: RISKS-request_at_private

Subject: Abridged info on RISKS (comp.risks)



 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.

=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)

 if possible and convenient for you.   The mailman Web interface can

 be used directly to subscribe and unsubscribe:

   http://lists.csl.sri.com/mailman/listinfo/risks

 Alternatively, to subscribe or unsubscribe via e-mail to mailman

 your FROM: address, send a message to

   risks-request_at_private

 containing only the one-word text subscribe or unsubscribe.  You may

 also specify a different receiving address: subscribe address= ... .

 You may short-circuit that process by sending directly to either

   risks-subscribe_at_private or risks-unsubscribe_at_private

 depending on which action is to be taken.



 Subscription and unsubscription requests require that you reply to a

 confirmation message sent to the subscribing mail address.  Instructions

 are included in the confirmation message.  Each issue of RISKS that you

 receive contains information on how to post, unsubscribe, etc.



=> The complete INFO file (submissions, default disclaimers, archive sites,

 copyright policy, etc.) is online.

   <http://www.CSL.sri.com/risksinfo.html>

 The full info file may appear now and then in RISKS issues.

 *** Contributors are assumed to have read the full info file for guidelines.



=> .UK users should contact <Lindsay.Marshall_at_private>.

=> SPAM challenge-responses will not be honored.  Instead, use an alternative

 address from which you NEVER send mail!

=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.

 *** NOTE: Including the string "notsp" at the beginning or end of the subject

 *** line will be very helpful in separating real contributions from spam.

 *** This attention-string may change, so watch this space now and then.

=> ARCHIVES: ftp://ftp.sri.com/risks for current volume

     or ftp://ftp.sri.com/VL/risks for previous VoLume

 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive

 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.

   Lindsay has also added to the Newcastle catless site a palmtop version

   of the most recent RISKS issue and a WAP version that works for many but

   not all telephones: http://catless.ncl.ac.uk/w/r

 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .

==> PGN's comprehensive historical Illustrative Risks summary of one liners:

    <http://www.csl.sri.com/illustrative.html> for browsing,

    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing

==> Special Offer to Join ACM for readers of the ACM RISKS Forum:

    <http://www.acm.org/joinacm1>



------------------------------



End of RISKS-FORUM Digest 25.93

************************



Received on Fri Jan 29 2010 - 11:07:25 PST





]]>
Fri, 29 Jan 2010 11:07:25 PST
RISKS List Owner



http://lists.jammed.com/RISKS/2010/01/0002.html






From: RISKS List Owner <risko_at_private>




Date: Tue, 19 Jan 2010 15:54:26 PST






RISKS-LIST: Risks-Forum Digest  Tuesday 19 January 2010  Volume 25 : Issue 91



ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy



***** See last item for further information, disclaimers, caveats, etc. *****

This issue is archived at <http://www.risks.org> as

  <http://catless.ncl.ac.uk/Risks/25.91.html>

The current issue can be found at

  <http://www.csl.sri.com/users/risko/risks.txt>



  Contents:

New Massachusetts unemployment insurance employer website crashes and burns

  upon launch (Jonathan Kamens)

Moscow grinds to a halt: spoofed traffic signs? (PGN)

Despite Risks, Internet Creeps Onto Car Dashboards (Matthew Kruk)

Software Firms Fear Hackers Who Leave No Trace (Markoff/Vance via PGN)

"--b" parsed as a double-negation (jidanni)

Network flaw connects Facebook users to wrong accounts (Steven J Klein)

Fraudulent Facebook group leads to malware scam (Matthew Kruk)

A5/3 attack (Alexander Klimov)

S&P loses 8.5% (Daniel P.B. Smith)

Dangerously wrong trailer weight in Web tool (Rex Sanders)

Australian man dies after being crushed by computers (Darryl Smith)

Update Your XYZZY Web Site Password (Dale E. Coy)

Offensive shutting down of botnets (Kelly Jackson Higgins via PGN)

Y2K+10 problem 1910 in BPCS 8.1 ERP (Al MacIntyre)

Y2K+10: Windows Mobile has 2010 problems too (Jeremy Epstein)

Y2K? Taiwan, N. Korea calendars facing Y1C in 2011! (jidanni)

Re: Couple Stuck in Oregon Snow for 3 Days After GPS Leads

 Them Astray (Al Stangenberger)

Other Traffic Risks (Gene Wirchenko)

REVIEW: "Into the Breach", Michael J. Santarcangelo (Rob Slade)

Abridged info on RISKS (comp.risks)



----------------------------------------------------------------------



Date: Thu, 14 Jan 2010 21:52:41 -0500

From: Jonathan Kamens <jik_at_private>

Subject: New Massachusetts unemployment insurance employer website

 crashes and burns upon launch



The Commonwealth of Massachusetts has a convoluted(*) unemployment insurance

system, under which employers are required to make various quarterly and

annual filings and quarterly payments involving at least two different state

agencies.



This system is administered by the Department of Unemployment Assistance

(DUA), who decided to replace their old, paper-based system with a Web-based

system called QUEST ("Quality Unemployment System Transformation").  The DUA

promised QUEST would bring countless improvements: one-stop shopping,

filings for all agencies in one place, faster filings, less wasted paper,

reduced printing and postage costs, reduced data entry costs, no more data

transcription errors, etc., etc.  You've no doubt heard it all before.



QUEST went live at the beginning of 2010.  As of the go-live date, the usage

of QUEST for all employer unemployment insurance transactions was mandatory;

paper filings were no longer permitted.  I.e., the DUA went straight from

paper filings only to on-line filings only, with no transition period or

overlap.(**)



It would be an understatement to say that QUEST is having some problems.  It

would probably be more accurate to say that it is a disaster.  Some examples

of the issues I've experienced trying to use the new system today to do my

filing for the last quarter of 2009:



 * I received an e-mail message informing me that there was correspondence

   in my QUEST inbox, and I should log into QUEST to read it.  When I log

   into QUEST and click on the link for the correspondence in question, I

   get a .NET error page.



 * When I attempted to enter my quarterly filing numbers, I was asked

   to fill in the fields "UI gross wages", "UI taxable wages", and

      "UHI taxable wages", with no explanation on the form or anywhere

      else on the site of what these terms mean or how to determine the

      correct amounts.  A DUA employee with whom I spoke today informed

      me that those words were supposed to be links that I could click

      on for definitions, but for some reason the links were missing

      from the page.



 * The two DUA employees with whom I spoke today both said that the

      new system is having innumerable problems across the board.



 * The first phone number I called today in an attempt to get help

      with QUEST was so swamped that I was not even given the option of

      waiting on hold -- a recording told me they were too busy to help

      me and I should call back later, and then I was disconnected.



 * A little while ago I tried to click on the QUEST login link on the

      DUA Web page and instead reached a DUA Web site error page

      indicating that the page I was trying to access had moved or was

      temporarily unavailable, or some such thing.



  * Some time after that, I tried again, and this time I actually got

    into the QUEST application, at which point I was greeted with a

      different error: "Error: You have reached the Commonwealth of

      Massachusetts Department of Unemployment Assistance. The Quest

      Unemployment System is temporarily unavailable due to scheduled

      maintenance in order to better serve you. Please try your request

      again later. We appreciate your understanding."  Given everything

      else that's going on, it seems highly unlikely to me that it is

      any way accurate to claim that this outage was "scheduled".



 * Earlier today, a new message showed up on the DUA Web site: *Additional

 Time for 4th Quarter Filing and Account Activation* Two-week grace period

 for filing 4th Quarter Employment and Wage Detail Report. New deadline:

 *February 16, 2010*. Penalties apply after deadline. ...  Although the

 January 8th deadline has passed, you can still activate your account

 without a late penalty. Please activate your account as soon as possible to

 avoid the expected high volume of calls and Web traffic near the filing

 deadline.



More.

http://www.mass.gov/Elwd/docs/dua/quest/empl_%26_wage_detail_filing_1st_reminder.pdf



As is typical in government bureaucracies facing epic disasters, there has

been no public disclosure of the fact that there is a problem, or of what is

being done to fix it, or of the ETA for when it will be fixed.  It remains

to be seen whether anything will be disclosed later, or whether any heads

will roll at the DUA in recognition of this monumental cock-up.



1. Perhaps the system does not seem so convoluted to businesses, but it does

to me, a "household employer" who is required to participate in it only

because I've made the seemingly naive decision of attempting to abide by the

law while employing a babysitter for six hours per week.



2. At least, requiring QUEST filing as of 1/1/2010 seems to have been their

original plan.  However, a letter sent to employers January 14 encourages

the use QUEST for filing 4Q2009 reports, which would seem to imply that not

using QUEST is in fact an option.  If so, it's a difficult option to

exercise, since all instructions and forms for filing on paper appear to

have been removed from website, or at least cunningly hidden.

<http://www.mass.gov/Elwd/docs/dua/quest/empl_%26_wage_detail_filing_1st_reminder.pdf>



------------------------------



Date: Tue, 19 Jan 2010 13:45:06 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Moscow grinds to a halt: spoofed traffic signs?



The long URL tells the story nicely.  Two downtown billboard video screens

caused traffic to "jerk.. to a standstill" for 20 minutes, until Panno.ru

removed the content.  They claim it was the result of either "hooligan

hackers" or "advertising competitors".  [Thanks to Herb Lin and Steve

Bellovin for this one.  PGN]



http://www.switched.com/2010/01/16/russian-commuters-treated-to-free-roadside-pornography/



Steve Bellovin has noted various sign-hacking events.

  http://www.foxnews.com/story/0,2933,484326,00.html  (see RISKS-25.53)

  http://www.i-hacked.com/content/view/274/48/  (ADDCO)

  http://www.nytimes.com/2006/05/08/business/media/08sign.html

    ("Stephen Harper Eats Babies")

and a very amusing official posted sign ("Do not take any risks.")

  http://www.woostercollective.com/2009/06/culture_jamming_on_the_london_tube.html

RISKS has noted other cases of spoofed signs in the past, notably dating

back to the 1984 Rose Bowl scoreboard (Caltech vs MIT).  PGN]



------------------------------



Date: Sat, 9 Jan 2010 16:58:33 -0700

From: "Matthew Kruk" <mkrukg_at_private>

Subject: Despite Risks, Internet Creeps Onto Car Dashboards



As if we didn't have enough bad drivers out there ...



To the dismay of safety advocates already worried about driver distraction,

automakers and high-tech companies have found a new place to put

sophisticated Internet-connected computers: the front seat.  [Source: Ashlee

Vance and Matt Richtel, *The New York Times*, 7 Jan 2010.]

  http://www.nytimes.com/2010/01/07/technology/07distracted.html



------------------------------



Date: Tue, 19 Jan 2010 13:48:18 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Software Firms Fear Hackers Who Leave No Trace



The title of this article gives you a strong clue as to its content.  The

Web page includes many readers' comments, so I won't try to capture the

entire discussion -- which should be very familiar to RISKS readers.



  John Markoff and Ashlee Vance, Fearing Hackers Who Leave No Trace,

  *The New York Times*, dated 19 Jan 2010

  http://www.nytimes.com/2010/01/20/technology/20code.html



------------------------------



Date: Tue, 12 Jan 2010 10:22:51 +0800

From: jidanni_at_private

Subject: "--b" parsed as a double-negation



POSIX says support for ++ and -- is "not required", but doesn't say how to

deal with ++b and --b when they aren't supported.



So we end up with

$ bash -c 'b=5; echo $((--b)); echo $((--b))'

4

3

$ dash -c 'b=5; echo $((--b)); echo $((--b))'

5

5

--b is being parsed here as a double-negation!

http://bugs.debian.org/508602



------------------------------



Date: Sun, 17 Jan 2010 13:30:02 -0500

From: Steven J Klein <steven_at_private>

Subject: Network flaw connects Facebook users to wrong accounts



Source: http://www.washingtontimes.com/news/2010/jan/16/network-flaw-causes-scary-web-error/

2010 Network flaw causes scary Web error



A woman in Georgia using a Nokia phone connected to facebook.com, and found

herself logged in to a stranger's account, without ever having been prompted

to log in.  She asked her mother & sister, both with the same model phone to

try it, and both also ended up in the accounts of other unknown parties.

They sent an e-mail from Facebook as evidence that what they described

really happened.



I want to emphasize that the error isn't specifically a Facebook problem,

but an AT&T network issue. Facebook could fix the problem by using a secure

connection.



Excerpt:



  The glitch -- the result of a routing problem at the family's wireless

  carrier, AT&T -- revealed a little known security flaw...  In each case,

  the Internet lost track of who was who, putting the women into the wrong

  accounts...  It's not clear whether such episodes are rare or simply not

  reported...  The women, who live together in East Point, Ga., outside

  Atlanta, had recently upgraded to the same model of phone and all used the

  same carrier, AT&T...  AT&T spokesman Michael Coe said its wireless

  customers have landed in the wrong Facebook pages in "a limited number of

  instances" and that a network problem behind those episodes is being

  fixed.



This is, of course, a serious problem.  But it's not clear to me that

there's any way for bad guys to intentionally exploit it.



Steven J Klein, A+ and Apple Certified, Your Mac & PC Expert (248) YOUR-MAC



------------------------------



Date: Sat, 9 Jan 2010 23:42:15 -0700

From: "Matthew Kruk" <mkrukg_at_private>

Subject: Fraudulent Facebook group leads to malware scam



If you happen to be on Facebook today and spot a group that is called,

"WE'RE AGAINST THE 4.99 A MONTH CHARGE FOR FACEBOOK FROM JUNE 30TH 2010,? be

sure to keep away from it. If you don't - instead of finding a friendly

group of people that are there to discuss ideas or similar interests, a user

could potentially end up with loads of malware garbage on their computer.



http://www.geek.com/articles/news/fraudulent-facebook-group-leads-to-malware-scam-20091229/



------------------------------



Date: Tue, 12 Jan 2010 12:46:25 +0200

From: Alexander Klimov <alserkli_at_private>

Subject: A5/3 attack



As you may already know, GSM phone conversations are encrypted with the 20+

years old A5/1 and A5/2 stream ciphers. The ciphers were repeatedly shown to

be weak, but in absence of a publicly available decryption tools the GSM

Association was able to claim that the attacks are not practical. Last

December the completion of tables needed for breaking A5/1 was announced and

now the GSM Association intends to speed up the transition to A5/3.



This A5/3 block cipher is KASUMI, which is a modified version of the MISTY

cryptosystem. Recently (2010-01-10) it was publicly shown that it is

possible to derive the complete 128-bit key of the full KASUMI by using only

4 related keys, 2^26 data, 2^30 bytes of memory, and 2^32 time (two hours on

a single PC).  <http://eprint.iacr.org/2010/013.pdf>



Authors of the attack note:

  neither our technique nor any other published attack can break MISTY in

  less than the 2^128 complexity of exhaustive search, which indicates that

  the changes made by the GSM Association in moving from MISTY to KASUMI

  resulted in a much weaker cryptosystem.



Never attribute to malice that which can be adequately explained by stupidity.



------------------------------



Date: Tue, 12 Jan 2010 09:13:04 -0500

From: "Daniel P.B. Smith" <usenet2006_at_private>

Subject: S&P loses 8.5%



As noted in the Bogleheads investing forum, the S&P 500 index plummeted 97.7

points or 8.53% in the last instant of trading on Monday, January 11th,

2010... as shown by Google Finance and other online charts.



An actual 8.53% drop would of course have generated screaming headlines, but

perfunctory Googling suggests that this glitch has escaped the notice of the

financial press.



The obvious RISK is that an investor might take action on erroneously

reported information, especially when that information could be "confirmed"

by more than one source. This particular glitch is obvious enough to make

such a thing unlikely, but it does place into question the reliability of

our financial reporting channels.



Why does such a thing ever happen? How difficult is it to calculate the

average of 500 numbers... and to omit reporting the result if any of them

are missing?



Here is a screenshot of the glitch as shown by Google Finance. The glitch

was not limited to Google, however.



http://img31.imageshack.us/img31/6914/sp8.png



The arrow points to the plummet. The chart displays a dynamic readout when

you point to places on the curve, and the circled number is the readout for

the right end of the curve. Fortunately, all of the summary numbers are

displayed correctly, showing that it was a gratifyingly dull day.



Bogleheads discussion:



Bogleheads link: http://www.bogleheads.org/forum/viewtopic.php?t=48592&mrr=1263297139



------------------------------



Date: Tue, 12 Jan 2010 17:22:21 -0800

From: Rex Sanders <rsanders_at_private>

Subject: Dangerously wrong trailer weight in Web tool



A good friend wanted to rent a trailer to haul heavy stuff about 1,000

miles.  The website of a reputable company had a tool for matching vehicle

towing capacity, trailer weights, and trailer cargo capacity.  He found a

trailer that just met all his requirements, and reserved the trailer online.



Except it seemed a little too good to be true.  A couple days before

leaving, he dug deeper on that company's website.  Under the specifications

for that trailer, he found the trailer weight listed at 1,000 pounds higher!



He called customer service.  The first agent tried to convince him through

some dubious logic that the extra weight would not be a problem.



He called again to get a second agent, who confirmed an error in the Web

tool, and promised to get it fixed.  My friend rented a truck instead.



If he had trusted the Web tool, or the first agent, he could have suffered a

serious crash through overloading.



Lessons: A trailer rental database error could have killed people.  And some

customer service agents are more trustworthy than others.



------------------------------



Date: Tue, 12 Jan 2010 22:15:20 +1100

From: "Darryl Smith" <Darryl_at_radio-active.net.au>

Subject: Australian man dies after being crushed by computers



An Australian man has died after computer equipment fell on him as it was

being unloaded from a truck according to a local paper...  "It appears the

man was helping others unload a large computer server from the back of a

truck,'' ambulance clinical support officer Mark Lamb said.

http://www.news.com.au/breaking-news/man-dies-after-being-crushed-by-compute

rs-in-melbourne/story-e6frfku0-1225818578320



Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia

www.radio-active.net.au/blog/ - www.radio-active.net.au/web/tracking/



------------------------------



Date: Sat, 16 Jan 2010 11:53:11 -0600

From: "Dale E. Coy" <dale_at_private>

Subject: Update Your XYZZY Web Site Password



For many years I've been a member of an organization that has a website that

has negligible risk, but requires a login for some purposes.  The

organization (let's call it XYZZY) has always used the members' surname as a

password.  On January 16th, I received the following e-mail (slightly altered

to obscure the organization [and the sender!  PGN]).



  Dear Mr. Coy,



  Due to website maintenance, the "member/guest only" sections of the XYZZY

  website will not be available until after Jan. 26. As part of this

  maintenance, we are increasing security measures. Passwords now must be at

  least five characters in length. Your current password does not meet this

  security requirement and you will be unable to log in. Please call XYZZY's

  Member Service Center at (800) 555-1212 from 8 a.m. to 6 p.m. EST or

  e-mail webmaster_at_private to update your password. We apologize for this

  inconvenience.



  I. Mostly Clueless, Deputy Director/Web Manager



Of course, I've sent e-mail requesting that they change my password.  I'm

anticipating that they will send my new password by email.



  [PGN says, not so Coyly, you should request a password of "Coyote" as in

  "Don Coyote", Or you could change your name.  That would certainly

  increase your security!  But they will probably change your NAME and

  PASSWORD for you.  I remember the 1108 operating system password, which

  was also the same as your user name.  If you attempted to change your

  password, as I recall it would tell you that your desired password change

  was already in use if it belonged to another user.  Now that's what we

  mean by REAL security!]



------------------------------



Date: Tue, 12 Jan 2010 9:37:02 -0800

From: Peter G Neumann <neumann_at_private>

Subject: Offensive shutting down of botnets



http://www.darkreading.com/insiderthreat/security/vulnerabilities/showArticle.jhtml?articleID=222300408



Kelly Jackson Higgins, DarkReading, 11 Jan 2010



Yet another botnet has been shut down as of today as researchers joined

forces with ISPs to cut communications to the prolific Lethic spamming

botnet -- a development that illustrates how botnet hunters increasingly are

going on the offensive to stop cybercriminals, mainly by disrupting their

valuable bot infrastructures.



For the most part researchers monitor and study botnets with honeypots and

other more passive methods. Then security vendors come up with malware

signatures to help their customers scan for these threats. But some

researchers are turning up the heat on the bad guys' botnet infrastructures

by taking the lead in killing some botnets: Aside from last weekend's

takedown by Neustar of Lethic, which is responsible for about 10 percent of

all spam, FireEye last November helped shut down the MegaD botnet. And

researchers at the University of California at Santa Barbara in May revealed

they had taken the offensive strategy one step further by infiltrating the

Torpig botnet, a bold and controversial move that stirred debate about just

how far researchers should go to disrupt a botnet.



Back in 2008 after two major ISPs halted traffic to malicious hosting

provider McColo, spam worldwide dropped around 70 percent because McColo had

been the main home to most botnet command and control (C&C) servers.



But deploying more offensive tactics to stop botnets and bad guys is not so

straightforward: Researchers walk a fine line as to how far they can go

legally and ethically, and sometimes taking down a botnet actually

backfires, either with the bad guys returning the favor with a

denial-of-service (DoS) attack, or learning how to better evade

investigators next time. There's the danger that getting inside a botnet

will just give its operators more tools and insight into how to strengthen

their operations; botnet operators are notorious for reinventing themselves

with stealthier botnets and new forms of malware.  [...]



------------------------------



Date: Fri, 8 Jan 2010 20:51:20 -0600

From: Al MacIntyre <macwheel99_at_private>

Subject: Y2K+10 problem 1910 in BPCS 8.1 ERP



http://archive.midrange.com/bpcs-l/201001/msg00012.html



BPCS-L discussion group has found out about a Y2K+10 problem in Business

Planning and Control System (BPCS) version 8.1.00 where Trusted Link

Enterprise (TLE) version 3.2.01 substitutes 1910 for 2010 in Electronic Data

Interchange (EDI). The vendor (Infor) knows about it, and is working on a

fix.



------------------------------



Date: Thu, 14 Jan 2010 13:49:34 -0500

From: Jeremy Epstein <jeremy.j.epstein_at_private>

Subject: Y2K+10: Windows Mobile has 2010 problems too



Should be no surprise, given RISKS 25.89 and 25.90, but.... according

to Cnet, there's reports of a glitch on Windows Mobile that some

devices are putting the wrong date on incoming SMS messages - using

2016 rather than 2010.  Microsoft has acknowledged the problem, but I

haven't seen any reports of fixes.



Source: http://news.cnet.com/8301-13860_3-10425455-56.html



------------------------------



Date: Sun, 10 Jan 2010 05:47:49 +0800

From: jidanni_at_private

Subject: Y2K? Taiwan, N. Korea calendars facing Y1C in 2011!



"This [everything-begins-again-with-us] dating system -- which reflects the

habits of the imperial dynasties, isn't just a quaint local custom, its

continued use is heading Taiwan toward its very own type of Y2K problem on

2011/1/1, when Taiwan's calendar reaches the age of 100 and has to jump to

three-digit years, Taiwan will likely experience what I like to call the Y1C

problem. (Yes, I know: I'm mixing systems in that C represents hundred in a

system that uses M, not K, for 'thousand.' But that's the best I could come

up with. I'm open to suggestions for catchy but correct names.)" North Korea

too, the very same day.



http://pcofftherails101.blogspot.com/2010/01/is-there-y1c-computer-glitch-in-taiwans.html

http://pinyin.info/news/2006/taiwans-y1c-problem

http://en.wikipedia.org/wiki/Y1C_Problem

http://en.wikipedia.org/wiki/Minguo_calendar

http://en.wikipedia.org/wiki/Juche#Calendar



------------------------------



Date: Fri, 08 Jan 2010 11:48:39 -0800

From: Al Stangenberger <forags_at_private>

Subject: Re: Couple Stuck in Oregon Snow for 3 Days After GPS Leads

 Them Astray (Grady: Risks 25:89)



Part of this problem can be caused by poor-quality data in the underlying

map database used by the GPS.



I found a similar error while reviewing a web page which has a link to

Google Maps to give directions from Berkeley to the University of

California's forestry camp in Plumas County.  The printed map directed users

to take a Forest Service road as the shortest route; the road is dirt and

not suitable for passenger cars.  I contacted Tele Atlas (the firm which

supplies the basic road data used by Google Maps), and found that they did

not know that the road was dirt.  They have updated the database, which

fixed the problem.



But all of these incidents (remember the Stolpa family in 1993?) just point

out that all the technology and maps in the world are no substitute for

common sense...



------------------------------



Date: Fri, 08 Jan 2010 21:23:34 -0800

From: Gene Wirchenko <genew_at_private>

Subject: Other Traffic Risks



While these traffic risks are not computer-related, they do help point out

how hard it can be to get it right.  So how difficult is it to construct a

good road sign?



1) Snow can stick to signs.  I recall driving near Penticton, British

Columbia, Canada one night and being very thankful that I knew the road.

The highway has some switchbacks as it descends into the Okanagan Valley

from Keremeos.  The turns are signed.  They are very visible three seasons

of the year.  In snow, the signs can be barely visible and not readable at

all.  *I* knew to slow down.  What about someone else?



Heated signs anyone?



2) In the same area and in others, it can be very windy.  I have seen signs

mounted so that they turn in the wind.  I would not have thought that

necessary.



I wonder if anyone has been injured by a sign that broke loose in the wind.



------------------------------



Date: Mon, 11 Jan 2010 11:45:04 -0800

From: Rob Slade <rmslade_at_private>

Subject: REVIEW: "Into the Breach", Michael J. Santarcangelo



BKINTBRE.RVW   20091012



"Into the Breach", Michael J. Santarcangelo, 2008, 978-0-9816363-0-6

%A   Michael J. Santarcangelo michael_at_private

%C   New York, USA

%D   2008

%G   978-0-9816363-0-6 0-9816363-0-6

%I   Catalyst Media

%O   www.intothebreach.com

%O  http://www.amazon.com/exec/obidos/ASIN/0981636306/robsladesinterne

  http://www.amazon.co.uk/exec/obidos/ASIN/0981636306/robsladesinte-21

%O   http://www.amazon.ca/exec/obidos/ASIN/0981636306/robsladesin03-20

%O   Audience i+ Tech 1 Writing 2 (see revfaq.htm for explanation)

%P   110 p.

%T   "Into the Breach"



The introduction states that security (which seems to be limited to

disclosure or breaches) is a "people" problem, and therefore requires social

solutions.  This addresses a common problem: security professionals, and

even non-technical managers, concentrate on breaches in systems and thus

miss the real heart of the matter: people.



Although not overtly stated, part one seems to be related to the first stage

in the Strategy to Protect Information, understanding information.  Chapter

one repeats the position that breaches are a human problem.  Security

awareness is promoted in chapter two.  In chapter three an analogy is drawn

between faddish security and crash dieting, noting that neither works.

Chapter four addresses risk management.



Part two suggests managing people.  Chapter five outlines the aforementioned

Strategy to Protect Information: understand your information assets, manage

and communicate with your people, and optimize your processes and systems.

Implementing this strategy is seen, in chapter six, as a five step process:

learn the jobs, gather information, prioritize, plan, and communicate.

Steps seem to be missing, such as dividing your data or systems into

elements for the process.  Guidance for planning is limited.  Chapter seven

suggests making a trial run with a pilot project, which is a good idea.

Measurement of the success of the project is discussed in chapter eight.



Part three deals with improvement.  Chapter nine notes that the strategy

benefits overall management, which is unsurprising, since it is basically a

general management process.  Costs of compliance with regulations or

standards are also partially covered, as is mentioned in chapter ten, since

a significant portion of the initial cost of compliance relies on the type

of research and analysis demanded by the strategy.  (However, a great deal

of the content simply emphasizes the importance of compliance.)  The advice

about outsourcing, in chapter eleven, seems to be to audit the vendor.

Chapter twelve closes off the book with an exhortation to act.



Although generic, the strategy proposed is sound and likely useful.  This

slim volume would help a significant number of managers and security

practitioners who are caught up in the latest security fad or device, to the

detriment of actual business (and personnel) needs.



copyright Robert M. Slade, 2009    BKINTBRE.RVW   20091012

rslade_at_private     slade_at_private     rslade_at_private

victoria.tc.ca/techrev/rms.htm blog.isc2.org/isc2_blog/slade/index.html

http://blogs.securiteam.com/index.php/archives/author/p1/

http://twitter.com/NoticeBored http://twitter.com/rslade



------------------------------



Date: Thu, 29 May 2008 07:53:46 -0900

From: RISKS-request_at_private

Subject: Abridged info on RISKS (comp.risks)



 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.

=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)

 if possible and convenient for you.   The mailman Web interface can

 be used directly to subscribe and unsubscribe:

   http://lists.csl.sri.com/mailman/listinfo/risks

 Alternatively, to subscribe or unsubscribe via e-mail to mailman

 your FROM: address, send a message to

   risks-request_at_private

 containing only the one-word text subscribe or unsubscribe.  You may

 also specify a different receiving address: subscribe address= ... .

 You may short-circuit that process by sending directly to either

   risks-subscribe_at_private or risks-unsubscribe_at_private

 depending on which action is to be taken.



 Subscription and unsubscription requests require that you reply to a

 confirmation message sent to the subscribing mail address.  Instructions

 are included in the confirmation message.  Each issue of RISKS that you

 receive contains information on how to post, unsubscribe, etc.



=> The complete INFO file (submissions, default disclaimers, archive sites,

 copyright policy, etc.) is online.

   <http://www.CSL.sri.com/risksinfo.html>

 The full info file may appear now and then in RISKS issues.

 *** Contributors are assumed to have read the full info file for guidelines.



=> .UK users should contact <Lindsay.Marshall_at_private>.

=> SPAM challenge-responses will not be honored.  Instead, use an alternative

 address from which you NEVER send mail!

=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.

 *** NOTE: Including the string "notsp" at the beginning or end of the subject

 *** line will be very helpful in separating real contributions from spam.

 *** This attention-string may change, so watch this space now and then.

=> ARCHIVES: ftp://ftp.sri.com/risks for current volume

     or ftp://ftp.sri.com/VL/risks for previous VoLume

 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive

 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.

   Lindsay has also added to the Newcastle catless site a palmtop version

   of the most recent RISKS issue and a WAP version that works for many but

   not all telephones: http://catless.ncl.ac.uk/w/r

 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .

==> PGN's comprehensive historical Illustrative Risks summary of one liners:

    <http://www.csl.sri.com/illustrative.html> for browsing,

    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing

==> Special Offer to Join ACM for readers of the ACM RISKS Forum:

    <http://www.acm.org/joinacm1>



------------------------------



End of RISKS-FORUM Digest 25.91

************************



Received on Tue Jan 19 2010 - 15:54:26 PST





]]>
Tue, 19 Jan 2010 15:54:26 PST
RISKS List Owner



http://lists.jammed.com/RISKS/2010/02/0001.html






From: RISKS List Owner <risko_at_private>




Date: Sun, 28 Feb 2010 6:03:14 PST






RISKS-LIST: Risks-Forum Digest  Sunday 28 February 2010  Volume 25 : Issue 95



ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy



***** See last item for further information, disclaimers, caveats, etc. *****

This issue is archived at <http://www.risks.org> as

  <http://catless.ncl.ac.uk/Risks/25.95.html>

The current issue can be found at

  <http://www.csl.sri.com/users/risko/risks.txt>



  Contents: [Backlogged]

Growing Threat to GPS Systems From Jammers (Jerry Leichter)

Sat-nav systems under growing threat from 'jammers' (Amos Shapir)

More on Risks of EMV Legacy Compatibility (Anthony Thorn)

Self-Signed Certificates Strike Again? (Bob Gezelter)

Facebook friended, boyfriend offended, tragically ended (John Linwood Griffin)

Google: Serious threat to the web in Italy (Monty Solomon)

Fault-Tolerance as a Risk (Gene Wirchenko)

School District Spying on Students at Home? (Gene Wirchenko)

A Message from Ric Edelman about data lost (fjohn reinke)

Nationwide Technetium shortage: coinciding reactor failure/maintenance

  (Richard I. Cook)

IEEE Symposium on Security and Privacy: 30th anniversary (David Evans)

FOSE 2010 (Kalin Tyler)

Abridged info on RISKS (comp.risks)



----------------------------------------------------------------------



Date: Thu, 25 Feb 2010 20:44:03 -0500

From: Jerry Leichter <leichter_at_private>

Subject: Growing Threat to GPS Systems From Jammers



The BBC reports (http://news.bbc.co.uk/2/hi/science/nature/8533157.stm)

on the growing threat of jamming to satellite navigation systems.  The

fundamental vulnerability of all the systems - GPS, the Russian Glonass, and

the European Galileo - is the very low power of the transmissions.  (Nice

analogy: A satellite puts out less power than a car headlight, illuminating

more than a third of the Earth's surface from 20,000 kilometers.)  Jammers -

which simply overwhelm the satellite signal - are increasingly available

on-line.  According to the article, low-powered hand-held versions cost less

than £100, run for hours on a battery, and can confuse receivers tens of

kilometers away.



The newer threat is from spoofers, which can project a false location.  This

still costs "thousands", but the price will inevitably come down.



A test done in 2008 showed that it was easy to badly spoof ships of the

English coast, causing them to read locations anywhere from Ireland to

Scandinavia.



Beyond simple hacking - someone is quoted saying "You can consider GPS a

little like computers before the first virus - if I had stood here before

then and cried about the risks, you would've asked 'why would anyone

bother?'." - among the possible vulnerabilities are to high- value cargo,

armored cars, and rental cars tracked by GPS.  As we build more and more

"location-aware" services, we are inherently building more

"false-location-vulnerable" services at the same time.  -- Jerry



------------------------------



Date: Wed, 24 Feb 2010 17:54:47 +0200

From: Amos Shapir <amos083_at_private>

Subject:  Sat-nav systems under growing threat from 'jammers'



"While "jamming" sat-nav equipment with noise signals is on the rise, more

sophisticated methods allow hackers even to program what receivers

display. At risk are not only sat-nav users, but also critical national

infrastructure."



Full story at: http://news.bbc.co.uk/1/hi/sci/tech/8533157.stm



  [This risk noted by several others as well.]



------------------------------



Date: Tue, 23 Feb 2010 09:27:28 +0100

From: Anthony Thorn <anthony.thorn_at_private>

Subject: More on Risks of EMV Legacy Compatibility (Magda, RISKS-25.94)



Recently Ross Anderson's group has published a new and very serious

vulnerability in the "Chip & Pin" (EMV) authentication used by many

-probably most- credit and debit card issuers world wide.



Very briefly: "The attack uses an electronic device as a "man-in-the-middle"

...  ... the terminal thinks that the PIN was entered correctly, and the

card assumes that a signature was used to authenticate the transaction."



The paper:

http://www.cl.cam.ac.uk/research/security/projects/banking/nopin/oakland10chipbroken.pdf



The FAQ

http://www.cl.cam.ac.uk/research/security/projects/banking/nopin/



The BBC Video

http://www.bbc.co.uk/blogs/newsnight/susanwatts/2010/02/new_flaws_in_chip_and_pin_syst.html



The risk: Providing "legacy compatibility", in this case with signature

based authentication, always involves additional risk and requires special

attention.



(Acknowledgment to Bruce Schneier's blog)



------------------------------



Date: Tue, 23 Feb 2010 07:03:33 -0500

From: Bob Gezelter <gezelter_at_private>

Subject: Self-Signed Certificates Strike Again?



CNN has posted an item: "Elvis Presley passport exposes security flaw"

(Atika Shubert, 2010-02-23) relating an interview with Adam Laurie and

Jeroen Van Beek, two self-described "ethical hackers" who created a forged

passport in the name of Elvis Presley from a non-existent country.



According to the article, the passport was accepted by an automated scanning

machine, even though it was signed by what amounted to a self-signed

certificate. Laurie is quoted as saying that many countries do not share

sufficient information for others to authenticate the digital signatures.



The article can be found at:



http://www.cnn.com/2010/TECH/02/19/passport.security/index.html



The need for commonly accepted higher level certification authority or

authorities is a well-understood part of such digital signature

authentication schemes. It is disturbing that such a registration or

acceptance feature, common to all web browser security implementations, has

not been internationally accepted, despite the fact that the infra-structure

is already in place in a number of international organizations (e.g., IPU,

ITU-T [formerly CCITT], and others).



- Bob Gezelter, http://www.rlgsc.com



------------------------------



Date: Thu, 25 Feb 2010 14:49:21 -0500 (EST)

From: John Linwood Griffin <griffin2_at_private>

Subject: Facebook friended, boyfriend offended, tragically ended



The independent newspaper *City Paper* runs a weekly column, "Murder Ink",

that provides coverage of homicides here in Baltimore City, Maryland.



A computer-related murder on February 17, 2010, caught my eye:



> Two men got into an argument with Couther's aunt over a Facebook page.

> Couther went into the living room to help his aunt and ended up arguing

> and then fighting with one of the men [resulting in Couther's throat being

> slashed] [...] Couther died at a local hospital an hour later.  Montaize

> Alford [was] arrested and charged with Couther's murder.  According to

> [Stephen Janis of investigativevoice.com], the aunt was being beaten by

> her boyfriend because a man "friended" her on Facebook.



http://www.citypaper.com/news/story.asp?id=19818 (Anna Ditkoff writing in

*City Paper* volume 34 number 8, page 8, February 23, 2010)



Peter Hermann of *The Baltimore Sun* corroborates the Facebook angle on his

blog, citing police detective Michael Moran's charging documents:



> [Couther's aunt] Begett had returned from work and was sleeping on her

> sofa when Alford called her on her cell phone at about 2 a.m. and started

> arguing with her about a male friend on her Facebook page [...]  Begett

> hung up on Alford and moments later he showed up at her home and entered

> using a key.  He began assaulting her [then] Couther and Alford began

> fighting [resulting in] a large laceration to [Couther's] neck which was

> bleeding profusely.



http://weblogs.baltimoresun.com/news/crime/blog/2010/02/slew_of_homicide_arrests_inclu.html



Since this is the RISKS Forum, I felt at first compelled to come up with a

piquant observation about the erosion of privacy inherent in social network

computing.  But then I realized I'm missing the broader issue.  It's not our

role as scientists and practitioners to complain about how "the times they

are a-changin'" -- it's to ask questions like "was Begett aware when she

accepted the friending request that the action would be visible to her

boyfriend, and if she was not aware then how could that consequence have

been conveyed better by Facebook or other entities?"  The RISK to me (whom a

student called "tragically uncool" due to my apparent underuse of social

networking media) is missing an opportunity to do something about a problem

simply because I don't like the problem.



------------------------------



Date: Wed, 24 Feb 2010 09:30:43 -0500

From: Monty Solomon <monty_at_private>

Subject: Google: Serious threat to the web in Italy



Serious threat to the web in Italy, 24 Feb 2010



In late 2006, students at a school in Turin, Italy filmed and then uploaded

a video to Google Video that showed them bullying an autistic

schoolmate. The video was totally reprehensible and we took it down within

hours of being notified by the Italian police. We also worked with the local

police to help identify the person responsible for uploading it and she was

subsequently sentenced to 10 months community service by a court in Turin,

as were several other classmates who were also involved. In these rare but

unpleasant cases, that's where our involvement would normally end.



But in this instance, a public prosecutor in Milan decided to indict four

Google employees -David Drummond, Arvind Desikan, Peter Fleischer and George

Reyes (who left the company in 2008). The charges brought against them were

criminal defamation and a failure to comply with the Italian privacy

code. To be clear, none of the four Googlers charged had anything to do with

this video. They did not appear in it, film it, upload it or review it. None

of them know the people involved or were even aware of the video's existence

until after it was removed.



Nevertheless, a judge in Milan today convicted 3 of the 4 defendants - David

Drummond, Peter Fleischer and George Reyes - for failure to comply with the

Italian privacy code. All 4 were found not guilty of criminal defamation. In

essence this ruling means that employees of hosting platforms like Google

Video are criminally responsible for content that users upload. We will

appeal this astonishing decision because the Google employees on trial had

nothing to do with the video in question. Throughout this long process, they

have displayed admirable grace and fortitude. It is outrageous that they

have been subjected to a trial at all. ...



http://googleblog.blogspot.com/2010/02/serious-threat-to-web-in-italy.html



------------------------------



Date: Mon, 22 Feb 2010 12:44:10 -0800

From: Gene Wirchenko <genew_at_private>

Subject: Fault-Tolerance as a Risk



Tim Greene, *IT Business*, 22 Feb 2010

Kneber botnet -- a multi-headed hydra that's wreaking havoc

The most sinister aspect of the Kneber botnet is its interaction with other

malware networks, suggesting a symbiotic relationship that ultimately makes

each bot more resistant to being dismantled.

http://www.itbusiness.ca/it/client/en/home/news.asp?id=56499



At the bottom of the first page of the article are these two paragraphs:



  'What he found is that more than half the 74,000 compromised computers --

bots -- within Kneber were also found infected with other malware that uses

a different command-and-control structure. If one of the criminal networks

were disabled, the other could be used to build it up again,



  "At the very least, two separate botnet families with different

[command-and-control] infrastructures can provide fault tolerance and

recoverability in the event that one [command-and-control] mechanism is

taken down by security efforts," he says in his written analysis of the

Kneber botnet.'



------------------------------



Date: Mon, 22 Feb 2010 13:37:37 -0800

From: Gene Wirchenko <genew_at_private>

Subject: School District Spying on Students at Home?



http://news.cnet.com/8301-30977_3-10457077-10347072.html

Students'-eye view of Webcam spy case



The first two paragraphs:



  'Students at Herriton High School in Lower Merion School District near

Philadelphia are given Apple MacBook laptops to use both at school and at

home. Like all MacBooks, the ones issued to the students have a Webcam. And,

in addition to the students' ability to use the Webcam to take pictures or

video, the school district can also use it to take photographs of whomever

is using the computer.



  In a civil complaint (PDF) filed in federal court, a student at the

school, Blake Robbins, said he received a notice from an assistant principal

informing him that "the school district was of the belief that minor

plaintiff was engaged in improper behavior in his home, and cited as

evidence a photograph from the Webcam."'



It is apparently worse than that:



http://www.infoworld.com/d/adventures-in-it/when-schools-spy-their-students-bad-things-happen-474?source=IFWNLE_nlt_notes_2010-02-22

InfoWorld Home / Adventures in IT / Robert X. Cringely Notes from the Field

February 22, 2010



When schools spy on their students, bad things happen Pennsylvania's Lower

Merion School District thought it was clever to use webcams to track its

students' MacBooks -- boy, were they mistaken



Savanna Williams, a statuesque sophomore at Harriton, appeared on CBS's "The

Early Show" with her mother, talking about how she takes her school-supplied

notebook everywhere -- including the bathroom when she showers. If that

doesn't give you a strong mental image of the potential for abuse, nothing

will.



For a thoroughly creepy demonstration of how another school, the Bronx's IS

339, spies on its students using webcams, check out this video. Assistant

Principal Dan Ackerman cheerfully shows how he watches sixth and seventh

graders in real time without their knowing it while they preen in front of

an app called Photo Booth.



Photo Booth is always fun... a lot of kids are just on it to check their

hair, do their makeup, the girls, you know. They just use it like it's a

mirror...  They don't even realize that we're watching...I always like to

mess with them and take a picture.



At least he's doing it on school grounds and not in their bathrooms."



------------------------------



Date: Tue, 23 Feb 2010 17:54:09 -0500

From: fjohn reinke <fjohn_at_private>

Subject: A Message from Ric Edelman about data lost



Begin forwarded message:



> From: "Edelman Financial" <client_at_private>

> Date: February 23, 2010 4:58:14 PM EST

> Subject: A Message from Ric Edelman



Dear fjohn and Evlynn:



For the past two years we have been distributing news, reviews and other

important information to you via email. By bypassing the postal service we

are able to contact you more easily, quickly and cheaply --- which improves

speed and helps us control expenses. Email also allows you to respond to us

more easily and quickly, too, resulting in faster and better service.



The vendor we use for sending you my updates and other non account-related

communications is iContact. We have just been informed that email addresses

have been stolen from iContact's system, possibly by one of their former

employees. iContact is working with law enforcement officials on the matter

and has not yet determined the extent of the theft. At this time, your email

address may or may not have been involved. Because we do not provide

iContact with anything other than email addresses and names, your personal

information remains safe. It was not possible for the thief to obtain

addresses, account numbers or any personal financial data. The worst case is

that you might notice an increase in the amount of spam that you receive. [...]



My best regards, Ric Edelman, Chairman & CEO, 888-752-6742



  [I invite you to read my blog "Reinke Faces Life", visit my sites (all

  listed at http://krunchd.com/reinkefj), and use whatever you need. Join

  me (reinkefj) on LinkedIn, Facebook, Plaxo, and / or follow me on

  Twitter. Remember the adage "first seek to help; then be helped".]



------------------------------



Date: Tue, 23 Feb 2010 15:45:28 -0600

From: "Richard I. Cook, MD" <rcook_at_private>

Subject: Nationwide Technetium shortage: coinciding reactor failure/maintenance



> Subject:  Clinical Update: Nationwide Technetium shortage memo..[]

> Date:     Tue, 23 Feb 2010 ##:##:## -####

> From:     Big University Hospital



On 14 May 2009 the NRU Reactor in Canada was shut down due to a heavy water

leak for repairs. This has impacted approximately 40% of the world's supply

of Mo-99.  Consequently, this has created a nationwide shortage of Tc99

which is used in 80% of nuclear medicine imaging procedures.



On 19 Feb 2010 the High Flux Petten Reactor in the Netherlands will be shut

down for approximately 6 months for repairs further exasperating the already

acute shortage. In the coming weeks it may be necessary to adjust schedules

to cope with the cyclical nature of the remaining supply of Tc99 from our

commercial radiopharmaceutical providers. Typically, our providers will have

a more ample supply in the beginning and end of the week, with seriously

depleted availability Tuesdays and Wednesdays as a result.



Even further complicating the matters, all five major medical isotope

reactors will be off-line for approximately two weeks in mid-March for

routine maintenance. There is a strong possibility there may be no product

available during certain days during those two weeks.



We will be doing everything we can to minimize the impact of this shortage

to our patients including reducing our normal radioactive doses, switching

to protocols that can conserve our supply of Tc99 and possibly using

alternative radioisotopes when clinically applicable. We hope to continue to

serve our faculty and our patients as efficiently as possible during this

crisis.



If you have any questions, please feel free to contact...



We appreciate your understanding during this shortage.



 - - - -



Technetium-99m is a short half-life gamma emitter that is used extensively

in nuclear imaging, especially in nuclear cardiology where is the mainstay

of stress-test imaging. It's short half-life makes it ideal for diagnostic

studies; a small dose of Tc-99m containing tracer can be given to a patient

for a high-quality imaging study with the radioactivity falling to virtually

nothing within a day. The isotope is produced continually as a decay product

of Molybdenum-99 which has a half-life about 10x as long.



The great benefit of the short half-life of the metal imposes a hard

physical limit on its use: it is essential that newly isolated TC-99 be used

within a few hours of its production -- there is no way to store it. The

radiation exposure from a routine TC-99m heart exam is 250 to 500 x that

from a routine chest x-ray. As many as 4 million people undergo such testing

in the U.S. each year.



The present trouble is the result of a long and complex chain of events.

The main Mo-99 production reactor, located in Canada and operated by Atomic

Energy of Canada Limited (AECL), was shut down in early 2009 after a

containment vessel leak was discovered. Repairs are proceeding slowly. Two

replacement reactors were constructed and commissioned but have never used

for production because of technical problems and because AECL determined in

early 2008 that they would have been too expensive to run. Unrelated to the

Canadian outage, a major European source in Holland as shut down in 2008

because of corrosion problems. It was expected to restart this month but

this has been pushed back to "the second half" of August 2010. Several news

sources are reporting that the Maria Polish reactor will be used to produce

medical isotopes, although there are obstacles that may delay availability

further.



A combination of factors have generated the high degree of dependency on a

few, old reactors. The cost of designing, certifying, building, and

commissioning a new reactor is high and operating them has proven far more

expensive than was expected. Concerns about the security for reactors have

increased greatly in the wake of 9/11. Radiopharmaceutical production is not

a growth industry -- indeed advances in non-radioactive imaging show great

promise and may replace the older methods within a decade. No one wants to

spend the huge amount of money needed to build a new reactor to serve a

declining market share. The use of the Maria reactor, which was constructed

in 1970 and renewed in 1986, for this purpose makes sense on a marginal cost

basis: you have a reactor than can do this and no one else does, why not

take advantage of the brief window of opportunity afforded by fate?



A spin-off of the shortage is that it creates an incentive for the quick use

of available Tc-99m. Rather than allowing substantial amounts of Tc-99m to

simply decay before use, look for nuclear medicine programs to seek rigid

control of exam timing and to book patients "standby" to assure that all of

the available material gets used each day.



What does this have to do with RISKS? Not a thing. For once, the problem is

not related to the computers for these reactors, many of which are ancient

devices that only augment the manual and conventional automation that

controls the reactors!



R.I.Cook, MD



------------------------------



Date: Fri, 19 Feb 2010 21:04:19 -0500

From: David Evans <evans_at_private>

Subject: IEEE Symposium on Security and Privacy: 30th anniversary



31st IEEE Symposium on Security and Privacy, 16-19 May 2010

The Claremont Resort, Berkeley/Oakland, California



Advance Program



Sunday, 16 May 2010



4-7pm         Registration and Welcome Reception



Monday, 17 May 2010



8:30-8:45    Opening Remarks

              Ulf Lindqvist, David Evans, Giovanni Vigna



8:45-10:00   Session 1: Malware Analysis

              Chair: Jon Giffin, Georgia Institute of Technology



    Inspector Gadget: Automated Extraction of Proprietary Gadgets from

    Malware Binaries

       Clemens Kolbitsch (Vienna University of Technology),

       Thorsten Holz (Vienna University of Technology),

       Christopher Kruegel (University of California, Santa Barbara),

       Engin Kirda (Institute Eurecom)



    Synthesizing Near-Optimal Malware Specifications from Suspicious

    Behaviors

       Matt Fredrikson (University of Wisconsin),

       Mihai Christodorescu (IBM Research),

       Somesh Jha (University of Wisconsin),

       Reiner Sailer (IBM Research),

       Xifeng Yan (University of California, Santa Barbara)



    Identifying Dormant Functionality in Malware Programs

       Paolo Milani Comparetti (Technical University Vienna),

       Guido Salvaneschi (Politecnico di Milano),

       Clemens Kolbitsch (Technical University Vienna),

       Engin Kirda (Institut Eurecom),

       Christopher Kruegel (University of California, Santa Barbara),

       Stefano Zanero (Politecnico di Milano)



10:20-noon   Session 2: Information Flow

              Chair: David Molnar, Microsoft Research Redmond



    Reconciling Belief and Vulnerability in Information Flow

       Sardaouna Hamadou (University of Southampton),

       Vladimiro Sassone (University of Southampton),

       Catuscia Palamidessi (École Polytechnique)



    Towards Static Flow-based Declassification for Legacy and Untrusted

    Programs

       Bruno P.S. Rocha (Eindhoven University of Technology),

       Sruthi Bandhakavi (University of Illinois at Urbana Champaign),

       Jerry I. den Hartog (Eindhoven University of Technology),

       William H. Winsborough (University of Texas at San Antonio),

       Sandro Etalle (Eindhoven University of Technology)



    Non-Interference Through Secure Multi-Execution

       Dominique Devriese, Frank Piessens (K. U. Leuven)



    Object Capabilities and Isolation of Untrusted Web Applications

       Sergio Maffeis (Imperial College London),

       John C. Mitchell (Stanford University),

       Ankur Taly (Stanford University)



1:30-2:45    Session 3: Root of Trust

              Chair: Radu Sion, Stony Brook University



    TrustVisor: Efficient TCB Reduction and Attestation

       Jonathan McCune (Carnegie Mellon University),

       Yanlin Li (Carnegie Mellon University), Ning Qu (Nvidia),

       Zongwei Zhou (Carnegie Mellon University),

       Anupam Datta (Carnegie Mellon University),

       Virgil Gligor (Carnegie Mellon University),

       Adrian Perrig (Carnegie Mellon University)



    Overcoming an Untrusted Computing Base: Detecting and Removing

    Malicious Hardware Automatically

       Matthew Hicks (University of Illinois),

       Murph Finnicum (University of Illinois),

       Samuel T. King (University of Illinois),

       Milo M. K. Martin (University of Pennsylvania),

       Jonathan M. Smith (University of Pennsylvania)



    Tamper Evident Microprocessors

       Adam Waksman, Simha Sethumadhavan (Columbia University)



3:15-4:55    Session 4: Information Abuse

              Chair: Patrick Traynor, Georgia Institute of Technology



    Side-Channel Leaks in Web Applications: a Reality Today, a Challenge

    Tomorrow

       Shuo Chen (Microsoft Research),

       Rui Wang (Indiana University Bloomington),

       XiaoFeng Wang (Indiana University Bloomington),

       Kehuan Zhang (Indiana University Bloomington)



    Investigation of Triangular Spamming: a Stealthy and Efficient

    Spamming Technique

       Zhiyun Qian (University of Michigan),

       Z. Morley Mao (University of Michigan),

       Yinglian Xie (Microsoft Research Silicon Valley),

       Fang Yu (Microsoft Research Silicon Valley)



    A Practical Attack to De-Anonymize Social Network Users

       Gilbert Wondracek (Vienna University of Technology),

       Thorsten Holz (Vienna University of Technology),

       Engin Kirda (Institute Eurecom),

       Christopher Kruegel (University of California, Santa Barbara)



    SCiFI - A System for Secure Face Identification

       Margarita Osadchy, Benny Pinkas, Ayman Jarrous,

       Boaz Moskovich (University of Haifa)



6:30pm  Special Gala Event

    Celebrating the 30th Anniversary of Security and Privacy

    Master of Ceremonies: Peter G. Neumann



Tuesday, 18 May 2010



9-10:15am    Session 5: Network Security

              Chair: Cristina Nita-Rotaru, Purdue University



    Round-Efficient Broadcast Authentication Protocols for Fixed Topology

    Classes

       Haowen Chan, Adrian Perrig (Carnegie Mellon University)



    Revocation Systems with Very Small Private Keys

       Allison Lewko (University of Texas at Austin),

       Amit Sahai (University of California, Los Angeles),

       Brent Waters (University of Texas at Austin)



    Authenticating Primary Users' Signals in Cognitive Radio Networks via

    Integrated Cryptographic and Wireless Link Signatures

       Yao Liu, Peng Ning, Huaiyu Dai (North Carolina State University)



10:15-10:45  Session 6: Systematization of Knowledge I

              Chair: Z. Morley Mao, University of Michigan



    Outside the Closed World: On Using Machine Learning For Network

    Intrusion Detection

       Robin Sommer (ICSI/Lawrence Berkeley National Laboratory),

       Vern Paxson (ICSI/University of California, Berkeley)



    All You Ever Wanted to Know about Dynamic Taint Analysis and Forward

    Symbolic Execution (but might have been afraid to ask)

       Thanassis Avgerinos, Edward Schwartz,

       David Brumley (Carnegie Mellon University)



    State of the Art: Automated Black-Box Web Application Vulnerability

    Testing

       Jason Bau, Elie Bursztein, Divij Gupta,

       John Mitchell (Stanford University)



1:45-3:00    Session 7: Secure Systems

              Chair: Jonathan McCune, Carnegie Mellon University



    A Proof-Carrying File System

       Deepak Garg, Frank Pfenning (Carnegie Mellon University)



    Scalable Parametric Verification of Secure Systems: How to Verify

    Reference Monitors without Worrying about Data Structure Size

       Jason Franklin (Carnegie Mellon University),

       Sagar Chaki (Carnegie Mellon University),

       Anupam Datta (Carnegie Mellon University),

       Arvind Seshadri (IBM Research)



    HyperSafe: A Lightweight Approach to Provide Lifetime Hypervisor

    Control-Flow Integrity

       Zhi Wang, Xuxian Jiang (North Carolina State University)



3:20-4:10    Session 8: Systematization of Knowledge II

              Chair: Ed Suh, Cornell University



    How Good are Humans at Solving CAPTCHAs? A Large Scale Evaluation

       Elie Bursztein, Steven Bethard, John C. Mitchell,

       Dan Jurafsky (Stanford University), Céline Fabry



    Bootstrapping Trust in Commodity Computers

       Bryan Parno, Jonathan M. McCune,

       Adrian Perrig (Carnegie Mellon University)



4:30-5:30    Short Talks

              Short Talks Chair: Angelos Stavrou, George Mason University



5:45-7:30pm  Reception and Poster Session

              Poster Session Chair: Carrie Gates (CA Labs)



Wednesday, 19 May 2010



9-10:15am    Session 9: Analyzing Deployed Systems

              Chair: J. Alex Halderman, University of Michigan



    Chip and PIN is Broken

       Steven J. Murdoch, Saar Drimer, Ross Anderson,

       Mike Bond (University of Cambridge)



    Experimental Security Analysis of a Modern Automobile

       Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel,

       Tadayoshi Kohno (University of Washington), Stephen Checkoway,

       Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham,

       Stefan Savage (University of California, San Diego)



    On the Incoherencies in Web Browser Access Control Policies

       Kapil Singh (Georgia Institute of Technology),

       Alexander Moshchuk (Microsoft Research),

       Helen J. Wang (Microsoft Research),

       Wenke Lee (Georgia Institute of Technology)



10:45-noon   Session 10: Language-Based Security

              Chair: David Brumley,Carnegie Mellon University



    ConScript: Specifying and Enforcing Fine-Grained Security Policies

    for JavaScript in the Browser

       Leo Meyerovich (University of California, Berkeley),

       Benjamin Livshits (Microsoft Research)



    TaintScope: A Checksum-Aware Directed Fuzzing Tool for Automatic

    Software Vulnerability Detection

       Tielei Wang (Peking University), Tao Wei (Peking University),

       Guofei Gu (Texas A & M University), Wei Zou (Peking University)



    A Symbolic Execution Framework for JavaScript

       Prateek Saxena, Devdatta Akhawe, Steve Hanna, Stephen McCamant,

       Dawn Song, Feng Mao (University of California, Berkeley)



noon-12:15   Closing, Ulf Lindqvist, David Evans, Giovanni Vigna



Thursday, 20 May 2010



Workshops (separate registration required):



* Systematic Approaches to Digital Forensic Engineering

* Workshop on Security and Privacy in Social Networks

* W2SP 2010: Web 2.0 Security & Privacy



------------------------------



Date: Thu, 18 Feb 2010 23:42:37 -0800

From: "Kalin Tyler" <ktyler_at_private>

Subject: FOSE 2010



You are well aware of the challenges we as a CyberSecurity community face

from rapid changes in the technology landscape. FOSE 2010 is the place to

discover opportunities and solutions along with changing expectations for

government IT professionals.



Register today for the FOSE 2010 experience http://www.fose.com. If you sign

up now you also get a 10% discount on a conference pass. You can redeem this

discount here http://cli.gs/FOSE10.



You can expect:



- 3 days of IT resources helping you navigate today's shifting tech landscape

- 2 full conference days packed with education on emerging technologies,

  trends, and new improvements to existing solutions

- Thousands of products on the FREE* EXPO floor allowing you to gain

  one-on-one insight into the capabilities of our exhibitors through demos,

  theater presentations and FREE Education.

- Attend the Accenture CyberSecurity Pavilion or Focus on Digital Forensics.



*FOSE is a must-attend free show for government, military, and government

 contractors.



It's time to register and reserve your place at FOSE today! Visit

http://www.fose.com to learn more about what FOSE has to offer, or redeem

your 10% discount by registering here: http://cli.gs/FOSE10.



Kalin Tyler, ktyler_at_private, FOSE Team/Tuvel Communications



Connect with FOSE

Twitter: http://twitter.com/FOSE

Facebook: http://cli.gs/85RgD5

LinkedIn: http://cli.gs/Vn8mMQ

GovLoop: http://www.govloop.com/group/fose



------------------------------



Date: Thu, 29 May 2008 07:53:46 -0900

From: RISKS-request_at_private

Subject: Abridged info on RISKS (comp.risks)



 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.

=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)

 if possible and convenient for you.   The mailman Web interface can

 be used directly to subscribe and unsubscribe:

   http://lists.csl.sri.com/mailman/listinfo/risks

 Alternatively, to subscribe or unsubscribe via e-mail to mailman

 your FROM: address, send a message to

   risks-request_at_private

 containing only the one-word text subscribe or unsubscribe.  You may

 also specify a different receiving address: subscribe address= ... .

 You may short-circuit that process by sending directly to either

   risks-subscribe_at_private or risks-unsubscribe_at_private

 depending on which action is to be taken.



 Subscription and unsubscription requests require that you reply to a

 confirmation message sent to the subscribing mail address.  Instructions

 are included in the confirmation message.  Each issue of RISKS that you

 receive contains information on how to post, unsubscribe, etc.



=> The complete INFO file (submissions, default disclaimers, archive sites,

 copyright policy, etc.) is online.

   <http://www.CSL.sri.com/risksinfo.html>

 The full info file may appear now and then in RISKS issues.

 *** Contributors are assumed to have read the full info file for guidelines.



=> .UK users should contact <Lindsay.Marshall_at_private>.

=> SPAM challenge-responses will not be honored.  Instead, use an alternative

 address from which you NEVER send mail!

=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.

 *** NOTE: Including the string "notsp" at the beginning or end of the subject

 *** line will be very helpful in separating real contributions from spam.

 *** This attention-string may change, so watch this space now and then.

=> ARCHIVES: ftp://ftp.sri.com/risks for current volume

     or ftp://ftp.sri.com/VL/risks for previous VoLume

 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive

 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.

   Lindsay has also added to the Newcastle catless site a palmtop version

   of the most recent RISKS issue and a WAP version that works for many but

   not all telephones: http://catless.ncl.ac.uk/w/r

 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .

==> PGN's comprehensive historical Illustrative Risks summary of one liners:

    <http://www.csl.sri.com/illustrative.html> for browsing,

    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing

==> Special Offer to Join ACM for readers of the ACM RISKS Forum:

    <http://www.acm.org/joinacm1>



------------------------------



End of RISKS-FORUM Digest 25.95

************************



Received on Sun Feb 28 2010 - 06:03:14 PST





]]>
Sun, 28 Feb 2010 6:03:14 PST
RISKS List Owner



http://lists.jammed.com/RISKS/2010/01/0003.html






From: RISKS List Owner <risko_at_private>




Date: Tue, 26 Jan 2010 16:38:04 PST






RISKS-LIST: Risks-Forum Digest  Tuesday 26 January 2010  Volume 25 : Issue 92



ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy



***** See last item for further information, disclaimers, caveats, etc. *****

This issue is archived at <http://www.risks.org> as

  <http://catless.ncl.ac.uk/Risks/25.92.html>

The current issue can be found at

  <http://www.csl.sri.com/users/risko/risks.txt>



  Contents:

*NY Times* expose on medical radiation overexposure (Jeremy Epstein)

Air-traffic control glitch due to the installation of new software

  (Chiaki Ishikawa)

Extending TCP/IP into space (Randall Webmail)

Y2K+10 and SMS (Richard Gadsden)

Bodyscanners that don't work (Peter Houppermans)

Corporate espionage in the news: Hilton and the Oil industry (Gadi Evron)

Have the Chinese Really Hacked into MSN's DB? (Chris J Brady)

Cyberattacks on Google in China (PGN)

Unsearchable stores (Mark Brader)

ICSI claims "effectively perfect" spam blocking method (Lauren Weinstein)

LORAN being retired (David Magda)

PROVINCE OF CHI (jidanni)

Google Maps won't be taking my address for a ride (jidanni)

Upgrading a World of Warcraft account ends in tears (Turgut Kalfaoglu)

Unique PINs (Dag-Erling Smørgrav)

Re: Offensive shutting down of botnets (Dick Mills)

Cloud Computing Security (Ivan Arce)

Abridged info on RISKS (comp.risks)



----------------------------------------------------------------------



Date: Sat, 23 Jan 2010 23:25:21 -0500

From: Jeremy Epstein <jeremy.j.epstein_at_private>

Subject: NY Times expose on medical radiation overexposure



There's nothing here that's akin to the infamous Therac disasters where

interactions of hardware and software caused unexpected results, but more

examples of how wrong configurations lead to dramatic radiation

overexposures.  "The Times found that on 133 occasions, devices used to

shape or modulate radiation beams [...] were left out, wrongly positioned or

otherwise misused."  But there were also software errors - crashes that lost

portions of the programming for the radiation beams.  "as [the medical

physicist] was trying to save her work, the computer began seizing up,

displaying an error message.  The hospital would later say that similar

system crashes 'are not uncommon with the Varian software, and these issues

have been communicated to Varian on numerous occasions.'  [...] At 12:57

p.m. -- six minutes after yet another computer crash -- the first of several

radioactive beams was turned on."  In another case, "One therapist

mistakenly programmed the computer for 'wedge out' rather than 'wedge in,'

as the plan required. Another therapist failed to catch the error. And the

physics staff repeatedly failed to notice it during their weekly checks of

treatment records. Even worse, therapists failed to notice that during

treatment, their computer screen clearly showed that the wedge was

missing. Only weeks earlier, state health officials had sent a notice,

reminding hospitals that therapists 'must closely monitor' their computer

screens."



The problem was lack of fail-safe processes.  "The software required

that three essential programming instructions be saved in sequence:

first, the quantity or dose of radiation in the beam; then a digital

image of the treatment area; and finally, instructions that guide the

multileaf collimator. When the computer kept crashing, [...] the

medical physicist, did not realize that her instructions for the

collimator had not been saved, state records show. She proceeded as

though the problem had been fixed. "



It's a pretty frightening article.

http://www.nytimes.com/2010/01/24/health/24radiation.html?hp



  [The article spans the middle of the front page and three inside pages.

  It's well worth reading in its entirety.  I also received comments on this

  from Jared Gottlieb, Harry Hochheiser, Matthew Kruk, Nancy Leveson, Martyn

  Thomas, and others.  See recent harbingers (RISKS-25.81,82) of the current

  round of events, as well as the earlier items on the Therac-25 problems

  (RISKS-8.5, 12.50, 14.04).  PGN]



------------------------------



Date: Thu, 21 Jan 2010 18:19:59 +0900

From: ishikawa <ishikawa_at_private>

Subject: Air-traffic control glitch due to the installation of new software



http://www.airportbusiness.com/online/article.jsp?siteSection=1&id=33648



Air-traffic control glitch due to the installation of new software



Air-traffic control software problem (airplane positions could not be

identified in a timely manner) caused the disruption of air flights in Japan

on 14 Jan 2010.



This happened after the installation of new software that consolidated the

air-traffic control operations of two large and busy airports, Haneda and

Narita.  The program controls the radar screen displays for the

controllers. Due to a software problem, the display on the screen got

sluggish to the point that the operators switched to a backup system and

operators diverted to traffic to other airports and such.



On 15 Jan 2010, the official announcement was made by the Ministry of Land,

Transport, Infrastructure and Tourism that the climate information,

especially bad weather, was mistakenly fed to the module of the control

program that display the positions of airplanes in this new software

setup. This caused overload of processing, and thus the failure to keep

track of the airplanes timely.



This incorporation of the bad weather is a new feature according to the

short announcement made by the minister in charge.



Usual risk. But I really wonder why this was not caught in advance testing.



The unwanted climate data by the position display module was silently thrown

away without no logging? If the bad weather was properly reflected on the

screen by the feed to the proper module (assuming the testing was done for

the display of bad weather condition on radar), then the data was duplicated

by mistake and fed to the airplane position display module, also?  Why and

how?



Inquiring minds want to know more.



I really wish that there is a public database of software bugs that caused

social glitches like this one and that record details for posterity for the

benefit of future programmers, etc. I suspect such a database will be a

loath to parties in the legal tangling as the result of such bugs, but the

society needs such a database, I think.  We need better foundation and not

try to build sand castles from scratch again and again with similar mistakes

in the foundation.



(This incident has nothing to do with the bankruptcy filing of Japan Air

Lines recently.)



------------------------------



Date: January 22, 2010 11:16:07 AM EST

From: Randall Webmail <rvh40_at_private>

Subject: Extending TCP/IP into space (From Dave Farber's IP)



NASA EXTENDS THE WORLD WIDE WEB OUT INTO SPACE



Astronauts aboard the International Space Station received a special

software upgrade this week - personal access to the Internet and the World

Wide Web via the ultimate wireless connection.



Expedition 22 Flight Engineer T.J. Creamer made first use of the new system

[on 22 Jan 2010], when he posted the first unassisted update to his Twitter

account, @Astro_TJ, from the space station. Previous tweets from space had

to be e-mailed to the ground where support personnel posted them to the

astronaut's Twitter account.



"Hello Twitterverse! We r now LIVE tweeting from the International

Space Station -- the 1st live tweet from Space! :) More soon, send

your ?s"



This personal Web access, called the Crew Support LAN, takes advantage of

existing communication links to and from the station and gives astronauts

the ability to browse and use the Web. The system will provide astronauts

with direct private communications to enhance their quality of life during

long-duration missions by helping to ease the isolation associated with life

in a closed environment.



During periods when the station is actively communicating with the ground

using high-speed Ku-band communications, the crew will have remote access to

the Internet via a ground computer. The crew will view the desktop of the

ground computer using an onboard laptop and interact remotely with their

keyboard touchpad.



Astronauts will be subject to the same computer use guidelines as government

employees on Earth. In addition to this new capability, the crew will

continue to have official e-mail, Internet Protocol telephone and limited

videoconferencing capabilities.



To follow Twitter updates from Creamer and two of his crewmates, ISS

Commander Jeff Williams and Soichi Noguchi, visit:

  http://twitter.com/NASA_Astronauts



For more information about the space station, visit:

  http://www.nasa.gov/station



Archives: https://www.listbox.com/member/archive/247/=now



  [Well, that may be just a little more secure than an early desire for the

  space station that I heard when I visited Johnson Space Center long ago,

  which was that researchers should be able to uplink over the Internet to

  the Space Station control computer and monitor and guide their own

  experiments in real time.  PGN]



------------------------------



Date: Thu, 21 Jan 2010 14:21:01 +0000

From: Richard Gadsden <richard_at_private>

Subject: Y2K+10 and SMS



The timestamp on SMS messages (known as TP-SCTS) stores the year in two

nibbles in a binary-coded decimal representation with the nibbles swapped.



Aside from the known risks of using a two-digit year, this is about as bad a

representation as can be imagined.  2009 is represented as 1001 0000 in BCD

swapped-nibble (i.e., as 09, decimal). 2010 (decimal) is represented as 0000

0001.



A number of telephone SMS programs, generally those that don't inherit a

code-base from pre-Y2K systems, have misread the spec, and are interpreting

it as swapped-nibble binary, rather than BCD, so are interpreting 0000 0001

as 00010000, i.e., as 0x10 or 16 instead of 10.  This is why some phones

(notably Windows Mobiles) are displaying text messages as having been sent

in 2016, rather than 2010.



It's worthy of note that these systems would not have worked correctly in

1999 either - they would have interpreted 0x99 as 153 (decimal) - and may

have displayed either 19153 or 2053.



In the specific case of Windows Mobile, the text message database stores two

dates, the TP-SCTS date and an internal datestamp applied to the text when

received by the phone.  There is a setting in the firmware that allows the

internal datestamp to be shown in preference to the TP-SCTS date, so some

phones are showing the correct information and some are not.  This setting

is set by the firmware programmer, normally being either the manufacturer or

the network operator.



RISKS:



Date code written after 2000 may display Y2K-like bugs, by making

assumptions that all dates are post-2000.



Programs installed in firmware are much more difficult to correct for bugs,

so code quality for firmware is much more important.



Systems are frequently coded to a small set of sample data, rather than to

the actual specification.  Checking against the specification rather than

unit testing with sample data is harder, but may be necessary, especially

for systems that are difficult to correct.



Richard Gadsden    richard_at_private



  [The authors of the post-Y2K phone software have obviously never heard The

  Ring of the Nibble-Young-un (Wagner).  It's worthy of a Ring-Tone-Poem

  (Strauss).  PGN]



------------------------------



Date: Sun, 24 Jan 2010 14:22:55 +0100

From: Peter Houppermans <peter_at_private>

Subject: Bodyscanners that don't work



Interesting article in The Register about a full body scanner demo on German

live TV demo.  You guessed: it would not be news unless the thing had failed

to detect some Very Bad Stuff.



You may want to watch the video, it's in German but I think you will be able

to see that the key message is that the man scanned was carrying more than

what he originally mentioned:



http://www.theregister.co.uk/2010/01/24/body_scanner_fail/



Keep watching - he will use the stuff that wasn't picked up, just to prove

the point (notice that he almost ruins a camera when he stirs the remains).

I hope these scanners won't lure security staff into a false sense of

security, and wonder how the use of these expensive devices will pan out in

real life use.  We'll soon see.



Speaking of pan - no idea of correlation between frying pan material and

what is used for a plane hull..



------------------------------



Date: Tue, 26 Jan 2010 08:53:07 +0200

From: Gadi Evron <ge_at_private>

Subject: Corporate espionage in the news: Hilton and the Oil industry



Corporate espionage in the news, and not just because of Google: Hilton and

the Oil industry. Is anyone calling espionage by means of computers

cyber-espionage yet? I hope not. At least they shouldn't call it cyber war.



Two news stories of computerized espionage reached me today.



The first, regarding the Oil industry, was sent by Marc Sachs to a SCADA

security mailing list we both read. The second, about the hotel industry,

was sent by Deb Geisler to science fiction convention runners (SMOFS)

mailing list we both read.



US oil industry hit by cyberattacks: Was China involved?

http://www.csmonitor.com/USA/2010/0125/US-oil-industry-hit-by-cyberattacks-Was-China-involved



  "At least three US oil companies were the target of a series of previously

  undisclosed cyberattacks that may have originated in China and that

  experts say highlight a new level of sophistication in the growing global

  war of Internet espionage."



Starwood Charges That Top Hilton Execs Abetted Espionage

http://www.meetings-conventions.com/article_ektid31918.aspx



  "Starwood's claim points to a "mountain of undisputed evidence," including

  e-mails among Hilton senior management, that Klein and Lalvani worked with

  others within Starwood to steal sensitive documents by sending them via

  personal e-mail accounts, among other methods, and that such information

  was shared and used by all of Hilton's luxury and lifestyle brands, as

  well as in the development of Hilton's now-shelved Denizen brand. In the

  new filing, Starwood says, "This case is extraordinary, and presents the

  clearest imaginable case of corporate espionage, theft of trade secrets,

  unfair competition and computer fraud...Hilton's conduct is outrageous.""



As to whether China is involved, maybe. But the automatic blaming has got to

stop. Many other countries have been known to be conducting corporate

espionage, such as France, and as the second story above shows, so do

corporations themselves.



[ Source on naming France: http://samvak.tripod.com/pp144.html ]



But.. here are a few questions:



- My dog barked, was China involved?

- The traffic light turned red, was China involved?

- I am tired. Is China involved?



------------------------------



Date: Wed, 20 Jan 2010 06:04:14 -0800 (PST)

From: Chris J Brady <chrisjbrady_at_private>

Subject: Have the Chinese Really Hacked into MSN's DB?



Seen in a forum on LoveMoney.com:



"There is a new scam today offering cheap goods from China. They probably

don't exist and they have hacked accounts, it appears they are in the MSN

database. Anyone with hotmail or live.com accounts should change their

passwords. This may be in the wrong thread. We are trying to figure out what

they are doing. It looks like a major operation hacking from China."



Is the risk believing that there is a risk here, or is there more of a risk

in ignoring it? Hmm ... but the Chinese do seem to be gaining a reputation

for hacking.



------------------------------



Date: Tue, 19 Jan 2010 16:21:02 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Cyberattacks on Google in China



Google has uncovered a "highly sophisticated and targeted attack" coming from

China on its infrastructure that resulted in some of its intellectual

property being stolen.  The cited article suggests that at least 20

technology companies were similarly targeted (and more than 30, according to

other reports).

  http://www.computerworld.com/s/article/9145679/



In addition, *The Jewish Chronicle* website (thejc.com) was recently

defaced.

  http://www.theregister.co.uk/2010/01/18/jc_defaced/



See also John Markoff, David E. Sanger, Thom Shanker, "In Digital Combat,

U.S. Finds No Easy Deterrent, *The New York Times*, 26 Jan 2010, A1/A6

today's National Edition.



------------------------------



Date: Sun, 24 Jan 2010 17:06:43 -0500 (EST)

From: msb_at_private (Mark Brader)

Subject: Unsearchable stores



Tangentially to recent thread in alt.usage.english, Cheryl Perkins

made a comment about how programmers dealing with addresses "don't

like apostrophes" and "don't allow for their existence".  John Varela

then wrote this (quoted by permission) about his TomTom One 130:



| I ran into that today when I wanted the GPS to take me to a store

| called "Lowe's".  There's no way to enter an apostrophe on the GPS.

| A search for "Lowe" found nothing and a search for "Lowes" found a

| store called "Lowest Price something-or-other".  I had to find the

| place on my own.  Doing so gave me a real feeling of independence

| and of superiority to technology.



Mark Brader, Toronto, msb_at_private | "Fast, cheap, good: choose any two."



  [Lowe'stcommon denominator?  PGN]



------------------------------



Date: January 25, 2010 6:51:19 PM EST

From: Lauren Weinstein <lauren_at_private>

Subject: ICSI claims "effectively perfect" spam blocking method



``Researchers have now come up with a system that deciphers the templates a

botnet is using to create spam.  These templates are then used to teach spam

filters what to look for.''



  [Maybe "effectively perfect" against that specific type of attack *at this

  point in the development of spam*.  Just ask Darwin.]

    http://bit.ly/7GwsVx  (New Scientist)

      [From the Network Neutrality Squad, http://www.nnsquad.org]



------------------------------



Date: Thu, 21 Jan 2010 09:00:27 -0500

From: David Magda <dmagda_at_private>

Subject: LORAN being retired



The U.S. Coast Guard has announced that it will begin turning off the

Loran-C navigation system on February 8, 2010, with a full decommissioning

by October 1, 2010:



http://www.access.gpo.gov/su_docs/fedreg/a100107c.html#Coast%20Guard

http://yro.slashdot.org/article.pl?sid=10/01/12/223241



While some people have said that GPS has made it redundant, critics of the

decision have said that having redundancy / backups is entirely the

point. The "Federal Register" statement implies that this concern is not

very pressing:



> The Loran-C system was not established as, nor was it intended to be, a

> viable systemic backup for GPS. Backups to GPS for safety-of-life

> navigation applications, or other critical applications, can be other

> radio-navigation systems, or operational procedures, or a combination of

> these systems and procedures. Backups to GPS for timing applications can

> be a highly accurate crystal oscillator or atomic clock and a

> communications link to a timing source that is traceable to Coordinated

> Universal Time.



http://edocket.access.gpo.gov/2010/2010-83.htm



Not sure what these other navigation systems would be (e.g., WAAS "augments"

GPS, not replaces it). For time a least, WWVB is available in large portion

of the continental U.S.



http://en.wikipedia.org/wiki/Wide_Area_Augmentation_System



Other countries have their own LORAN towers, and it remains to be seen how

this will affect them:



http://en.wikipedia.org/wiki/LORAN



------------------------------



Date: Mon, 11 Jan 2010 02:18:46 +0800

From: jidanni_at_private

Subject: PROVINCE OF CHI



Fidelity.com is where I keep my retirement millions. A few days after a

cordial address update I double checked to find it had become a mangled

DONGSHI 42351 PROV-INCE OF CHI TAIWAN behind both my and staff's backs.

In order to please neighboring China, their run a batch job that alters

all Taiwan addresses. It then took much staff effort whack mine back

into shape.



Jackson.com is where I keep my other millions. Foreign customers have a

pseudo-state of "OT" appended to their addresses. It used to be "OC" but

that probably landed mail into an even darker hole at the post office.



------------------------------



Date: Tue, 26 Jan 2010 07:30:24 +0800

From: jidanni_at_private

Subject: Google Maps won't be taking my address for a ride



Ah, the amazing ability of http://maps.google.com/ to pinpoint

anything one tosses into its search box.



Let's just change this search string from house number 21, to e.g., 22:

http://maps.google.com/maps?f=q&hl=en&q=21+DaGuan+RD+%E5%A4%A7%E8%A7%80%E8%B7%AF21%E8%99%9F%2C+Taichung%2C+Taiwan

http://maps.google.com/maps?f=q&hl=en&q=22+DaGuan+RD+%E5%A4%A7%E8%A7%80%E8%B7%AF22%E8%99%9F%2C+Taichung%2C+Taiwan



Whammo... for #21 all along Google was merely matching a text string

attached to a story associated with a point in their database. For #22

etc. Google Maps says "We could not understand the location."



If one has a Facebook account, here I am telling the business owner their

new address finds a point (stuck to their old address (mentioning their new

address.))

http://www.facebook.com/permalink.php?story_fbid=253295461155&id=12619981155



Me? I'm at http://maps.google.com/maps?ll=24.181699,120.866261.

No text strings to get hijacked by pagerank.



------------------------------



Date: Wed, 20 Jan 2010 11:04:54 +0200

From: Turgut Kalfaoglu <turgut_at_private>

Subject: Upgrading a World of Warcraft account ends in tears



My son and I have something in common: We love the online game Warcraft.  We

are separated by a continent as he lives with his mother, but we still meet

online through this game.



For those who are not familiar, it consists of a 5GB game download, followed

by numerous similarly-sized updates, and finally being able to play (and pay

monthly) online.



We recently attempted to upgrade our gaming accounts to their new "Wrath of

Leech King" expansion - it was suppose to be a Christmas present for him.

So I entered their web site, gave my credit card details, clicked

upgrade. It promptly said congratulations, and that the account was

upgraded.



A day later, we got another e-mail saying that the purchase was "undone" and

the game upgrade was rolled back. No details were given, but we were given a

hint that we should phone them.  That simple task of phoning them took three

days of non-stop phoning from overseas: Their UK help desk was so

swamped/understaffed that I could not get in their waiting queue.  When I

did, I was dropped off after waiting 9 minutes on the phone.  It eventually

turned out that my security-conscious son had not entered his correct name

and address when signing up to the service some years back, and apparently

only during the upgrade that Blizzard bothers to check these things.



After a successful phone call to their help desk, we were sent a

questionnaire to fill out to correct the details.  However, even after the

details were entered into their system, we were STILL denied the

upgrade. Reason? As far as I can tell, it was their security system again:

It will not let you "upgrade" twice from the same IP address!



Since according to their records, we had one "successfully" upgraded, we

were now denied an upgrade!



After numerous fruitless e-mails, I finally re-re-re-did the registration

from a work computer, and it went through, and it became a late new year

present for my son instead.



Moral of the story:

  1) You must reveal your complete identity if you want to play games,

  2) Your request must not look like it's coming from a sweatshop in China.



And you thought playing online games was all fun and games?



Turgut Kalfaoglu, Msc. Computer Engineering, Izmir Institute of Technology



------------------------------



Date: Wed, 20 Jan 2010 11:51:22 +0100

From: Dag-Erling Smørgrav <des_at_private>

Subject: Unique PINs



A number of municipal cinemas in larger Norwegian cities have a common

fidelity program called Kinosonen ("the cinema zone").  Amongst other

benefits, members get a card they can use to prepay tickets (at a discount,

of course).



A few days ago, two e-mails were sent out to program members.  The first

e-mail enjoined all members to change their PIN as quickly as possible "for

security reasons".  All well and good.  The second...  The second said,

loosely translated:



  We have been notified of a flaw in our procedures, and have asked all our

  members to change their PIN.  Several members have been issued the same

  PIN for their membership cards.  As many as 1200 cards may be affected.

  This only applies to cards issued after 2007-11-25.  We are in the process

  of changing the PIN for those 1200 members.  You will receive a new PIN by

  e-mail.



So...  am I to conclude that the security of their system depends on each

member's PIN being unique?  The mind boggles.  If so, why do they ask

members to select their own PIN?  What happens if a member selects a PIN

that is already in use - does she get a message to that effect?  So now she

knows that somebody else uses that PIN, can she take advantage of that

knowledge?  If not, why are duplicate PINs a problem in the first place?



I'm not sure how long the PIN is, by the way, but my guess is four or five

digits.  The total population of these cities and their suburbs is around

two million people.  Even with conservative estimates of their membership

base, latecomers are going to have a hell of a time trying to find an unused

PIN.  Even with six digits, the odds are that a lot of people are going to

use either their birth date or the last six digits of their 12-digit card

number...



------------------------------



Date: Thu, 21 Jan 2010 09:14:38 -0500

From: Dick Mills <dickandlibbymills_at_private>

Subject: Re: Offensive shutting down of botnets



It seems foreseeable that someday a mass cutoff of botnet infected computers

will trigger some kind of disastrous side effect.



Of course, mission critical or life critical applications should never be

allowed to exists on unprotected net connected computers, especially those

infected by malware.  Nevertheless, it would be foolish to presume that

nobody else is ever foolish.



Here's the risk.  We may know that a mass collection of computers are

hosting malware, but we have no way of knowing what good and vital services

they may also be providing.  Is it not true therefore, that any action to

remotely cut off a class of nodes is somewhat reckless by nature.



  [Old whine in new bot-tles?  PGN]



------------------------------



Date: Sat, 23 Jan 2010 18:24:12 -0200

From: Ivan Arce <ivan.arce_at_private>

Subject: Cloud Computing Security



We have a special issue on Security in Cloud Computing scheduled for

publication in Nov/Dec 2010.  The final date for submissions is approaching

(5 Mar 2010). and The Call for Papers is here:

  http://www.computer.org/portal/web/computingnow/spcfp6



------------------------------



Date: Thu, 29 May 2008 07:53:46 -0900

From: RISKS-request_at_private

Subject: Abridged info on RISKS (comp.risks)



 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.

=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)

 if possible and convenient for you.   The mailman Web interface can

 be used directly to subscribe and unsubscribe:

   http://lists.csl.sri.com/mailman/listinfo/risks

 Alternatively, to subscribe or unsubscribe via e-mail to mailman

 your FROM: address, send a message to

   risks-request_at_private

 containing only the one-word text subscribe or unsubscribe.  You may

 also specify a different receiving address: subscribe address= ... .

 You may short-circuit that process by sending directly to either

   risks-subscribe_at_private or risks-unsubscribe_at_private

 depending on which action is to be taken.



 Subscription and unsubscription requests require that you reply to a

 confirmation message sent to the subscribing mail address.  Instructions

 are included in the confirmation message.  Each issue of RISKS that you

 receive contains information on how to post, unsubscribe, etc.



=> The complete INFO file (submissions, default disclaimers, archive sites,

 copyright policy, etc.) is online.

   <http://www.CSL.sri.com/risksinfo.html>

 The full info file may appear now and then in RISKS issues.

 *** Contributors are assumed to have read the full info file for guidelines.



=> .UK users should contact <Lindsay.Marshall_at_private>.

=> SPAM challenge-responses will not be honored.  Instead, use an alternative

 address from which you NEVER send mail!

=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.

 *** NOTE: Including the string "notsp" at the beginning or end of the subject

 *** line will be very helpful in separating real contributions from spam.

 *** This attention-string may change, so watch this space now and then.

=> ARCHIVES: ftp://ftp.sri.com/risks for current volume

     or ftp://ftp.sri.com/VL/risks for previous VoLume

 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive

 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.

   Lindsay has also added to the Newcastle catless site a palmtop version

   of the most recent RISKS issue and a WAP version that works for many but

   not all telephones: http://catless.ncl.ac.uk/w/r

 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .

==> PGN's comprehensive historical Illustrative Risks summary of one liners:

    <http://www.csl.sri.com/illustrative.html> for browsing,

    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing

==> Special Offer to Join ACM for readers of the ACM RISKS Forum:

    <http://www.acm.org/joinacm1>



------------------------------



End of RISKS-FORUM Digest 25.92

************************



Received on Tue Jan 26 2010 - 16:38:04 PST





]]>
Tue, 26 Jan 2010 16:38:04 PST
RISKS List Owner



http://lists.jammed.com/RISKS/2009/12/0000.html






From: RISKS List Owner <risko_at_private>




Date: Mon, 14 Dec 2009 16:43:00 PST






RISKS-LIST: Risks-Forum Digest  Monday 14 December 2009  Volume 25 : Issue 86



ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy



***** See last item for further information, disclaimers, caveats, etc. *****

This issue is archived at <http://www.risks.org> as

  <http://catless.ncl.ac.uk/Risks/25.86.html>

The current issue can be found at

  <http://www.csl.sri.com/users/risko/risks.txt>



  Contents:

Stryker Operating Room System II Surgical Navigation System recall

  (Richard Cook)

Northwest Flight 188 (Curt Sampson)

Chase Quicken and MS Money bill pay broken for 2 weeks, no fix ETA

  (John Rivard)

UK Digital Economy Bill -- Blocking Illegal Downloaders (Chris D.)

Massive New UK Internet Wiretapping Plan Announced (Lauren Weinstein)

Public servant fired over leak of private info of 14,000 (Gene Wirchenko)

Farmer claims GPS led him to breed clams in the wrong place (Rob McCool)

My mother regarding LED traffic lights and Wisconsin winters (Richard Cook)

Were you talkin' to me? (Jerry Leichter)

All the best efforts gone to naught... (Jeremy Epstein)

Various Internet Issues, Succinctly Put (Peter Ladkin)

Re: The Joy of satellite navigation failures (Jerry Leichter)

Abridged info on RISKS (comp.risks)



----------------------------------------------------------------------



Date: Sun, 29 Nov 2009 20:09:05 -0600

From: Richard Cook <ri-cook_at_private>

Subject: Stryker Operating Room System II Surgical Navigation System recall



MedWatch - Stryker Operating Room System II Surgical Navigation System:

Recall due to potential for the navigation PC SPC-1 component to stop

working which could result in potential harms associated with this failure

 href="http://service.govdelivery.com/service/w3c/p3p.xml"



First known recall of a computer-based surgical positioning system.



Most surgical intervention takes place under direct observation. In these

"open" procedures, the surgeon sees the anatomy and moves an instrument

(e.g. scissors) under direct vision. The product line involved in this

recall includes a positioning product that allows procedures to be performed

under indirect observation. These instruments allow the surgeon to operate

on deep, hidden structures in close proximity to critical points, e.g. in

the sinuses close to the thin bone that separates them from the brain.



The principle of operation is straightforward. Prior to the surgical

procedure, a computed scan (e.g. spiral CT) is obtained while the patient

wears a locater fiduciary, typically a headpiece that incorporates several

easy to identify points. The patient wears the same device during

surgery. The scan is imported into an operating room system that includes an

array of sensors capable of detecting and triangulating the location of the

fiduciary, special instruments that register with the sensors, and a high

quality display that shows patient anatomy and instrument

location. Depending on the application, the representation may be multiple

"flat" cross-sections or a 3D reconstruction. The system displays the

patient anatomy along with the location of the instruments in realtime&nbsp;

The display is updated frequently to track the location of the instrument as

it moves through the patient. This allows the surgeon to move the tip of the

instrument and accomplish the surgical intervention by watching a

representation rather than under direct observation.



There are a variety of such instruments available for different

applications. For neurovascular procedures, the system can use a contrast

enhanced computed tomogram to map the arterial vascular tree in the head and

then by digital subtraction to remove the non-vascular structures to allow

realtime 3D display so that aneurysms can be embolized. The advantage of

such an approach is that it entirely eliminates the need for a surgical

craniotomy with its attendant risks, allowing the procedure to be

accomplished from "the inside".



The failure of this type of instrument would certainly get attention.

The "Dear Doctor" letter (http://www.stryker.com/en-us/139059)

notes that the system failure could result in:



  ``delay in surgery, reschedule of the procedure resulting in an additional

  surgery, risk of infection, increased morbidity, potential neurological

  deficits, or injury due to the surgeon operating in an area where they did

  not intend to operate. Depending on the type of surgery, these failures

  could potentially lead to serious adverse health consequences, including

  death. There have been no reports of injury.''



Based on the description of the failure and the specific serial numbers

of instruments included in the recall, it is possible that the sensors

are not detecting reliably the fiduciary or the instruments being used.

Software faults are also possible, of course; the application, while

simple in theory, is complicated in implementation.



The FDA recall notice:

MedWatch - The FDA Safety Information and Adverse Event Reporting Program

Stryker Operating Room System II Surgical Navigation System: Recall due to

potential for the navigation PC SPC-1 component to stop working...



*Audience:* Hospital risk managers, surgical service managers



Stryker and FDA notified healthcare professionals of a recall of 23

Operating Room System II Surgical Navigation Systems because there is a

potential for the navigation PC SPC-1 component to stop working which

could result in the screen freezing, the system updating at a slow

rate, or not responding at all. The Navigation System II is a computer

aided surgery platform that surgeons can use to perform Hip, Knee,

Spine, Neuro and ENT surgical procedures and contains a computer

workstation with the navigation System II software and various

components necessary to run the system.The potential harms associated

with this failure are: delay in surgery, reschedule of the procedure

resulting in an additional surgery, risk of infection, increased

morbidity, potential neurological deficits, or injury due to the

surgeon operating in an area where they did not intend to operate.

Depending on the type of surgery, these failures could potentially lead

to serious adverse health consequences, including death. Hospitals that

have product that corresponds to the catalog numbers above should

immediately quarantine the product, label it as a recalled product and

stop using the product.



Read the complete MedWatch 2009 Safety summary including a link to the

firm press release, at:

<a class="moz-txt-link-freetext" href="http://www.fda.gov/Safety/MedWatch/SafetyInformation/SafetyAlertsforHumanMedicalProducts/ucm192105.htm">http://www.fda.gov/Safety/MedWatch/SafetyInformation/SafetyAlertsforHumanMedicalProducts/ucm192105.htm</a>



Richard I. Cook, MD, Associate Professor, Department of Anesthesia and

Critical Care, University of Chicago, <href="http://www.ctlab.org">



------------------------------



Date: Tue, 8 Dec 2009 02:24:07 +0900

From: Curt Sampson <cjs_at_private>

Subject: Northwest Flight 188



A blogger has posted what he says are "excerpts of an e-mail I received from

a fellow airline pilot. It is a summary of another pilot's conversation with

Tim Cheney, the Captain of NW Flight 188, that overflew MSP."



  http://thedonovan.com/archives/2009/11/about_that_nort.html



It's hard to tell the veracity of this report, given that it's a friend of a

friend thing, but it sounds quite plausible. Here's a summary.



The flight had a 100 knot tailwind that appears to have shortened travel

time considerably. (Though they left San Diego 35 minutes late due to an ATC

flow restriction, even after overflying their destination, they arrived only

15 minutes late.)



After passing Denver, the captain left the cockpit to go to the toilet.

While he was out, the first officer (FO) received ATC instructions to move

to a new frequency. However, for whatever reason, the FO changed to Winnipeg

ATC rather than the correct frequency for Denver Center.  Normally this

would be caught quickly, but the FO apparently did not confirm

communications on the new frequency. (Had he done so, and realized that he

was talking to the wrong ATC, the standard procedure would be to go back to

the previous frequency and confirm the new frequency he was being directed

to use.)



When the captain returned, the FO neglected to inform the captain of this

change. Because there was chatter on the frequency, the captain didn't

realize that they were not talking to the ATC that was supposed to be

controlling them. When Denver Center couldn't contact the flight, they did

have the airline send an ACARS message to the flight, but on the Airbus 320

apparently there's no audible signal upon receipt of an ACARS message, just

a light that turns on for thirty seconds and turns off again.



During this time, the captain mentioned that he was unhappy with the

scheduling software, which was new to him, being Delta's software and he

being a Northwest pilot. The FO offered to help, and they spent perhaps five

minutes with laptops out dealing with this.



Then,



  The F/As called the cockpit on the interphone...and asked when they will

  get there. They looked at their nav screens and were directly over MSP

  [the Minneapolis-Saint Paul International Airport].



  Because they had their screens set on the max 320 nm setting, when the F/O

  called on the frequency, which of course was Winnipeg Center, he saw Eau

  Claire and Duluth on his screen. They asked where they were and the F/O

  told them over Eau Claire, which was not even close, but MSP had

  disappeared from the screen even though they were right over the city. ...



  They were, as you all know, vectored all over the sky to determine if they

  had control of the a/c and Tim kept telling the F/O to tell them they have

  control, they want to land at MSP, etc. They landed with 11,000 pounds of

  fuel (no, they did not come in on fumes, but had 2 hours in an A320)....



------------------------------



Date: Mon, 30 Nov 2009 10:10:00 -0500

From: John Rivard <jcr_at_private>

Subject: Chase Quicken and MS Money bill pay broken for 2 weeks, no fix ETA



I just got off the phone with a customer service agent at Chase online

support.



I was attempting to discover why electronic payments sent via the Quicken

desktop application are failing with an error code. The error message

recommends trying again later, and contacting your financial institution if

the problem does not go away.



The phone agent I spoke to said that since an upgrade to their system two

weeks ago, both Quicken and Microsoft Money payments have been failing. Yes,

you read that correctly, Chase is aware that this problem has been occurring

for two weeks, but instead of notifying users of this by phone or e-mail (or

even snail mail, since it has been two weeks), they have been waiting for

them to call in, navigate the phone tree, and wait on hold to talk to an

agent.



Perhaps they have delayed informing users directly because they have no idea

how to fix the problem. The agent also stated that there was no estimate

available for when this problem. I was fairly incredulous, and pressed if

there was any order-of-magnitude estimate available: would it be fixed in

hours, days, another two weeks? There is no estimate available at all.



------------------------------



Date: Sat, 28 Nov 2009 19:51:49 +0000

From: "Chris D." <e767pmk_at_private>

Subject: UK Digital Economy Bill -- Blocking Illegal Downloaders



There have been reports in the news this week (late Nov 2009) about the UK

Government's Digital Economy Bill which has started its course through

Parliament.  The main concern for RISKS readers is most likely the

requirement for ISPs to throttle or suspend broadband connections for

"persistent" illegal file-sharers and pass details over to copyright

holders.  I haven't seen anything about how such criminals are supposed to

be identified or who arbitrates in the event of a dispute, but obviously it

will all have to be paid for, and news reports comment that if ISPs have to

start up whole departments to monitor traffic and handle violation claims

then this may well increase Internet service bills.  That's apart from the

more-fundamental issue of ISPs moving away from just giving access to

cyberspace, of course; looks like yet another case of governments

legislating for the desired results.  Talking of costs, the UK Government

has pledged to offer everyone in the whole country (i.e. including remote

rural areas) at least 2MBit/s broadband by 2012, funded by a proposed 6

pounds ($10) a year levy on fixed-line telephone rental, so another good

reason to give up the landline and just use a cellphone.



Chris Drewe, Essex County, UK, still on dial-up.



------------------------------



Date: Fri, 4 Dec 2009 18:43:18 -0800

From: Lauren Weinstein <pfir_at_private>

Subject: Massive New UK Internet Wiretapping Plan Announced



                  http://lauren.vortex.com/archive/000646.html



Greetings.  Remember the controversy over the UK's "Phorm" - "ISPs Spy on

Users" Internet ad system? (http://bit.ly/91Yvgz [Lauren Weinstein's Blog])



Phorm was eventually beaten back, but it was small potatoes compared to what

the surveillance-happy folks in Jolly Old England have got up their sleeves

now.



Britain's Virgin Media ISP has announced a stunning plan to actually spy on

the data content of Internet users -- using law enforcement grade equipment

-- in search of illegal file sharing ( http://bit.ly/80maxP [ZDNet] ).



The scope of the plan is breathtaking.  File sharing protocol packets will

be opened and the contents run through music fingerprinting systems to try

determine if files are licensed or not.  At this stage of the plan, any

positive "hits" will be anonymous, but one can imagine how long that aspect

will remain in force.  And of course, if this sort of system can be

justified to "protect" the music and film industries, it's a small step to

arguing that all traffic should be monitored for *any* Internet content

considered to be suspicious, illicit, or inappropriate by Her Majesty's

government -- it's basically just a matter of how much communications and

processing power you're willing to throw at the task.



There is no opt-out or opt-in.  All files carried by any of the three

primary file-sharing protocols are subject to inspection, with initially

about 40% of subscribers being included in the "lucky" test group.  And

remember, these are *private* user-to-user Internet connections being

monitored -- not postings on public Web sites where license fingerprinting

can be reasonably justified.



What Virgin has announced is essentially the same concept as monitoring

telephone calls in hopes of overhearing something illegal being discussed.



The question here isn't whether or not people should inappropriately trade

licensed materials -- they shouldn't.  The issue is Internet users --

including innocent, law-abiding subscribers -- being subjected to having

their data content searched by whim of their ISPs, when such behavior would

not (we assume!) be tolerated on conventional telephone calls (but what of

VoIP phone calls traversing the Internet?  A fascinating question of ever

increasing importance ...)



Notably, the answer to these dilemmas is contained in a single word, which

you've seen me use many times before: *encrypt*!  As far as I'm concerned,

all Internet traffic should be routinely and pervasively encrypted, not just

to protect civil rights, but to protect economic and business security as

well.



In fact, a spokesman related to the new Virgin ISP spying project

notes that, "encryption of the data packet would defeat us."



Sounds like good advice to me.



Lauren Weinstein +1 (818) 225-2800 http://www.pfir.org/lauren

People For Internet Responsibility - http://www.pfir.org

Network Neutrality Squad - http://www.nnsquad.org

PRIVACY Forum - http://www.vortex.com



------------------------------



Date: Sun, 29 Nov 2009 11:52:12 -0800

From: Gene Wirchenko <genew_at_private>

Subject: Public servant fired over leak of private info of 14,000



This appeared in the 2009-11-27 issue of "The Daily News" of

Kamloops, British Columbia, Canada on page A7:



Second B.C. public servant fired over leak of private info on 14,000[1] people



The B.C. government says two public servants have now been fired following a

leak of the private information of 1,400 [1] welfare recipients.  The NDP

[2] claims the first person sacked was a man and the second was his wife,

but Citizen Services Minister Ben Stewart would not confirm that, saying it

was a personnel issue.



The leak came to light after the personal information was found in the hands

of a public servant under investigation by the RCMP's [3] commercial crime

unit and the Insurance Corporation of B.C. on an unrelated matter.  The NDP

says that information included birth dates, social insurance numbers and

other data.



The controversy came up for the second day in question period in the

legislature on Thursday, where the NDP once again demanded to know why it

took seven months to warn the people affected and why Stewart wasn't told

earlier about the breach.  Stewart promised a full investigation into the

issue, adding that the RCMP doesn't believe people's information was

compromised.



1. The headline is apparently the error.  All other coverage that I

   have seen has the number as being 1,400.

2. New Democratic Party.  In B.C., they are currently the official

   opposition party.

3. Royal Canadian Mounted Police: Canada's national police force



------------------------------



Date: Thu, 10 Dec 2009 19:10:42 -0800 (PST)

From: Rob McCool <robm_at_private>

Subject: Farmer claims GPS led him to breed clams in the wrong place



http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2009/12/10/financial/f162026S49.DTL&tsp=1



An oyster farm in Marin County, California was fined recently for farming

clams in an area designated as protected for the harbor seal. The owner of

the operation claimed that a faulty GPS device led his employees to place

the clam farm in the wrong place.



------------------------------



Date: Fri, 11 Dec 2009 11:20:07 -0600

From: Richard Cook <ri-cook_at_private>

Subject: My mother regarding LED traffic lights and Wisconsin winters



Mom wrote:



  "Interesting, some of the new traffic lights are LEDs and since they

  don't give off much heat, the snow sticks to the lights and drivers

  can't see the light.  I was yelling at someone who drove through a red

  and scared me but when I came home, realized that I couldn't see the

  light.  Now what?



Richard I. Cook, MD, Assoc.Prof., Department of Anesthesia and Critical

Care, U. Chicago, 5841 S. Maryland Ave MC4028, Chicago, IL 60637 773-702-4890



------------------------------



Date: Sun, 29 Nov 2009 12:29:14 -0500

From: Jerry Leichter <leichter_at_private>

Subject: Were you talkin' to me?



Early last spring I received mail containing a textual date and time for an

appointment.  Apple's mail client implements "data detectors," which spot

certain patterns in the text of messages and provide you with a pull-down to

implement various natural operations.  For example, the date and time in

this message gave me the opportunity to either go to that date and time in

iCal, the Mac calendar; or directly create a new event at that date and

time.  I chose the latter, and it worked as desired - even naming the

appointment from the subject of the mail message.



Except that ... the sender had specified the time zone with the date and

time.  And he specified it as EST.  But this was on a date shortly after we

switched over to EDT.  iCal faithfully converted the time to EDT, and made

the appointment an hour too late!  (There is a setting in iCal - which I

don't have enabled right now - in which the originating time zone is

preserved.  That might well have been even *more* confusing, as I suspect

the numeric time in the calendar would have agreed with the numeric time I

remembered from the mail message, keeping me from spotting the problem

quickly - but the alarm would still have gone off an hour too late!)



The risk: Increasingly, you really can't be sure when what you type (and,

soon, say) will be interpreted by a human being or by a machine.  Machines

are getting better, but they remain much more literal in their

interpretations than we expect humans to be.  We'll need to be very careful

in our use of language - as when we speak to someone from another culture -

or misunderstandings will multiply.



------------------------------



Date: Mon, 30 Nov 2009 21:54:39 -0500

From: Jeremy Epstein <jeremy.j.epstein_at_private>

Subject: All the best efforts gone to naught...



For one of my volunteer activities (anyone wanna buy Girl Scout cookies?), I

have a logon to a web site.  Every year we have to get renewed, which is

reasonable considering that the assignment changes annually.  There's always

gripes about setting a password for your account.



Here's an excerpt from an e-mail I received today on using the site: "They

will also have to change their password.  If they want to go back to their

original password, the next time they sign in they should complete the login

and password but click the 3rd green bullet below the login and go back to

that contact page for another password edit.  This a little tricky - most

people would like to keep their old password so here is what they can do -

when they go to the 3rd bullet it will ask for a new password - just put in

any kind of word - get out of that and go back to the login to the 3rd

bullet and go through that procedure for the new password , put old password

in and that way you will have your same password."



In summary, people will go to far more effort to keep the old password than

to set a new one....



But I guess it beats the message we got from my daughter's school telling us

that all the kids were instructed to change their password from the default

of "dragon" to the new password "dragons" - kids aren't allowed to pick

their own passwords, because then the teachers can't give them access, I

guess.  Sounds like a system that's poorly designed if the teacher can't

reset the students' passwords, so they ensure that all students have the

same password...



And we wonder why there are so many web account compromises?!?!?!



------------------------------



Date: Sun, 29 Nov 2009 08:20:24 +0100

From: "Prof. Dr. Peter Bernard Ladkin" <ladkin_at_private-bielefeld.de>

Subject: Various Internet Issues, Succinctly Put



Jeremy Clarkson is long-time host of the BBC's car-review program Top Gear,

which (I find out from the link below) is the most illegally- downloaded

television program from some unspecified sample.



Clarkson is known for his biting wit, the Oscar Wilde of the Morris

Mini. Like Garrison Keillor, he has crossed over from broadcast to print

journalism and writes entertaining pieces for The Times/Sunday Times

(Murdoch's News International), amongst others.



Here is his take on a number of Internet problems. I only wish I could write

so well:

http://www.timesonline.co.uk/tol/comment/columnists/jeremy_clarkson/article6936087.ece



Peter Bernard Ladkin, University of Bielefeld, 33594 Bielefeld, Germany

www.rvs.uni-bielefeld.de +49 521 880 73 19



------------------------------



Date: Sun, 29 Nov 2009 13:14:06 -0500

From: Jerry Leichter <leichter_at_private>

Subject: Re: The Joy of satellite navigation failures



In RISKS-25.85, Steve Loughran complains specifically about an ad in which a

car will use GPS "to get you home" - and more generally about over-reliance

on GPS.



I find myself increasingly an old curmudgeon myself, and I'm bothered by the

young whippersnappers who couldn't read a map to find their way down a

midwestern plains highway - dead straight and level as far as the eye can

see in both directions.



But ... let's be a bit objective here.  How accurate were paper maps?  The

period in which, even in the US and Western Europe, you could rely on maps

to be more than approximations doesn't date back much more then 50 years or

so.  In most of the world, there have never been accurate road maps.  I

drove around Puerto Rico in the late 1970's.  Hardly an undeveloped part of

the world.  And yet the maps were ...  fanciful in places.  Roads shown that

were planned but not yet built.  Roads that existed on the ground but

somehow didn't make it onto the maps.  Drive based just on the map - which

in one spot showed a 4-lane highway - and find yourself in the middle of a

sugar cane field.



Are GPS maps up to date?  How about the paper maps that used to fill glove

boxes?



Accurate road markers are of roughly the same vintage - and for historical

reasons are often difficult to use for navigation.  When I drove in England

about 20 years ago, most road signs except on the largest roads (a) did

*not* show you the compass direction; (b) named the next town down the road,

not some larger city you might have heard of beyond that.  One wrong turn

and you could go many miles the wrong way without knowing it.  (I did!)



Were there complaints from experienced users of compasses and rough maps

showing topographical features when people stopped learning how to use them

and relied on street signs?  When maps were introduced and people stopped

observing what was around them?  When compasses disconnected people from

navigation by the sun and stars?  Of course.  And did this lead to some

people getting lost because they had an old map, when someone of a previous

era would have had no problem noticing that we couldn't possibly turn

*there*, the topo maps shows that we should be going uphill?  Sure.



The fact is, GPS's get it right most of the time.  They are much easier to

use, much more reliable (when you consider the entire system, including the

inexperienced map reader), much more accurate than any system we had before.

People aren't going back, short of some kind of collapse that renders the

systems inoperable.  There's not much point in complaining.



Do *inappropriately used* or *badly designed* GPS's cause problems?  Sure,

but just how new are those?  People blindly followed maps, too - sometimes

because the maps were wrong or simply omitted some information like "low

bridge" (frankly, I've never seen a *consumer* road map with that piece of

information on it, any more than consumer GPS's inappropriately used by

truckers show this information), sometimes because most people never learned

how to read more than the basic information from a map.



We can certainly make the current systems better - and we are.  But

consider: Suppose you were driving somewhere unfamiliar, in a heavy

thunderstorm, using your GPS - and I suddenly took it away from you and

handed you some 4-year-old ratty, disintegrating map out of the glove box.

Would you think I'd improved things for you?



------------------------------



Date: Thu, 29 May 2008 07:53:46 -0900

From: RISKS-request_at_private

Subject: Abridged info on RISKS (comp.risks)



 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.

=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)

 if possible and convenient for you.   The mailman Web interface can

 be used directly to subscribe and unsubscribe:

   http://lists.csl.sri.com/mailman/listinfo/risks

 Alternatively, to subscribe or unsubscribe via e-mail to mailman

 your FROM: address, send a message to

   risks-request_at_private

 containing only the one-word text subscribe or unsubscribe.  You may

 also specify a different receiving address: subscribe address= ... .

 You may short-circuit that process by sending directly to either

   risks-subscribe_at_private or risks-unsubscribe_at_private

 depending on which action is to be taken.



 Subscription and unsubscription requests require that you reply to a

 confirmation message sent to the subscribing mail address.  Instructions

 are included in the confirmation message.  Each issue of RISKS that you

 receive contains information on how to post, unsubscribe, etc.



=> The complete INFO file (submissions, default disclaimers, archive sites,

 copyright policy, etc.) is online.

   <http://www.CSL.sri.com/risksinfo.html>

 The full info file may appear now and then in RISKS issues.

 *** Contributors are assumed to have read the full info file for guidelines.



=> .UK users should contact <Lindsay.Marshall_at_private>.

=> SPAM challenge-responses will not be honored.  Instead, use an alternative

 address from which you NEVER send mail!

=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.

 *** NOTE: Including the string "notsp" at the beginning or end of the subject

 *** line will be very helpful in separating real contributions from spam.

 *** This attention-string may change, so watch this space now and then.

=> ARCHIVES: ftp://ftp.sri.com/risks for current volume

     or ftp://ftp.sri.com/VL/risks for previous VoLume

 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive

 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.

   Lindsay has also added to the Newcastle catless site a palmtop version

   of the most recent RISKS issue and a WAP version that works for many but

   not all telephones: http://catless.ncl.ac.uk/w/r

 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .

==> PGN's comprehensive historical Illustrative Risks summary of one liners:

    <http://www.csl.sri.com/illustrative.html> for browsing,

    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing

==> Special Offer to Join ACM for readers of the ACM RISKS Forum:

    <http://www.acm.org/joinacm1>



------------------------------



End of RISKS-FORUM Digest 25.86

************************



Received on Mon Dec 14 2009 - 16:43:00 PST





]]>
Mon, 14 Dec 2009 16:43:00 PST
RISKS List Owner



http://lists.jammed.com/RISKS/2010/01/0000.html






From: RISKS List Owner <risko_at_private>




Date: Thu, 7 Jan 2010 15:17:41 PST






RISKS-LIST: Risks-Forum Digest  Thursday 7 January 2010  Volume 25 : Issue 89



ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy



***** See last item for further information, disclaimers, caveats, etc. *****

This issue is archived at <http://www.risks.org> as

  <http://catless.ncl.ac.uk/Risks/25.89.html>

The current issue can be found at

  <http://www.csl.sri.com/users/risko/risks.txt>



  Contents: "HAPPY NEW YEAR!!!"

Y2K+10 problem 1. German contactless bank cards (Debora Weber-Wulff)

Y2K+10 problem 2: Symantec (PGN)

Y2K+10 problem 3: Bank of Queensland Eftpos system (Jared Gottlieb)

Y2K+10 problem 4: SpamAssassin tags "2010" e-mail as spammish (Danny Burstein)

Y2K+10 Bug, for those who thought that Y2K was a made up crisis (Bob Gezelter)

Verizon: I just don't know what to say (Geoff Kuenning)

Eurostar Risks (Anthony Thorn)

Display: none; visibility: hidden; overflow: hidden (jidanni)

Crumbling Crypto: RSA 768 modulus factored + security implications (PGN)

Couple Stuck in Oregon Snow for 3 Days After GPS Leads Them Astray

  (Richard Grady)

Risks of Relying on Downstream Syndication (Bob Gezelter)

Re: Teleportation via Skyhook (Gary Bliesener)

Toyota acceleration; is it just the gas pedal or not? (David Lesher,

  Curt Sampson, Dick Mills, Jerry Leichter, Amos Shapir, Rob Seaman)

Abridged info on RISKS (comp.risks)



----------------------------------------------------------------------



Date: Tue, 05 Jan 2010 00:33:39 +0100

From: Debora Weber-Wulff <weberwu_at_htw-berlin.de>

Subject: Y2K+10 problem 1. German contactless bank cards (3 messages)



Happy New Year!



Germans now have the answer as to why they came up short at the ATMs after

the New Year. Tagesschau reports online that people who were using newer

cash machine cards that had new-fangled golden chips in them were told at

the machine that their cards had an error because of a "software error". Not

only ATM machines were affected, supermarkets and such that check cards

online refused to accept the cards.

  http://www.tagesschau.de/wirtschaft/eckarte102.html



Since I have spent the first 4 days of the year writing "20010", anyone want

to speculate that this is the error?  No details on the exact nature of the

error as yet. It is scheduled to be fixed tonight (Jan. 4!).



Not all of the machines refused to work, only the newer ones with the

"EMV-Standard" (http://en.wikipedia.org/wiki/EMV) which are to keep the

cards from being duplicated illegally and "secure" the data.



Older cards, which store information on a magnetic strip, were not affected.



I'm glad I still have an old card and an ancient machine around the

corner. I got money after New Year's.



More: Wed, 06 Jan 2010 17:36:57 +0100



It is getting curiouser and curiouser! The Tagesschau reports in

http://www.tagesschau.de/wirtschaft/eckarte108.html and

http://www.tagesschau.de/wirtschaft/kreditkarten144.html, which

I translate and summarize here:



It turns out that even more cards are affected, and even more people are

unable to use either their EC cards or their credit cards to obtain cash or

to pay in stores.



The culprit has been named: The company that produces the cards,

Gemalto. Seems that the software thinks that it is the year 2016 and not

2010, so all of the cards are no longer valid. A friend pointed out to me

that 2016 is 11111100000 in binary. [*]



The problem is a program stored on the chip. The banks don't want to have to

exchange all of the cards (a really expensive solution), so they are looking

for a workaround. One was promised for Monday evening, but it has not yet

materialized. ATMs are generally now accepting the cards again [meaning they

probably don't do any checking now...], but the Point of Sale terminals

refuse to cooperate.



30 million cards are affected, and changing them would entail the owners all

having to learn a new code for their cards. Only German cards are

affected. Many hundred thousand cards were just exchanged in November

because of problems with the data of cards used in Spain having been

available after a security breach.



The company Gemalto was formed 2006 in the fusion of the French company

Gemplus International and the Dutch Axalto Group. The company has 10.000

employees and produces bank cards, telephone SIM cards and electronic

passports. The company reports a volume of 1,68 billion euros in 2008.



Consumer organizations and the consumer minister are blasting the banks for

informing the consumers only a little bit at a time.



* On a side note, customers of smartphones using Windows Mobile operating

system have been noticing that incoming SMS messages also have the date

2016.



Still More: Thu, 07 Jan 2010 08:58:34 +0100



Just a bit of scotch tape, sir!



The great Y2K+10 problem in Germany continues:



The chips were put on the cards to make them more difficult to

duplicate. But it turns out, they at least have a fail-safe mode.  If the

chip is found to be malfunctioning or not there, the card readers resort to

reading the magnetic stripe.



Spiegel and others report that all it takes is a little Scotch tape over the

contacts of the card, and the readers will switch to fail-safe mode.

Retailers now dispense tape at the cash registers.

http://www.spiegel.de/wirtschaft/soziales/0,1518,670433,00.html



It is great that they have this mode, but it kind of makes you wonder how

safe these expensive chips really make you, if they can so easily be

defeated.



Prof. Dr. Debora Weber-Wulff, HTW Berlin, Treskowallee 8, 10313 Berlin

Tel: +49-30-5019-2320 http://www.f4.htw-berlin.de/people/weberwu/



------------------------------



Date: Thu, 7 Jan 2010 11:44:54 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Y2K+10 problem 2: Symantec



Symantec Y2K10 Date Stamp Bug Hits Endpoint Protection Manager

http://www.eweek.com/c/a/Security/Symantec-Y2K10-Date-Stamp-Bug-Hits-Endpoint-Protection-Manager-472518/?kc=EWKNLSTE01072010STR1



Updates after 31 Dec 2009 11:59 p.m are being labeled as "out-of-date."



------------------------------



Date: Sun, 3 Jan 2010 11:22:18 -0700

From: jared gottlieb <jared_at_private>

Subject: Y2K+10 problem 3: Bank of Queensland Eftpos system



Retail businesses across the country have lost thousands of dollars over the

long weekend because a computer glitch left shoppers unable to use the Bank

of Queensland's Eftpos terminals.  BOQ's Eftpos machines skipped ahead six

years when the clock ticked over to January 1 and started date stamping

January 2016.  BOQ staff have not been able find what caused the problem,

but a temporary solution has been put in place to ease retailers'

frustrations.  The glitch cost businesses untold amounts as the Eftpos

terminals read customers' [debit] cards as having expired and refused their

transactions.  [Source: *Sydney Morning Herald* 3 Jan 2010, AAP news wire]



------------------------------



Date: Sat, 2 Jan 2010 10:28:38 -0500 (EST)

From: danny burstein <dannyb_at_private>

Subject: Y2K+10 problem 4: SpamAssassin tags "2010" e-mail as spammish



Spam Assassin is a pretty widely used e-mail filtering program.  One of the

rules it uses is checking the date on incoming e-mail. If it's wrong, then

some points are added to the "is this spam?" score.



It seems that up until a rushed update the afternoon of Jan. 1st, 2010, the

standard installations, using the default rule set, considered the year

"2010" to be way off in the future. Accordingly they gave e-mail with that

date an automatic 3.5 points. Five points gets you to the "spam threshold",

so lots of material coming through on the new year got clobbered.



It seems the "year date" was hard/hand coded, as opposed to making a

comparison to "today's" date.



The SpamAssassin folk have a new version which corrects this problem. Folk

running SA can also modify that one rule set and bypass the issue.



Details:

http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269



  [Also noted by Dave Horsfall:

    "To summarise, it blocks messages with dates set too far in the future

    (which apparently is a common spammer trick - I read my e-mail in forward

    order of delivery) and 2010 was inside the range of 2010-2099."]

  https://secure.grepular.com/blog/index.php/2010/01/01/spamassassin-2010-bug/



------------------------------



Date: Wed, 06 Jan 2010 16:52:14 -0500

From: Bob Gezelter <gezelter_at_private>

Subject: Y2K+10 Bug, for those who thought that Y2K was a made up crisis



Recently, I have seen several letters questioning the whether Y2K was a real

hazard, or whether it was an invented crisis. Several of these letters have

appeared in *The New York Times* Letters page following the publication of

"It's Always the End of the World as We Know It" (Op Ed, 1 Jan 2010).



The coincidence is uncanny. Yesterday (5 Jan 2010), Network World published

"Y2K all over again in 2010?" on a series of outages related to this most

recent decade change.



The Network World article can be found at:

https://www.networkworld.com/news/2010/010510-date-change-problems.html

The New York Times Op Ed can be found at:

http://www.nytimes.com/2010/01/01/opinion/01dutton.html

The Letters relating to Op Ed can be found at:

http://www.nytimes.com/2010/01/06/opinion/l06climate.html



- Bob Gezelter, http://www.rlgsc.com



------------------------------



Date: Sat, 02 Jan 2010 14:23:51 -0800

From: Geoff Kuenning <geoff_at_private>

Subject: Verizon: I just don't know what to say



Recently, Verizon took over MCI, resulting in me getting them as my new

local telephone provider.  This afternoon, I used Verizon's online site

to change the billing address for my account.  About an hour later, I

got a nice automated phone call that was intended to verify that the

change was legitimate.



So far, so good.  But the automated voice informed me that if I hadn't

authorized the change, I should "contact us at [slight pause] between

the hours of [slight pause] and [slight pause].  Thank you for choosing

Verizon."



I guess I should be glad that "[slight pause]" didn't come out as "left

parenthesis null pointer right parenthesis."



Geoff Kuenning   geoff@private   http://www.cs.hmc.edu/~geoff/



------------------------------



Date: Sun, 27 Dec 2009 10:09:44 +0000 (GMT)

From: "anthony.thorn_at_private" <anthony.thorn_at_private>

Subject: Eurostar Risks



On December 18th, 5 Eurostar passenger trains failed, in the Channel tunnel

trapping 2000 passengers.  (Eurostar is the rail service through the tunnel

under the English channel) The service only resumed on Tuesday 22nd.



The failure was due to inadequately "winterised" trains encountering snow

and extremely cold weather: "The snow entered the locomotives' ventilation

system... When the trains entered the great warmth of the tunnel, the

electrical system short-circuited and the traction motors of the Eurostars

cut out and would not start again."



This problem was known.  It is NOT a "Black Swan" !



Apparently in contrast to the passenger trains, the car-transporter trains

are sufficiently winterised.



If the failure was not already a disaster, there is no doubt at all about

the evacuation.



Some passengers were trapped in the tunnel for up to 14 hours, and

complained about lack of/conflicting information, as well as the heat.



Thousands of passengers waited at the railway (train) stations for a service

that would not be available for days.



There was not much of an alternative: huge queues for ferries , and planes

delayed by the weather.



e.g.

http://www.independent.co.uk/news/uk/home-news/thousands-stranded-as-eurostar-service-is-suspended-1846350.html



The risks:



1. (IMHO)  an inadequately tested contingency plan.



2. We passengers assume that a rail service will be reliable -because it

almost always is.  Perhaps we should not/cannot and need to take our own

"emergency equipment" along?



------------------------------



Date: Tue, 05 Jan 2010 06:37:57 +0800

From: jidanni_at_private

Subject: Display: none; visibility: hidden; overflow: hidden



I suppose it's fair game these days to hide anything you like within an

HTML div style="display: none; visibility: hidden; overflow: hidden;"

like they do on http://topics.cnn.com/topics/weather .

They even store a "404 Error The page you requested cannot be found"

inside that HTML div. "Who would ever browse without using (our) stylesheets?"



------------------------------



Date: Thu, 7 Jan 2010 11:40:28 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Crumbling Crypto: RSA 768 modulus factored + security implications



After an extensive multiyear collaborative effort, the RSA 768-bit challenge

number has been factored, suggesting that 1024-bit prime products may be

somewhat closer to approaching the end of their practical lifetimes.



  http://bit.ly/8xXSgy  (International Association for Cryptologic Research)



------------------------------



Date: Mon, 28 Dec 2009 13:52:20 -0800

From: Richard Grady <richard_at_private>

Subject: Couple Stuck in Oregon Snow for 3 Days After GPS Leads Them Astray



KLAMATH FALLS, Ore.  A Nevada couple letting their SUV's navigation system

guide them through the high desert of Eastern Oregon got stuck in snow for

three days when the GPS unit sent them down a remote forest road.

  http://www.foxnews.com/story/0,2933,581303,00.html



------------------------------



Date: Mon, 04 Jan 2010 19:20:31 -0500

From: Bob Gezelter <gezelter_at_private>

Subject: The Risks of Relying on Downstream Syndication



It is common to rely on downstream syndication feeds (e.g., ATOM, RSS,

usenet news) for information. Unfortunately, sometimes there are "clogs" in

the pipeline that result in delayed, lost, or out of sequence messages.



Those who read RISKS using Google Groups have recently experienced just such

an episode. RISKS 25.85, 25.86, and 25.87 are out of sequence on the archive

at http://groups.google.com/group/comp.risks and RISKS 25.88 is completely

missing as of this date (4 January 2010), despite having been posted on

26 December.



Fortunately, the RISKS page at http://www.risks.org is up to date.



Bob Gezelter, http://www.rlgsc.com



------------------------------



Date: Tue, 29 Dec 2009 10:45:31 -0500

From: Gary Bliesener <gbliesener_at_private>

Subject: Re: Teleportation via Skyhook



The default browser, Polaris 6.0, on my Samsung Rant is nearly useless so I

installed the Opera Mini-Browser.  I ran into IP geolocation issues when

responding to e-mailed employment alerts, as many websites would reject my

application with a message informing me that one must be a United States

resident to apply for their position, even though I am an American using the

phone in the mid-Atlantic region of the United States.  The Opera

mini-browser evidently brings with it an IP address out of what IP

geolocation types would label a "Norwegian address pool".  I had to wait

until my return home to apply, rather defeating the purpose of purchasing a

web and e-mail enabled cellphone.



Gary Bliesener, Unix System Administrator



------------------------------



Date: Sun, 27 Dec 2009 01:35:32 -0500

From: David Lesher <wb8foz_at_private>

Subject: Toyota acceleration; is it just the gas pedal or not? (RISKS-28.85)



<http://www.latimes.com/business/la-fi-toyota-throttle29-2009nov29,0,5254584.story>



An *LA Times* item has lead the coverage of the issue, bringing up the

accusation that the problem is not just mechanical interference between the

mats and the pedals, but also more.



  Eric Weiss was stopped at a busy Long Beach intersection last month when

  he said his 2008 Toyota Tacoma pickup unexpectedly started accelerating,

  forcing him to stand on the brakes to keep the bucking truck from plowing

  into oncoming cars.  ..  But Weiss is convinced his incident wasn't caused

  by a floor mat. He said he removed the mats in his truck months earlier on

  the advice of his Toyota dealer after his truck suddenly accelerated and

  rear-ended a BMW.



Also, I saw a mention that a previous driver of the car that crashed had

complained to the dealer about the problem, but it was reissued to the

victim despite that. If true, THAT would not alter the cause, but would

likely change the legal liability issues.



------------------------------



Date: Sun, 27 Dec 2009 16:14:54 +0900

From: Curt Sampson <cjs_at_starling-software.com>

Subject: Re: Another user interface fatal accident in Afghanistan



Re: Mark Thorson, RISKS-25.88



> When the target position is cleared, it would probably be better to

> initialize it 100 meters to the east or something, rather than right on

> top of the observer position.



Where it might drop on your friends?



It seems to me one wants to expand the range of values to include "no target

position." It can't be all that unusual sometimes not to want to drop a

bomb.



Curt Sampson         <cjs_at_private>         +81 90 7737 2974



------------------------------



Date: Sun, 27 Dec 2009 09:47:25 -0500

From: Dick Mills <dickandlibbymills_at_private>

Subject: Re: LED Traffic Lights are efficient ... (R 25 88)



  John Johnson (R 25 88): "The problem is also evident on motor vehicles

  with LED signal and stop lights.  Snow is not melted away by the signal

  and stop lights and accumulation blocks the lights."



Neither can incandescent stop and signal lights melt snow if they are not

used often; such as long stretches of driving on the open highway.  Nor

could they melt snow when there was a generous air gap between the bulb and

the lens cover.



I can't recall any mention of this risk in the pre LED era. What's new?



------------------------------



Date: Sun, 27 Dec 2009 05:38:43 -0500

From: Jerry Leichter <leichter_at_private>

Subject: Re: LED Traffic Lights are efficient ... (R 25 88)



John Johnson's mention (R 25 88) of a story that LED traffic lights can be a

problem if it snows because they don't generate enough heat to clear

themselves brings to mind a repeated story from the NY area.  Every fall, we

get delays in mass transit because of wet leaves on train tracks.  I never

recalled hearing of such problems years back, and indeed reports have

indicated that this is another side-effect (or lack of a side-effect!) of

new technology.



In the old days, trains stopped by apply brake pads to the wheels.  The

resulting friction heated the wheels and rails and rapidly dried and burned

off any leaves.  Today, the trains use regenerative braking: The wheel

motors are run as generators, recovering much of the kinetic energy of the

train as electricity.  Much more efficient - but as a result, the wheels and

rails no longer hot enough to perform a leaf-clearing function.



------------------------------



Date: Sun, 27 Dec 2009 17:55:49 +0200

From: Amos Shapir <amos083_at_private>

Subject: Re: LED Traffic Lights are efficient ... (R 25 88)



This is actually an old problem with a new twist: the designers of traffic

lights and headlights were -- probably unknowingly -- relying on an

undocumented feature of incandescent light bulbs, namely their ability to

generate enough heat to melt snow on cold days.  Obviously it did not occur

to anyone that light fixtures should be redesigned for a different type of

bulbs.



------------------------------



Date: Mon, 28 Dec 2009 00:07:47 -0700

From: Rob Seaman <seaman_at_private>

Subject: Re: LED Traffic Lights are efficient ... (R 25 88)



The general class of risk here is that of unintended consequences.  It may

be helpful to drill down into the specifics of what is going wrong.  In both

of these submissions (traffic or vehicle signals), LEDs are replacing

incandescent bulbs in outdoor applications subject to varying weather

conditions.  The notion appears to be that nobody could have predicted that

more efficient lamp technology would be subject to a failure mode in the

snow.



Such a notion is mired in confusion over the difference between describing a

problem and entertaining solutions to that problem.  "Unintended

consequences" is another way of saying "undiscovered requirements".  The

underlying problem is one of signaling, not of lighting technology.  After

all, before there were traffic lights, there were unlighted traffic

semaphores.  Drivers still use hand signals on occasion to supplement

lighted turn signals and brake lights.



The common goal is to communicate signals (of intent, permission, and

proscription) between a community of drivers, pedestrians, and other roadway

users.  In addition to numerous requirements relating to sequencing of

interlocking signals, there are - as a matter of course - various

requirements regarding weather and ambient visibility (and other sensory)

conditions.  For instance, presumably the LED manufacturers did not neglect

to consider the effect of rain on the operation of their signals.



A complete set of top level requirements for a roadway signaling system

might not even mention lighting technology at all.  More likely, constraints

on lighting will appear as non-functional requirements describing current

practices and standards (eg., the order of the colors on a traffic signal).

A statement that a signal device should continue to operate when it is

snowing (presumably up to some NNN-year blizzard threshold) is very much a

functional requirement inherent in the concept of operations.



A compliance audit/acceptance test should have caught this issue - almost by

inspection - before deployment.  LEDs are desirable because they inexpensive

to operate due to their high efficiency.  They are efficient because they

emit far less waste heat.  What happens to the snow accumulation when heat

is removed from the system?



Some possible solutions have already been mentioned: a heating element

(perhaps actively controlled), weather shielding, special coatings.  The

point is that there is one problem description ("signal must continue to

operate when it is snowing"), but many different options for solutions.  It

is impossible to evaluate the acceptability of any solution without matching

it point-by-point against the problem requirements the solution is meant to

address.



Some risks are long and involved to describe.  It is precisely that this

issue can be characterized so succinctly that reveals a requirements

failure.  Whether the vendor or the customer bears a larger burden of the

responsibility for the failure is a separate question.



Rob Seaman, National Optical Astronomy Observatory seaman_at_private



------------------------------



Date: Thu, 29 May 2008 07:53:46 -0900

From: RISKS-request_at_private

Subject: Abridged info on RISKS (comp.risks)



 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.

=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)

 if possible and convenient for you.   The mailman Web interface can

 be used directly to subscribe and unsubscribe:

   http://lists.csl.sri.com/mailman/listinfo/risks

 Alternatively, to subscribe or unsubscribe via e-mail to mailman

 your FROM: address, send a message to

   risks-request_at_private

 containing only the one-word text subscribe or unsubscribe.  You may

 also specify a different receiving address: subscribe address= ... .

 You may short-circuit that process by sending directly to either

   risks-subscribe_at_private or risks-unsubscribe_at_private

 depending on which action is to be taken.



 Subscription and unsubscription requests require that you reply to a

 confirmation message sent to the subscribing mail address.  Instructions

 are included in the confirmation message.  Each issue of RISKS that you

 receive contains information on how to post, unsubscribe, etc.



=> The complete INFO file (submissions, default disclaimers, archive sites,

 copyright policy, etc.) is online.

   <http://www.CSL.sri.com/risksinfo.html>

 The full info file may appear now and then in RISKS issues.

 *** Contributors are assumed to have read the full info file for guidelines.



=> .UK users should contact <Lindsay.Marshall_at_private>.

=> SPAM challenge-responses will not be honored.  Instead, use an alternative

 address from which you NEVER send mail!

=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.

 *** NOTE: Including the string "notsp" at the beginning or end of the subject

 *** line will be very helpful in separating real contributions from spam.

 *** This attention-string may change, so watch this space now and then.

=> ARCHIVES: ftp://ftp.sri.com/risks for current volume

     or ftp://ftp.sri.com/VL/risks for previous VoLume

 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive

 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.

   Lindsay has also added to the Newcastle catless site a palmtop version

   of the most recent RISKS issue and a WAP version that works for many but

   not all telephones: http://catless.ncl.ac.uk/w/r

 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .

==> PGN's comprehensive historical Illustrative Risks summary of one liners:

    <http://www.csl.sri.com/illustrative.html> for browsing,

    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing

==> Special Offer to Join ACM for readers of the ACM RISKS Forum:

    <http://www.acm.org/joinacm1>



------------------------------



End of RISKS-FORUM Digest 25.89

************************



Received on Thu Jan 07 2010 - 15:17:41 PST





]]>
Thu, 7 Jan 2010 15:17:41 PST
RISKS List Owner



http://lists.jammed.com/RISKS/2009/12/0002.html






From: RISKS List Owner <risko_at_private>




Date: Sat, 26 Dec 2009 20:57:27 PST






RISKS-LIST: Risks-Forum Digest  Saturday 26 December 2009  Volume 25 : Issue 88



ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy



***** See last item for further information, disclaimers, caveats, etc. *****

This issue is archived at <http://www.risks.org> as

  <http://catless.ncl.ac.uk/Risks/25.88.html>

The current issue can be found at

  <http://www.csl.sri.com/users/risko/risks.txt>



  Contents:

Insurgents Hack U.S. Drones (PGN)

Another user interface fatal accident in Afghanistan (Mark Thorson)

Security in the Ether: Cloud Computing? Or "Swamp" Computing?

  (Lauren Weinstein)

HP's facial-recognition can't recognize black people's faces (Randall Webmail)

Alert: Twitter apparently hacked (Lauren Weinstein)

Silent Hybrid Nearly Causes Carbon Monoxide Poisoning (Bob Gezelter)

UAL: Another risk of weather for computer based systems (Jared Gottlieb)

When the human model doesn't match the system model (Sean W. Smith)

Disconnects between the Real World and Cyberspace (Bob Gezelter)

Obscure GPS problems not just in remote areas (Jeremy Epstein)

On the Road with a GPS System (Gene Wirchenko)

GPS ads for captive bus riders (jidanni)

Cruise control failed to disengage (Steve Cody)

Re: LED Traffic Lights are efficient but cannot melt away snow (John Johnson)

Abridged info on RISKS (comp.risks)



----------------------------------------------------------------------



Date: Thu, 17 Dec 2009 16:28:57 PST

From: "Peter G. Neumann" <neumann_at_private>

Subject: Insurgents Hack U.S. Drones



Militants in Iraq have used $25.95 off-the-shelf software to intercept live

video feeds from U.S. Predator drones, potentially providing them with

essence, the Predator video link to the ground station is unencrypted.

Insurgents are sniffing the link and reconstructing the video.  The

U.S. government has known about this flaw for a decade, but ignored it,

offering the usual litany of problems: encrypting the link would delay the

program, cost more, and complicate operations.  ``But the Pentagon assumed

local adversaries wouldn't know how to exploit it, the official said.''  The

stolen video feeds also indicate that U.S. adversaries continue to find

simple ways of counteracting sophisticated American military technologies.

[Source: Siobhan Gorman, Yochi J. Dreazen and August Cole, $26 Software Is

Used to Breach Key Weapons in Iraq; Iranian Backing Suspected, Wall Street

Journal, 17 Dec 2009, front page; PGN-ed] The myth of security by obscurity

strikes again.  http://ebird.osd.mil/ebfiles/e20091217723006.html



I've seen arguments that key management would be too difficult to manage,

although some reports say that efforts are now underway to encrypt.  Other

arguments are that uncleared soldiers need access to the video streams, but

that seems to confuse "encryption" and "classification".  Don't forget that

the former does not require the information to be classified for

confidentiality or that it is not important for integrity!  Also, the new

Reaper drones cost over $10 million each and have the same vulnerability.



Jeremy Epstein noted that *WiReD* reports that it's not just drones, but

also regular combat aircraft - although it's harder to intercept the

(unencrypted) signal from the regular planes.  The talk I've heard today

that "it's not such a big deal" seems odd - if you were an insurgent, having

a few minutes warning that there's a drone coming your direction would be

useful data.

http://www.wired.com/dangerroom/2009/12/not-just-drones-militants-can-snoop-on-most-us-warplanes/



Also, see Bruce Schneier's essay on the topic:

http://www.wired.com/politics/security/commentary/securitymatters/2009/12/securitymatters_1223



------------------------------



Date: Tue, 15 Dec 2009 20:22:41 -0800

From: Mark Thorson <eee_at_private>

Subject: Another user interface fatal accident in Afghanistan



The circumstances of this incident seem very similar to the incident a few

years ago in which changing batteries cleared the offset between the

observer's GPS position and the target position on his Garmin.

http://www.dailymail.co.uk/news/article-1236087



When the target position is cleared, it would probably be better to

initialize it 100 meters to the east or something, rather than right on top

of the observer position.



------------------------------



Date: Thu, 24 Dec 2009 11:04:16 -0800

From: Lauren Weinstein <lauren_at_private>

Subject: Security in the Ether: Cloud Computing? Or "Swamp" Computing?



Security in the Ether: Cloud Computing? Or "Swamp" Computing?

  [From NNSquad, Network Neutrality Squad, http://www.nnsquad.org]



An important article worth reading:



http://bit.ly/4uYabf  (MIT Technology Review)



My personal "thumbnail" view on this is that:



a) Cloud Computing" holds enormous promise.



b) Most of the key security and other operational issues associated with

   cloud computing are solvable, including aspects of pervasive encryption

   that would protect cloud computing clients from potential snooping by

   theoretically postulated unscrupulous cloud service providers.



c) The financial and intellectual resources (including basic policy

   analysis) required to understand and solve these problems on an *a

   priori* basis, rather than on an "after there's a mess" reactive basis,

   are in general insufficiently emphasized and deployed.



d) Given (c), not all of the current rush to cloud computing on today's

   widely available platforms can necessarily be justified as wise,

   particularly where sensitive and/or privacy-critical data is involved.



Or in other words, Cloud Computing can be a Really Good Thing if done

right, but let's not get the cart in front of the horse.



------------------------------



Date: December 21, 2009 1:29:12 PM EST

From: Randall Webmail <rvh40_at_private>

Subject: HP's facial-recognition can't recognize black people's faces



  [From Dave Farber's IP]

This is awkward. It appears that HP's new webcams, which have facial-

tracking software, can't recognize black faces, as evidenced in the above

video. HP has responded:



> We are working with our partners to learn more. The technology we use is

> built on standard algorithms that measure the difference in intensity of

> contrast between the eyes and the upper cheek and nose. We believe that

> the camera might have difficulty "seeing" contrast in conditions where

> there is insufficient foreground lighting.



> HP Face-Tracking Webcams Don't Recognize Black People - Hp - Gizmodo  

> (21 December 2009)

http://gizmodo.com/5431190/hp-face+tracking-webcams-dont-recognize-black-people

http://snipurl.com/tsfli



Archives: https://www.listbox.com/member/archive/247/=now



------------------------------



Date: Thu, 17 Dec 2009 22:38:41 -0800

From: Lauren Weinstein <lauren_at_private>

Subject: Alert: Twitter apparently hacked



Twitter has apparently been hacked.  Invalid security certificate for wrong

site on the Twitter https: home page, Iranian Cyber Army hack page on main

twitter.com.  This looks much like an SQL injection exploit I've dealt with

in the past, but I don't know for sure at this point if the actual Twitter

infrastructure has been hacked or if this is a DNS hack.



Presumably this won't last long, but more info when available.



Date: Fri, 18 Dec 2009 09:47:59 -0800



Twitter has not officially released details on last night's hacking-related

outage of their Web site, other than to state that it was (as many of us

suspected) a DNS-related attack.



There are some other details floating around unofficially.  Twitter's DNS

services are provided by Dyn Inc.'s Dynect Platform.  Dyn is insisting that

their systems were not compromised and that nobody accessed Twitter's DNS

data without appropriate (login) credentials.



This suggests (but again, this is *not* confirmed) that Twitter's account on

Dyn was somehow itself compromised, possibly through "social engineering" or

other techniques that resulted in the attackers gaining login access to the

Twitter account on Dynect, allowing them to change the associated DNS data.

(From Dyn's standpoint, this could still be considered to be "appropriate

login credentials.")



It goes without saying that the "Iranian Cyber Army" hack page is almost

certainly a fraud, and there are no indications that Iran actually had

anything to do with this attack (breathless statements blaming Iran being

made by some media points notwithstanding).  By the way, I've seen this

exact page resulting from various bot-based, non-DNS attacks in the past.



Presumably more "official" statements about what transpired will be

forthcoming at some point, after the finger-pointing slows down a bit.



Of course this once again demonstrates the fragility of DNS, but that's

hardly a headline news revelation at this stage of the game.



Date: Fri, 18 Dec 2009 12:14:27 -0800



Now confirming [ Ref: http://www.nnsquad.org/archives/nnsquad/msg02460.html ] 

that the Twitter DNS diversion last night was the result of someone using

Twitter's own login credentials to change DNS data at Dyn's site,

according to Dyn's CTO:



http://bit.ly/80Ve4Y  (Wired)



So as suspected, this was not a "sophisticated" attack (e.g., DNS cache

poisoning) but rather a conventional login attack.



It is interesting to consider that apparently a single username/password

pair was able to take Twitter's entire Web site effectively offline

globally.



At the very least one would hope that more advanced account control

mechanisms (e.g., certificate-based access authentication) would be employed

with critical accounts for organizations at this level.



------------------------------



Date: Sat, 26 Dec 2009 08:07:53 -0500

From: Bob Gezelter <gezelter_at_private>

Subject: Silent Hybrid Nearly Causes Carbon Monoxide Poisoning



The Decemeber 27, 2009 Sunday New York Times Magazine (p. 8) contains a

Letter to the Editor from Liz Cantarine entitled "Artificial Car Noises".



Ms. Cantarine describes how she accidentally left her hybrid automobile

running in her garage. Apparently, when returning from a shopping trip, she

became preoccupied with the packages in the trunk, and forgot to turn off

the car. The car continued running, filing the garage space with fumes.



It is an interesting problem. Synthetic noise generators are being required

due to a hazard to visually impaired pedestrians, but this is the first

report I have seen describing a danger to owners and their families from

silent cars.



------------------------------



Date: Sun, 20 Dec 2009 15:51:55 -0700

From: jared gottlieb <jared_at_private>

Subject: UAL: Another risk of weather for computer based systems



>From the United Airlines website 20 December 2009



Weather-related delays and cancellations resulted in a significantly  

higher volume of calls into United's reservations centers. Our voice  

recognition software was hampered by the volume, which in turn drove  

longer wait times. We sincerely regret the inconvenience faced by our  

guests, and are pleased to report that our voice recognition software  

is fully up and running and wait times have been significantly  

reduced. We are still experiencing higher than normal call volume,  

which may result in sporadic call interruptions. 



------------------------------



Date: Fri, 25 Dec 2009 18:31:29 -0500

From: "Sean W. Smith" <sws_at_private>

Subject: When the human model doesn't match the system model



The real world gives another instance of what can go wrong:



A man in Epping tried to deposit $580 into an ATM but neglected to note the

transaction had not completed and walked away without the returned cash.

The next person pocketed the cash, but of course was identified.

[Source: AP item, 25 Dec 2009] 



Sean W. Smith   sws_at_private  www.cs.dartmouth.edu/~sws/

Associate Professor, Department of Computer Science, Dartmouth  



------------------------------



Date: Sat, 26 Dec 2009 08:19:04 -0500

From: Bob Gezelter <gezelter_at_private>

Subject: Disconnects between the Real World and Cyberspace



Sometimes the real world and cyberspace are truly separate realms. The other

day, I experienced two episodes of just such a disconnect.



I was trying to verify the hours for a branch bank in the area. Checking the

bank's www site, I discovered that the branch was not listed. Calling the

customer service line, I was assured that if the branch was not listed, it

must have closed.



Three hours later, I visited the branch. It was quite active, with no signs

of closing or relocation. A discussion with the officers revealed that I was

not the first person to note the error. It had been reported to corporate,

but for some reason the data had not been corrected.



The same day, I had a similar experience with a major international

distributor. A local branch was not listed as one of their locations, even

though it was open and active.



It is an interesting question of IT governance when a company is unable to

keep its list of branches up to date.



A longer discussion of this episode can be found in "Bricks and Mortar

Hidden by Cyberspace". 

http://www.rlgsc.com/blog/ruminations/bricks-and-mortar-hidden-by-cyberspace.html



Robert "Bob" Gezelter, +1 (718) 463 1079   35-20 167th Street, Suite 215

Flushing, New York  11358-1731 http://www.rlgsc.com



------------------------------



Date: Tue, 15 Dec 2009 16:02:12 -0500

From: Jeremy Epstein <jeremy.j.epstein_at_private>

Subject: Obscure GPS problems not just in remote areas



The discussion of GPS issues with BMWs reminded me of a recent GPS

navigation problem I ran into using my brand-new Garmin nuvi 275T.



The Garmin maps of Washington DC have an unfortunate mistake: they don't

understand that K Street runs *under* (and parallel to) the Whitehurst

Expressway.  The Whitehurst Expressway intersects Key Bridge (well, actually

it runs into M Street a block from Key Bridge), but K Street does not except

when separated by 100 vertical feet.  Specifically, if you ask the GPS for

directions from northwest Washington DC (I was coming from the Tenleytown

neighborhood) to Fairfax VA, it tells you to take Rock Creek Parkway south,

exit onto K Street west, then drive along K Street and then make a left on

Key Bridge - which is 100 feet above you.  Google Maps, on the other hand,

gets this right.



The RISK is thinking that GPS errors only occur in out-of-the-way locations.

This is in the Georgetown neighborhood of Washington DC, hardly remote!



  [Alarmin' Garmin Swarmin' Harmin' not Charmin'.  PGN]



------------------------------



Date: Tue, 15 Dec 2009 18:46:58 -0800

From: Gene Wirchenko <genew_at_private>

Subject: On the Road with a GPS System



  [Whenever I fail to run an item you think I may have missed, please

  resubmit (with "notsp" in the subject line, of course.  This is an

  instance of something I apparently missed 3.5 years ago.  Sorry!!!  PGN]



GPS problems have been in the news more lately, so I thought that I would

resubmit this item.  I have since moved back to Canada.  A key point: All of

the events that I describe happened on a trip to my mom's and back.  This is

not a collection of events over a period of, say, months.



On the Road with a GPS System



There have been previous submissions of the joys of GPS systems used in

driving.  They have been brief.  This writeup goes into much more detail and

details more than one risk.  I wrote this in June of 2006, but have kept the

present tense.



I am a Canadian citizen, but I live in Bellingham, WA, USA and work near it.

At the beginning of April, I went to visit my mother who was then living in

Greenwood, BC, Canada.  At the car rental place, because neither of the cars

available was acceptable -- perfumed cleaners are a non-computer risk some

face -- and because I am a frequent customer, I was upgraded at no extra

cost to a SUV, a SUV with a GPS navigator: the NeverLost system.  I did not

get lost, but that was not entirely due to the device.



I lost little time in starting to play with this new toy.



I found it interesting all of the streets that were nearby.  Unfortunately,

sometimes, the names were truncated, and in at least one case, the truncated

name made sense as a word.  I did not see any way to adjust the

magnification.



I saw that I could ask for a course to my mother's.  Unfortunately, the

interface was a bit confusing and rather than selecting the city of

Greenwood, BC (the smallest incorporated city in Canada), I accidentally

selected the then-current city and a street.  There is a street named

Greenwood in Bellingham.  There is also one in Lynden (near to Bellingham).

I found myself being directed to the south.  My mother's home was north and

east.  The device was quite persistent: "Please proceed to the designated

route."  Later, it got desperate, words to the effect of "When legal, please

make a U-turn."  I finally shut it off.



I tried again later, and it worked, mostly.  My mom lived on Kimberley

Street.  It is one of, if not the, longest street in Greenwood.  The device

did not know its name.  It did know many of the other streets, including the

cross-street by my mom's then-home.  The cross-street is two short blocks

long.  I finally programmed the device for the city centre of Greenwood.



I crossed the border at Sumas.  I then proceeded to Hope.  While on the way,

at one point I glanced at the display to see that a road was displayed to

the right.  This was disconcerting as that was where a cliff was.  The road

turned out to dead end.  I think it was a deactivated road, possibly the old

highway.



I usually stop at a certain gas station in Hope to buy a sandwich and drink.

In that area, there are under- and over-passes.  The device got confused.

It got its revenge shortly.  When I restarted the SUV, I looked at the

display and was confused.  The USA operates on the Imperial system of

measure, and Canada uses the metric system.  The device, recognising that it

was in Canada, had switched to metric.  When I looked more closely, I could

see the miles display.  It was rather smaller than the digits.



The gas station is on the old highway which parallels the current highway.

To get onto the current highway involves a few tight turns.  Some of these,

the device knew and some it did not.  I was directed to make turns when

there was no other road, but sometimes, the curve had no instructions.  This

also happened when I left Keremeos, BC.



The device warns about 2 Km before a turn and then just before.  The turnoff

for the Hope-Princeton Highway had already diverged from the main highway by

nearly one lane-width before the device announced the just before warning

that I should turn.  I was already in the correct lane.  Had I not been in

the correct lane, I could not have safely switched.



Not long after, I looked at the time display.  As it was just after noon, I

could not tell whether it was the time I would arrive in Greenwood or the

time left before I would arrive in Greenwood.  Later, I found that that

detail was documented on the card that was dangling from the unit, but many

other things were not.



While driving on the Hope-Princeton Highway, I found that many roads that

had no names were on the display, but that some roads that had names were

not present.



The Hope-Princeton Highway does run through wilderness, and in many places,

there are no other roads nearby.  That did not stop the device from telling

me three times each way to "Proceed to the designated route."  The voice is

a bit startling when it is not expected.



Glancing from time to time at the time-to-go display, I got suspicious.  It

seemed to be assuming 80 Km/h.  This is the default highway speed in BC, but

the Hope-Princeton Highway is known for being rather curvy in places.  It

has plenty of signs suggesting slower speeds.  At one place, the advisory is

20 Km/h.  In the summer, one can go bombing along much of the highway.  In

the winter, the curves get more dangerous, and you had better slow to 20

Km/h on the worst curve.  This was near the end of breakup, so conditions

could vary considerably.  What was the device assuming?



Princeton is at the west end of "The Regional District of

Okanagan-Similkameen".  The device displayed this from time to time clipped

to "Okanagan-Similkameen Region".  Much of this time, it displayed this next

to the road on the other side of the Similkameen River.  There was no

differentiation of region or city names from street names.  That road across

the river is called "Old Hedley Road".  When it finally was displayed, well,

the device leaves off the road designation.  The device did not display the

river though earlier, it had displayed much smaller creeks.



Leaving the village of Keremeos, BC, the road winds up a hill.  At the

bottom of the hill, there is a curve to the right (which the device told me

about), a curve to the left at the top of the hill (which the device did not

tell me about), and finally a right turn to the highway I wanted (which the

device told me about).  The up-shot was that I was told to make a right turn

followed by a right turn, and it did not make sense.  It was good that I

knew the road.  Had I blindly followed the advice, I would have gone down a

60 (or so) degree slope.



In the hamlet of Cawston, BC, the device thought that the main street

dead-ended and suggested accordingly.



I get paid in US dollars, so I prefer to spend US dollars.  Therefore,

rather than continuing through Canada, I cross at Nighthawk, WA, proceed to

Oroville, WA, fill up with gas, and cross back into Canada at Osoyoos, BC.



The device kept trying to get me to turn around.  I was wondering when it

would give up.  While I was wondering I saw a road displayed on the device,

but there was no road there, no sign of there ever having been a road there,

and no sign of anything else that the device should know about (such as a

creek).  A few miles past the border crossing, there is another road, a real

one.  The device seems to understand the world as segments.  When I got off

the segment, it recalculated.  The road to Oroville is a nice drive, very

pretty.  At least one of the roads that the device shows is actually a long

driveway.



Ah, Canada.  The device was displaying Imperial.  Remember how the device

switched measuring systems in Hope?  It switched again after I restarted the

SUV at the gas station in Oroville.  The system in use depends not on what

country you are in, but what country you were in when you started the

vehicle.  I found later that one can force the setting, but I did not

experiment to see if that locked down the measuring system used or that it

just lasted until the next vehicle startup.  Imagine explaining to a border

officer that you are experimenting with your GPS.  Guessing is such fun.



The device also had an odd idea of which way I should go.  As far as I can

tell, it intended to keep me on the highways.  I know of a shortcut, and I

took it.  The device did not handle it well.  Trying to get me back "on

course", it suggested some bad ideas.



1) One road to the left comes down a hill which is steep enough that the

road is broken into left and right branches.  The device suggested that I

take the far branch.  This would have necessitated a turn of approximately

150 degrees.  The near branch is about thirty degrees.



2) Later, it suggested that I take a right turn -- remember that the

previous suggestion was for a left turn? -- onto a narrow road with patched

potholes when I was on the best road around and which led straight to the

programmed route.



3) I rejoined the programmed route and prepared to turn right.  The device

was instructing me to turn left!



One thing that I never did solve was how to get the device to just display

without having a route programmed.  I wanted to see where I was without

having to select a destination.



The device has a safety feature that disables most of the user interface

when the vehicle is in motion.  It was also mounted so that the person in

the front passenger seat would not be able to see the display.  I thought

this was rather counterproductive.



When I set out to go home, I planned again to stop in Oroville for gas.

While I did not know the exact address, I thought I could get close.  For

some reason, the highway was not listed.  Unfortunately, the device requires

you to select first what you want (nearest city centre, a particular city

centre, or a particular intersection) then the city name.  The other way

around is much more natural to me.  It also would have been much quicker as

entering alphabetic was a slow process with no keyboard.



Again, I crossed the border at Nighthawk.  I crossed into the US a final

time.  The border between Canada and the USA is at 49 degrees north

latitude.  For some reason, the device told me I was in the USA when it

still displayed me at seven seconds of latitude north of the border.

According to my estimate, I was much closer.



I decided to let the device tell me how to get to Bellingham.  Understand

that I take a short route.  Roughly, I go west, then I go south.  The system

picked a route that was much longer and windier.  Among other places that I

saw, the oddly appropriate Chance Road.  In Osoyoos, it was trying to keep

me on the highways.  Here, it avoided them until the end.



I did make it home safely, and I certainly see where these devices are

useful, but much salt is needed.



------------------------------



Date: Fri, 18 Dec 2009 10:57:52 +0800

From: jidanni_at_private

Subject: GPS ads for captive bus riders (Re: Sullivan, RisKS-25.87)



Like the in-bus GPS "next bus stop" LED marquee boards here in Taiwan.

Between stops they have been programmed not to waste an idle moment, but

instead scroll "thank you for riding XYZ Bus Co." to riders

concentrating on them to learn the next stop's name.

At least accompanying audio just chants the stops.

Naturally everything must be repeated for each local language too.



------------------------------



Date: Sun, 20 Dec 2009 13:41:37 +1100

From: Steve Cody <steve_at_private>

Subject: Cruise control failed to disengage



Similar to recent reports of uncommanded acceleration, we had an incident

where cruise control could not be disengaged.  This link should bring up

related news items..

http://news.google.com.au/news/more?um=1&cf=all&ned=au&cf=all&ncl=diIb-MX_41mrfpMRXwbgO6EIxST7M

Or google news for "Cruise control Frankston"



------------------------------



Date: Wed, 16 Dec 2009 08:05:08 -0500

From: John Johnson <jvj_at_private>

Subject: Re: LED Traffic Lights are efficient but cannot melt away snow



The problem is also evident on motor vehicles with LED signal and stop lights.

Snow is not melted away by the signal and stop lights and 

accumulation blocks the lights.



new item: 

http://www.newser.com/story/76251/led-traffic-lights-efficient-but-cant-melt-away-snow.html



------------------------------



Date: Thu, 29 May 2008 07:53:46 -0900

From: RISKS-request_at_private

Subject: Abridged info on RISKS (comp.risks)



 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.

=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)

 if possible and convenient for you.   The mailman Web interface can

 be used directly to subscribe and unsubscribe:

   http://lists.csl.sri.com/mailman/listinfo/risks

 Alternatively, to subscribe or unsubscribe via e-mail to mailman

 your FROM: address, send a message to

   risks-request_at_private

 containing only the one-word text subscribe or unsubscribe.  You may

 also specify a different receiving address: subscribe address= ... .

 You may short-circuit that process by sending directly to either

   risks-subscribe_at_private or risks-unsubscribe_at_private

 depending on which action is to be taken.



 Subscription and unsubscription requests require that you reply to a

 confirmation message sent to the subscribing mail address.  Instructions

 are included in the confirmation message.  Each issue of RISKS that you

 receive contains information on how to post, unsubscribe, etc.



=> The complete INFO file (submissions, default disclaimers, archive sites,

 copyright policy, etc.) is online.

   <http://www.CSL.sri.com/risksinfo.html>

 The full info file may appear now and then in RISKS issues.

 *** Contributors are assumed to have read the full info file for guidelines.



=> .UK users should contact <Lindsay.Marshall_at_private>.

=> SPAM challenge-responses will not be honored.  Instead, use an alternative

 address from which you NEVER send mail!

=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.

 *** NOTE: Including the string "notsp" at the beginning or end of the subject

 *** line will be very helpful in separating real contributions from spam.

 *** This attention-string may change, so watch this space now and then.

=> ARCHIVES: ftp://ftp.sri.com/risks for current volume

     or ftp://ftp.sri.com/VL/risks for previous VoLume

 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive

 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.

   Lindsay has also added to the Newcastle catless site a palmtop version

   of the most recent RISKS issue and a WAP version that works for many but

   not all telephones: http://catless.ncl.ac.uk/w/r

 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .

==> PGN's comprehensive historical Illustrative Risks summary of one liners:

    <http://www.csl.sri.com/illustrative.html> for browsing,

    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing

==> Special Offer to Join ACM for readers of the ACM RISKS Forum:

    <http://www.acm.org/joinacm1>



------------------------------



End of RISKS-FORUM Digest 25.88

************************



Received on Sat Dec 26 2009 - 20:57:27 PST





]]>
Sat, 26 Dec 2009 20:57:27 PST
RISKS List Owner