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…
NIST is currently holding a competition to choose a design for the SHA-3 algorithm. The reference implementations of a few of the contestants have bugs in them that could cause crashes, performance problems, or security problems if they are used in their current state. Based on our bug reports, some of those bugs have already been fixed. Two of the projects (Blender and MD6) contained buffer overflows. The rest of the issues found were out-of-bounds reads, memory leaks and null dereferences. The code was good overall, but it's important to get these implementations right. They end up being the basis for future implementations, or used as is, and can be a factor is the outcome of the SHA-3 competition. More details about the issues: http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1 Joy Marie Forsythe, Security Researcher, Fortify Software 1-650-358-5621 jforsythe@fortify.com
The lack of an emergency brake exhaust valve in a locomotive must be a British peculiarity. Every American locomotive built within the past century has an emergency dump valve in the locomotive cab (and these are the Westinghouse brake design). When locomotives had firemen, the valve was located by the fireman's seat in case the engineer was incapacitated. Also, every American railroad passenger car has an emergency dump valve (aka the conductor's valve). In older cars this valve was connected to a cord which ran above the windows for the full length of the car. Modern cars eliminated the emergency cord, and now the handle for the conductor's valve is often found near the vestibule at the end of the car. It is often not very obvious, but the crew knows where it is. AL Stangenberger, Western Railway Museum [Added: Fri, 20 Feb 2009 19:43:15 -0800] I learned a lot more about railroad locomotive emergency brake valve requirements. Emergency brake valves are now only required by U.S. Federal law (49 CFR Ch. II, sec. 229.47) if the locomotive cab is designed for occupancy by more than one person. The requirement is actually for the valve to be accessible to a member of the crew other than the engineer. In the British case in RISKS, the US-built locomotive was designed for only one person in the cab, so the emergency brake pipe valve was not required. Possibly this policy should be reconsidered. In any case, though, it is not the case that nobody ever thought about having emergency valves in Westinghouse-design air brake systems.
<http://www.nytimes.com/2009/02/21/nyregion/21scam.html?emc=3Deta1> "A Nigerian citizen duped Citibank into wiring $27 million to accounts that he and others controlled, prosecutors said." Citibank accepted a package changing contact data for the National Bank of Ethiopia; and only months later noticed it came not from Ethiopia but Lagos, Nigeria. When they finally started looking into it; they also found the new contact numbers were cell phones in Nigeria, UK and South Africa. I'm reminded of the ex-President who'd never seen a grocery store scanner. An enormous international bank has never connected Nigeria and identity fraud? The Risk? Reliance on easily forged documents with no verification. Sometimes, a fraud too simple to ever work, shall...
Conrad De Aenlle, Fresh Starts: Digital Archivists, Now in Demand, *The New York Times*, 8 Feb 2009 When the world entered the digital age, a great majority of human historical records did not immediately make the trip. Literature, film, scientific journals, newspapers, court records, corporate documents and other material, accumulated over centuries, needed to be adapted for computer databases. Once there, it had to be arranged - along with newer, born-digital material - in a way that would let people find what they needed and keep finding it well into the future. The people entrusted to find a place for this wealth of information are known as digital asset managers, or sometimes as digital archivists and digital preservation officers. Whatever they are called, demand for them is expanding. One of them is Jacob Nadal, the preservation officer at the University of California, Los Angeles. He does not use the "digital" modifier because his duties include safeguarding analog materials in U.C.L.A.'s collection, not just preparing them to cross the digital divide. "I don't think there's any day where I would say I'm the digital guy," he said. But he concedes that he's not really an analog, ink-on-paper guy, either, and that is increasingly the case in his field. These days, he noted, "if you want to work in a library, you have to deal in electronic resources." Mr. Nadal and 10 or so colleagues at U.C.L.A. devote much of their effort to organizing and protecting material in digital form. Their duties include licensing and buying digital content from vendors, assigning identification markers called meta-tags so that material can be found easily, researching copyright matters and ensuring that files remain intact whenever new iterations of relevant software or hardware come along. ... http://www.nytimes.com/2009/02/08/jobs/08starts.html
Actually, the prank goes deeper. An anonymous IP (shorthand for non-registered editors on the Wikipedia), 78.34.237.194, a broadband user from Cologne, added the additional given name "Wilhelm" on 8 Feb 2009 at 9.40 pm for the newly designated German Minister of Commerce [1]. As a true blue-blood, he has more than the average number of them. On 9 Feb at 12.23 pm the administrator Arudaki complained that there was no source for this name, and removed all of the additional given names [2]. But by then the damage had been done, and the newspapers who had done a quick Wikipedia "fact"-check were already online and included the name "Wilhelm". A rage ensued, as people "fixed" the Wilhelm back in, quoting the now online sources that had used the faked Wikipedia entry. As is usual in a vandalism war, the page was removed from editing mode until people could cool down and get out a copy of the German peerage book [3] and discover that there was no "Wilhelm" listed there. The page is back being editable (and of course the pranksters keep putting in new names such as "Marcus", but they get quickly reverted (and the prankster given an hour in the corner, unable to edit). Anonymous then bragged about his or her heroic feat in [4], and it became clear that the German media relies heavily on the Wikipedia, without citation, of course. And this is not just the more yellow press, many newspapers printed the name. The risks? Don't rely on Wikipedia information for current events. And find a second, preferably offline, source for your information if you are doing serious journalism. Especially if you are doing print. [1] http://de.wikipedia.org/w/index.php?title=3DKarl-Theodor_zu_Guttenberg&oldid=3D56419545 [2] http://de.wikipedia.org/w/index.php?title=3DKarl-Theodor_zu_Guttenberg&oldid=3D56439344 [3] Genealogischen Handbuch des in Bayern immatrikulierten Adels, Band 17. Neustadt, Aisch, 1988 [4] http://www.bildblog.de/5695/wie-ich-freiherr-von-guttenberg-zu-wilhelm-machte/ with picture document of the Bild front page Prof. Dr. Debora Weber-Wulff,FHTW Berlin, FB 4, Internationale Medieninformatik (from 1.4.2009 HTW Berlin), Treskowallee 8, 10313 Berlin +49-30-5019-2320 weberwu@(f)htw-berlin.de http://www.f4.(f)htw-berlin.de/people/weberwu/
... From this I conclude that France is using Windows in its military. I thought nobody other than the US (and possibly the UK) were so foolish. http://cbfalconer.home.att.net
I got an e-mail alert from Capital One that a new message was in my account. The messages was a boilerplate warning that a phishing attach on Capital One was in progress. Unfortunately, the email alert was sent by a third party which Capital One uses for this purpose. Capital One does not have an SPF record for the sender, but is using SPF. GMAIL correctly marks this as a phishing letter and throws it into SPAM. If you try to read it you get the big bright GMAIL phishing warning! So I try to tell Capital One they have a problem. Their response is advice on how to turn the warning off! So much for their anti-phishing campaign.
Ireland doesn't yet have credit-card style licenses (they've been coming Real Soon Now for several years), but we've had the tri-fold licenses with standardised numbered fields for well over a decade. Mine is one. It defies belief that any Garda doesn't know how to figure out a driving license - no matter what it looks like - or establish someone's name from other documentation. Their internal performance rating depends on it, amongst other things. Further, Polish people have been working in Ireland since at least the late 1970's to my personal knowledge. They just didn't suddenly appear from nowhere. So 50 members of An Garda Siochana making the same mistake stretches credulity. It's far more likely to be a problem with their PULSE system, perhaps to do with data entry. It's known to be inflexible, and there were several expensive investigations into poor design and cost overruns before it went live. Something about this story doesn't add up.
Jeremy Epstein <jeremy.j.epstein@gmail.com> wrote about a product with an asterisk in the middle between two common words, making it almost impossible to find using search engines. IBM has done something similar: the hardware line once known as AS/400, then iSeries, then System i, is now known simply as "i", making it beyond impossible to find. I can't imagine what their marketroids were thinking.
There have been a number of claims in RISKS recently that bounds checking is impossible in C. These claims are false. In fact, there was a software product (Centerline) available for a number of years that checked bounds in C programs at run time. However, out-of-bounds array references are far from the only run-time transgressions in C programs that are both common and difficult to check. Another such is referring to memory after it has been freed. Such problems are exacerbated by the fact that at one time (before approximately 1980), freeing memory was guaranteed not to affect its contents--it was not until the next time you tried to allocate memory that any values would be changed. This phenomenon led to code such as this: struct node *p = listhead; while (p) { free(p); p = p->next; } Even worse, the original definition of realloc *required* the memory being reallocated to be freed first; if you tried to call realloc with memory that had not been freed, it would *always* allocate new space and copy the contents of the old memory block into the new space, relying on you to free the old block in the fullness of time. Thus the original definition of malloc and free encouraged, and sometimes required, programmers to use pointers to unallocated memory. This requirement made checking for legitimacy very difficult indeed. The definition of free and realloc were eventually changed to say that free was permitted to destroy the contents of the memory being freed, and that realloc could (and should) accept the address of a block that was already allocated, and would free the block after copying its contents elsewhere. That change at least made it plausible to check the legitimacy of pointers.
Ah! If only we had the right programming language, then we could write robust software. I have heard that refrain since the early eighties as I developed software in FORTRAN, BASIC, COBOL, C, C++ Pascal, Prolog and various assemblers, 4GLs, 5GLs and more. It remains, as it has always been, garbage. You can write robust code in almost any language and can write garbage just as easily. We have known for many years how to write robust software. We do not do so for one reason: cost. We can write junk software much more cheaply than the good stuff and nobody wants to pay the extra cost. 1. We skimp on training our programmers and architects. Maybe you can teach yourself <$PROGRAMMING_LANGUAGE> in 30 days (or whatever) but it takes many years to learn quality software engineering. 2. We rush through the specification phase. Stakeholders are too busy to give time to nailing down requirements. Sometimes we skip this stage altogether. 3. We skimp on the design phase. Frequently we just start coding with no thought of a proper architecture. Even when we do a design phase it is with mobile requirements and a short deadline. 4. We skimp on testing. We don't have adequate test specs. We don't have well trained testers. And the pressure to ship, so that we can book some revenue, is overwhelming. We chose not to produce quality software because all those things cost money and we'd rather make do with the cheap alternative. If we produced a word processor with almost zero bugs, an intuitive user interface and excellent performance, but it cost $50,000 per copy, we would not have a top seller. Though if every company summed all the cost of crashed and buggy software, bad products and training to manage poor interfaces, I wonder if it is still a bargain. Michael J Smith <emmenjay@zip.com.au>
If we're going to take Hoare's name in vain, let me point people to his Turing Award lecture from 1980: The first principle was security: ... A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. ... I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. And novelty? Circa 1966, I knew a magic incantation (in Fortran II, using some platform-specific subroutines) to interfere with the ability to do a soft reboot. (The machine in question was an SDS 920; as I recall, it didn't even have any disk drives.)
In this particular case I have to disagree: I believe with C it's not so much "hysterical raisins" as "nails and screwdrivers". What gets lost in advocacy hype is that creators of a programming language usually have a specific set of problems (real, perceived, transient or fundamental) in mind and are thinking of ways to solve them. The programmers get to choose what language to write in and it's their job to understand available tools and choose the right one for the task at hand. For some definition of "right". C was created to write portable operating systems in, not end-user applications. "Portable" is the big plus when you consider potential customers and all the different computing platforms they may have been using. The lack of proper high-level facilities is a minus, but what choice do we have — the language that has std:string and std::vector? Up until recently those weren't portable, and judging from past experience there's a good chance they'll revert to that state again when the next version of C++ standard comes out. Of course nowadays 99.9% of the target user base is using an x86-based platform with mice and graphical user interfaces, so one would expect the focus to shift to the tool that built-in GUI and runs on all x86 computers: Java virtual machine. Which has a whole lot of its own shortcomings and I'm sure 20 years down the track we'll read all about them in RISKS.
Not everyone in the "olden days" was as trusting as King Ables in RISKS-25-57. In the 1970's the Multics implementors at MIT and Honeywell were developing a time-sharing system. The language was PL/1, though that's a minor difference. Pointers that pointed to segments had bounds, and you got a hardware exception if you violated them. In PL/1 this was reflected as part of a higher level construct called the refer extent of a structure. The problem programmers happened alone the scene later on, with microprocessors and "personal" computers. The professional computer scientist was displaced by hordes of self-taught C coders. I hope to live to see today's programming paradigms replaced, I'm on my third round of "what where those idiots thinking?" Randy Saunders, JHU Applied Physics Lab +1.240.228.3861 R.Saunders@IEEE.org
This may be pure coincidence but it struck me as very odd. I use Earthlink as my E-mail provider. I have the 'spam' setting set to put all suspicious things into a 'spam folder' which I look at every few days (as opposed to them automatically being deleted). During the U.S. presidential campaign, I would frequently find E-mail from 'Democratic' candidates AND conservation groups in this folder. Not once did I find any E-mail from Republican candidates in this folder. I flagged the Democrat and conservation E-mails as 'not spam' which supposedly sent copies to Earthlink to figure out why they were improperly marked as spam. However, this kept up until AFTER the election was over. Then all my mail was delivered correctly. I'm not accusing Earthlink of anything duplicitous but I did find it curious. Duane De Vries, Retired, ex-computer geek, practicing curmudgeon
> Steven J Klein asked, "Why not use the social security number, which is guaranteed to be unique?" In California, Civil Code Section 1798.85 generally prohibits the use of Social Security numbers as identifiers, especially for Internet services. This law is the result of numerous instances where Social Security numbers were not adequately protected from improper disclosure, resulting in identity theft. Of course, this law cannot be enforced against services based outside of California. David E. Ross <http://www.rossde.com/>.
Preventing siblings with the same birthdate from being entered via the Web site seems like a reasonable precaution, especially given that there is an easy fallback, i.e., calling and giving the information over the phone. On the other hand, I acknowledge that I might see it differently if I had been thus inconvenienced. Steven Klein's story about his problem with the USAA Web site brings to mind a problem I had with the site last week which might be of interest to RISKS readers. I was entering the information on the Web site for myself and my wife, when I found listed in my wife's profile a "parent" whose name most certainly was not the name of one of my wife's parents. I sent USAA a message about this through their Web site, and they confirmed that the "parent" had been added to my wife's profile in error and they had removed it (I was not able to remove it myself through the Web site). I don't know what precautions USAA has in place to prevent such "errors" (e.g., do their member numbers have a checksum digit to detect mistyping?), but something definitely seems wrong with the fact that someone was able to attach a complete stranger to my wife's record in their database.
Kevin Way's description of the absurd hoops demanded by Trend Micro before removing static IP ranges from their DNS blocklists reminded me of an incident which occurred during the 2008 U.S. Presidential Campaign. I was an active volunteer for one of the candidates and thus regularly received bulk emailings and email list messages from his campaign. At some point during the campaign, the flow of email petered out to nothing. Eventually I realized that this was because one of the blocklists my mail server was configured to use, NJABL, had the candidate's mail servers listed as spam sources. Only registered users of the candidate's site and donors to his campaign were added to his mailing lists, and every single message sent by the candidate had a working unsubscribe link at the bottom of it, so the candidate could not reasonably be categorized as a spammer. I contacted both the maintainers of NJABL and the webmasters of the candidate's site, pointing out that the site was listed in the blocklist and suggesting that perhaps one or more people who opposed the candidate had falsely reported his site as a spam source as a political dirty trick. I received no response from either NJABL or the webmasters, and after waiting in vain for several days for the problem to be fixed, I threw up my hands and removed NJABL from the set of blocklists my server was using. I'm now using only the Spamhaus ZEN blocklist, which apparently has somewhat more rigorous procedures than NJABL. The implications of being able to use DNS blocklists as weapons in political campaigns are quite frightening.
National Cyber Alert System Technical Cyber Security Alert TA09-051A [PGN-excerpted: Please see the cited item in case of updates.] Adobe Acrobat and Reader Vulnerability Original release date: February 20, 2009 Last revised: -- Source: US-CERT Systems Affected * Adobe Reader version 9 and earlier * Adobe Acrobat (Professional, 3D, and Standard) version 9 and earlier Overview Adobe has released Security Bulletin APSB09-01, which describes a vulnerability that affects Adobe Reader and Acrobat. This vulnerability could allow a remote attacker to execute arbitrary code. I. Description Adobe Security Bulletin APSB09-01 describes a memory-corruption vulnerability that affects Adobe Reader and Acrobat. Further details are available in Vulnerability Note VU#905281. An attacker could exploit these vulnerabilities by convincing a user to load a specially crafted Adobe Portable Document Format (PDF) file. Acrobat integrates with popular web browsers, and visiting a website is usually sufficient to cause Acrobat to load PDF content. II. Impact An attacker may be able to execute arbitrary code. III. Solution Disable JavaScript in Adobe Reader and Acrobat [...] Prevent Internet Explorer from automatically opening PDF documents [...] IV. References * Adobe Security Bulletin apsa09-01 - <http://www.adobe.com/support/security/advisories/apsa09-01.html> * Securing Your Web Browser - <http://www.us-cert.gov/reading_room/securing_browser/> * Vulnerability Note VU#905281 - <http://www.kb.cert.org/vuls/id/905281> The most recent version of this document can be found at: <http://www.us-cert.gov/cas/techalerts/TA09-051A.html> Feedback can be directed to US-CERT Technical Staff. Please send email to <cert@cert.org> with "TA09-051A Feedback VU#905281" in the subject. For instructions on subscribing to or unsubscribing from this mailing list, visit <http://www.us-cert.gov/cas/signup.html>. Produced 2009 by US-CERT, a government organization. Terms of use: <http://www.us-cert.gov/legal.html> Revision History February 20, 2009: Initial release
Please report problems with the web pages to the maintainer