Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The highly touted robot race staged by the Pentagon in an effort to boost R&D in driverless vehicles has ended with all 15 self-navigating devices petering out within a few miles of the starting gate — victims of technical glitches, barbed wire fences and rough terrain. The Defense Advanced Research Projects Agency had spent $13 million on its Grand Challenge, which offered a $1 million prize to the creators of the vehicle that could complete a 150-mile race across the Mojave Desert within 10 hours. Team members were not allowed to touch or steer the vehicles and most of the robots stalled, overturned, or ran off the course shortly after taking off. Defense officials foresee using such autonomous robotic vehicles to ferry supplies in war zones. [AP 15 Mar 2004: NewsScan Daily, 15 Mar 2004] http://apnews.excite.com/article/20040315/D81AQ3M00.html
For RISKS readers, it should be no surprise that none of the competitors got very far in the first robotic Grand Challenge of such scope. This challenge is a fine example of an *overall system* problem where *everything* counts, not just mechanical and electrical robustness, software reliability, fault tolerance, vision processing, incredible foresight in choosing system requirements, good software engineering, sound programming languages, design for survivability, etc., but also real-time awareness of and reactiveness to the surrounding physical and logical environments. Furthermore, security was not even a concern this time around — although it would be absolutely critical in any real military deployment. In actual battle conditions, defending against and responding to all sorts of denial- of-service attacks would have to be in scope, including electromagnetic jamming, remote penetrations, sabotage, and so on. (Here, each vehicle had a remote manual trigger that would cause it to halt in case human lives — or even a protected tortoise — were about to be threatened. Of course, such a safety-contingency mechanism could also be potentially misused by competitors, although I presume there might have been rules against such actions in this case — or at least suppositions that an eventual winner might be disqualified for having engaged in such tactics.) Knowing what we know about RISKS and human frailty, I am always concerned about people overendowing a sense of operational certainty toward fully automated vehicles. (For example, think about the completely automated highway and what might happen in the event of noncompliant participants or unanticipated events.) At any rate, the prize remains a Grand Challenge for the future — or, actually, a kilogrand Grand Challenge, because *one grand* is *one thousand dollars*. (Note for foreign readers: American slang!) Incidentally, after commenting on watching the event, Paul Saffo called it ``Woodstock for Warlords''. PGN
An article out at eWeek.com that RISKS readers can relate to all too well: http://www.eweek.com/article2/0,1759,1543652,00.asp?kc=EWNWS030804DTX1K0000599 It reviews the risks of software/human interactions that have lead to injuries or death of the human component of the equation. A fairly comprehensive summary of what has been covered here many times in the past.
Bruce Schneier's CRYPTO-GRAM for March 2004 had a pointer to this article: http://zdnet.com.com/2100-1104_2-5164413.html from which I quote: Spanish developer Pablo Soto, whose Blubster and Piolet software have attracted several hundred thousand users, is taking a decidedly different tack. [...] Information such as an MP3 song will still be downloaded from its original source, he said. But a song will be scrambled, and downloaded simply as raw, unintelligible data. This means that no actual copy of a song is being exchanged, he contends. If downloaders want to turn that data into usable music, their software must seek elsewhere on the file-swapping network for the encryption "keys" that will unlock the data, transforming it back into an MP3. Separating the download of the data and the keys may help protect file sharers from lawsuits, making it more difficult for courts to say exactly which party is responsible for copyright infringement, Soto said. This reminded me immediately of my favorite RISKS article, "The source of semantic content" (Gat, RISKS-16.87). Perhaps Gat's questions "Has the law been broken? Who broke it?" will soon be tested in court.
The Bureau of Labor Statistics (BLS) has been unable to compute the Producer Price Index (PPI) for January or February due to delays in implementing a change in the way data is organized. The switch of the industry classification system used has already been done for most BLS data, according to a Reuters report, but the "PPI had to remap some 40,000 industry units and about 120,000 items before re-aggregating the data into four indexes" in the PPI. The assistant commissioner responsible for the PPI said "God knows when" the January numbers will be out. He blamed "aging computers" which could not handle a dry run before pulling the plug on the old system, and "30-year-old systems" that are not conversion-friendly. The PPI measures wholesale prices and is an early indicator of inflationary trends, future corporate profitability and hiring, etc. A report on public radio's morning MarketPlace Report on Friday March 12 alluded to business contracts with prices based on the current PPI. Source: Reuters, "U.S. Blames Aging Computers for PPI Delay" by Andrea Hopkins (no relation), 9 Mar 2004, found on Yahoo. [Andrea may be no direct relation, but Bill may have many other one-hop-kins-men. PGN]
California's Attorney General circulated a document to fellow state attorneys general outlining a strategy for a legal attack on the makers of peer-to-peer software. However, the document was in Microsoft Word, and the metadata revealed that the document's actual author was "stevensonv", apparently Vans Stevenson, the MPAA's Senior Vice President for State Legislative Affairs. http://www.wired.com/news/digiwood/0,1412,62665,00.html?tw=wn_tophead_1
One Sequoia Optech electronic machine used to count optical-scan paper absentee ballots in the 2 March 2004 California primary in Napa County failed to record votes on some ballots. This was detected by chance in a random 1% recount. As a result, the county will re-scan over 11,000 ballots, which could possibly change the results of some close local races. The machine was miscalibrated to detect carbon-based ink, but not dye-based ink commonly used in gel pens. (The pre-test was done only with carbon-based ink.) [Of course, the random test might not have noticed other machines that were similarly miscalibrated. PGN] Kim Alexander said the county was lucky that the problem occurred on a system with a paper trail. "If the problem had occurred with their electronic ballots or with the tabulation software (which sits on the County server), they would have been hard pressed to reconstruct their election. Or, they might not have ever known there was a problem at all. If they were doing the manual count on the electronic ballots there would be no record to look at to determine what the accurate vote count should be." [Source: Kim Zetter, Wired News, 12 Mar 2004; PGN-ed] http://www.wired.com/news/politics/0,1283,62655,00.html
In the 2 March 2004 California in Alameda and San Diego Counties, some voters were delayed or turned way from polling places. In Alameda County, about 200 of their 1,096 voting precincts experienced problems with the precinct-control module encoder machines that provide voters with an access card for Diebold touch-screen machines. Some voters were able to fill out provisional paper ballots. However, apparently many voting places ran out of paper ballots, and voters were turned away in at least 25 polling places. [Sources: Ian Hoffman, Electronic-voting machine snafus leave votes in limbo *The Argus* (Fremont, CA), 4 Mar 2004, and Thomas Peele and Sam Richards, Voters turned away by encoder problems, *Contra Costa Times*, 12 Mar 2004; PGN-ed.] The Argus article had this quote: Alameda County elections officials ``were swamped Tuesday morning by some 200 calls for help from poll workers in all parts of the county. Diebold representatives said part of the problem seemed to be a low battery charge in the voter-card encoders, causing them to boot up into an unfamiliar Windows screen.'' As we noted earlier (RISKS-23.07), in the 17 counties in which Diebold systems were used, none of the versions of those systems actually used was the version that had been certified. There were numerous reports in the past weeks of malfunctions and irregularities elsewhere as well. I would have to spend more time than I have to catalogue them all in RISKS. But I think you get the idea from what we have included here that there are vastly too many problems that could influence the results of close elections, often with no recourse to find out what was really intended.
Google is in many ways the most useful tool available to the bad guys, and the most dangerous Web site on the Internet for many, many thousands of individuals and organizations. By Scott Granneman, 9 Mar 2004 In my last column, I provided a checklist for Windows users that would help them secure their computers. I created that checklist because it has become increasingly and painfully obvious to me that most home users — and most small businesses and organizations — have substandard security practices in place, if they have any at all. The checklist was designed to help secure things on the perimeters: on client computers and at the edges of home and business networks. This week, I want to talk about servers. Specifically, let's talk about the stuff that people are serving without realizing it. Security pros have known about this problem for years, but most computers users still have no idea that they may be revealing far more to the world than they would want. In fact, it wouldn't be far from the truth to say that Google is in many ways the most useful tool available to the bad guys, and the most dangerous Web site on the Internet for many, many thousands of individuals and organizations. [...] http://www.securityfocus.com/columnists/224
Netcraft reports that phishers are using real and fake SSL certificates to fool computer users into thinking that they are using the site they hope to be using instead of the phisher's site. The report is here: http://news.netcraft.com/archives/2004/03/08/ ssls_credibility_as_phishing_defense_is_tested.html and is worth a read even if, like me, you've been a regular RISKS reader for years. The phishers must be on to something, as they are putting a lot of research and effort into this scam. One thing I didn't know: SSL allows a "plain text" encoding, that doesn't require a signed certificate, yet browsers show a locked padlock as a site using encryption would display. I'm not sure whether I should whack the browser authors, the SSL implementors or the SSL designers on the head for this. My advice on phishing avoidance: never click on a link in an e-mail from a financial institution, always navigate from a bookmark. If possible, avoid typing in web addresses too, in case you misspell and a phisher has taken the misspelled site hoping to catch unlucky typists. And never, ever use a public terminal such as in a cyber cafe or library to enter *any* password at all, due to physical or software keyboard sniffers. Alistair McDonald +44 (0)7017-467386 http://www.inrevo.com
As part of a hobby, I write vehicle tracking software that plugs into cheap external mapping software to create an entire application without me needing to worry about dealing with maps - I just need to tell the mapping program where to display positions, and it just goes and does it. Now, I use two interfaces to the mapping software - one using API calls sending the positions as parameters of the API call for adding points to the map. The second interface involves creating a dummy GPS data line (starting with $GPRMC), and sending this to the application for use with the moving map functions. In the last few days I have been exchanging e-mail with a user in Canada who has been complaining that the positions on the map for the mappoint are correct at about 48N and 71W, whereas the moving map functions are saying about 80N and 0W. Of course the points should be identical. My software sends the mappoint through the API, and then generates and sends the fake GPS position. The software is written in Visual Basic version 6. Some of my code appears below. lat = Abs(lat) nmeastring = Format(Int(lat), "00") lat = lat - Int(lat) lat = lat * 60 nmeastring = nmeastring & Format(lat, "00.000") On most systems this correctly encodes the latitude into degrees followed by decimal minutes. Unfortunately on systems where the locale has been changed to have a comma as a decimal place, then Visual Basic ignores the fact that I have specifically stated that I want to use a decimal point when I format the number into a string, and changes it to a comma. To be fair to Microsoft this is listed in the manual Visual Basic 6. Of course since the NMEA sentence I am generating uses commas as field delimiters, the fields are getting totally messed up. And the mapping software is making its best effort to display the obviously incorrect position. The risk: using the same character to denote decimal places as for denoting different fields is not a good idea. Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia Mobile Number 0412 929 634 [+61 4 12 929 634 International] www.radio-active.net.au - www.radio-active.net.au\web\tracking
My bank has decided that two trusts for which I am a trustee are in fact "the same", despite being "for the benefit of" different individuals, and having different Taxpayer Identification Numbers. Or, at least, the trusts have different TINs, and the accounts _used_ to have different TINs, but the first of two lines on the bank's forms is the same for the two trusts, and my address is, naturally, the same for both, and that's "close enough" for them to decide to report all income for both trusts as being paid to one TIN. I am now at four weeks calendar time, four hours phone-log time directly interacting with them, and three forms signed in duplicate. So far, all it has gotten me is that they issued _another_ 1099 (report to the IRS of interest paid), now reporting all income to the _other_ TIN. Plus an oddly-formatted (no spaces between words) e-mail claiming that they would "take care of it and issue another 1099" (note: _an_other, I shudder to think...) Meanwhile, April 15th is closer than it appears... Risks? Obviously, someone, or something, at the bank was able to change the TIN on an account without the permission, or even notification, of the account holder. Yet enormous effort is required (so far unsuccessfully) to correct the mistake. This scheme (easy to break, hard to fix) is breathtakingly wrong. I would go to another, perhaps more competent bank, but every time I do, they get bought by the likes of these incompetents. Hence the double meaning to "Merger Mania".
It seems that the Beagle virus is doing the rounds again with a new interesting twist to the social engineering used previously. In this case it seems to send you an e-mail saying that your mailing system will be out of action for two days and to follow the instructions in the attachment. > Dear user of "Btopenworld.com" mailing system, Our main mailing server > will be temporary unavailable for next two days, to continue receiving > mail in these days you have to configure our free auto-forwarding service. > > For further details see the attach. > > Cheers, > The Btopenworld.com team > http://www.btopenworld.com It's fairly transparent to RISKS readers, but to someone less savvy it might seem quite plausible. Of course, given btopenworlds recent conjoining of its services with Yahoo! and the confusion that caused some users, people should be forgiven if they fall for this. The risk of a well-timed and well-written e-mail of this sort should not be underestimated.
> With the multitude of gauges in a cockpit this is a brilliant way to quickly scan the status of the various components of the airplane. This should not be remarkable, and it is certainly not original. When I served aboard Nuclear Submarines more than 10 years ago, all the instruments in the Engineering control room were designed such that at roughly normal operation, all needles pointed up (all analog instruments). There were a few that weren't pointing up, due to their nature — we used to talk about the Beauty of analog — you could take a mental "picture" of normal, and identify off-nominal very rapidly, much more so than if you had to process each number. In the 1980s, the B-1 Lancer bomber was remarkable for a similar "innovation" — they used LED bargraphs lined up next to each other for engine instrumentation, and when all was normal at cruise, there was a straight line across several (~10, I think) instruments.
DM> On the other hand, there's no reason to believe anyone will rush to DM> implement new and improved SMTP when/if ever that comes along. It is "when", not "if ever". Two projects for replacing SMTP-based Internet mail, IM2000 and "mail-ng", exist right now. DM> nobody's in a hurry to switch to IPv6, are they? Actually, IP version 6 is a good example, because it is a bad example. It doesn't actually support that point at all. In a U.S.-centric view of the world, perhaps nobody is in a hurry to implement IP version 6. But there are other parts of the world that are quite enthusiastic about implementing it, because they are significantly inconvenienced by IP version 4. The same is true of a replacement for SMTP-based Internet mail. There will be those who, because they have reached the stage where SMTP-based Internet mail is simply unusable, will be enthusiastic about adopting a suitable replacement.
> From: "Stanley F. Quayle" <stan@stanq.com> > Subject: Re: Buffer overflows and VMS > C programmers moving to OpenVMS quickly discover what the ACCVIO error > message means. BTW: SYS III Lint core-dumped when I first ran it on itself, under VMS :-) > From: "Bill Hopkins" <whopkins@wmi.com> > Subject: Re: Buffer overflows and Burroughs/Unisys > Since C's memory abstraction is basically the hardware address, and > addresses can be manipulated arbitrarily, [...] Anybody else note the dissonance here? In fact the C language, while not as "tight" as, e.g. Ada, does provide sufficient opacity of pointers to accomplish pretty good bounds-checking. Of course, not much "alleged C" code would run on such a system. I submit it is _because_ too many implementors accepted the notion that "C has pointers that are no more than tarted-up machine addresses" and didn't even consider implementing _real_ C pointers on machines which would support them. The original "oh, cut them some slack" led to a generation of programmers who actually believe such dreck as "packed structs" and "result of a cast is a modifiable lvalue" _is_ part of C. The risk: If you take a sufficiently dim view of your ability to enforce language specs, and give up at the start, you'll get, well, the current situation, and risks...
2004 IEEE Symposium on Security and Privacy
May 9-12, 2004, The Claremont Resort, Oakland, California, USA
sponsored by
IEEE Computer Society Technical Committee on Security and Privacy
in cooperation with
The International Association for Cryptologic Research (IACR)
For more information, see http://www.ieee-security.org/TC/SP-Index.html
For registration, see http://www.cics.unt.edu/ieeereg/register.php
[Info on registration/local arrangements at www.ieee-security.org.]
Monday MORNING
Session: Attacks and Defenses
* Keyboard Acoustic Emanations, Dmitri Asonov, Rakesh Agrawal (IBM Research)
* Effects of Mobility and Multihoming on Transport-Protocol Security
Tuomas Aura (Microsoft Research), Pekka Nikander (Ericsson Research),
Gonzalo Camarillo (Ericsson Research)
* Analysis of an Electronic Voting System
Tadayoshi Kohno (UC San Diego), Adam Stubblefield (Johns Hopkins Univ.),
Aviel D. Rubin (Johns Hopkins Univ.), Dan S. Wallach (Rice Univ.)
Session: Theory of Access Control
* Access Control By Tracking Shallow Execution History
Philip W. L. Fong (U. Regina)
* A Layered Design of Discretionary Access Controls with Decidable
Safety Properties, Jon A. Solworth, Robert Sloan (U. Illinois, Chicago)
Monday AFTERNOON
Invited Talk
Session: Cryptography
* Symmetric encryption in automatic analyses for confidentiality against
active adversaries, Peeter Laud (Tartu University)
* Automatic Proof of Strong Secrecy for Security Protocols
Bruno Blanchet (Ecole Normale Superieure)
5-minute work-in-progress talks
Tuesday MORNING
Session: Denial of service
* An empirical analysis of target-resident DoS filters
Michael Collins (CERT), Michael Reiter (CMU)
* Large-Scale IP Traceback in High-Speed Internet: Practical Techniques
and Theoretical Foundation, Jun Li, Minho Sung, Jun (Jim) Xu (Georgia Tech),
Li (Erran) Li (Bell Labs)
* An Endhost Capability Mechanism to Mitigate DDoS Flooding Attacks
Abraham Yaar, Dawn Song, Adrian Perrig (CMU)
Session: Access Control and Privacy
* Safety in Automated Trust Negotiation
William H. Winsborough (George Mason Univ.), Ninghui Li (Purdue Univ.)
* Securing OLAP Data Cubes Against Privacy Breaches
Lingyu Wang, Sushil Jajodia, Duminda Wijesekera (George Mason Univ.)
Tuesday AFTERNOON
Panel Session
Session: Static Analysis
* Run-time Principals in Information-flow Type Systems
Stephen Tse, Steve Zdancewic (U. Pennsylvania)
* Formalizing Sensitivity in Static Analysis for Intrusion Detection
Henry Hanping Feng (U. Mass., Amherst), Jonathon T. Giffin (U. Wisconsin,
Madison), Yong Huang (U. Mass., Amherst), Somesh Jha (U. Wisconsin
Madison), Wenke Lee (Georgia Tech.), Barton P. Miller (U. Wisconsin Madison)
Wednesday MORNING
Session: Network Security
* Fast Portscan Detection Using Sequential Hypothesis Testing, Jaeyeon
Jung (MIT), Vern Paxson (ICIR), Arthur W. Berger, Hari Balakrishnan (MIT)
* On-the-Fly Verification of Rateless Erasure Codes for Efficient Content
Distribution, Maxwell N. Krohn (MIT), Michael J. Freedman,
David Mazieres (NYU)
* Multicast Authentication in Fully Adversarial Networks
Anna Lysyanskaya, Roberto Tamassia, Nikos Triandopoulos (Brown Univ.)
Session: Security Against Physical Attacks
* An Interleaved Hop-by-Hop Authentication Scheme for Filtering False
Data Injection in Sensor Networks, Sencun Zhu, Sanjeev Setia,
Sushil Jajodia (George Mason Univ.), Peng Ning (NC State Univ.)
* SWAtt: Software-based Attestation for Embedded Devices, Arvind Seshadri,
Adrian Perrig (CMU), Leendert van Doorn (IBM and CMU), Pradeep Khosla (CMU)
Please report problems with the web pages to the maintainer