Date: Wed, 29 Sep 2004 14:42:47 -0400 (EDT) From: email@example.com Subject: CDT Headline: Federal Judge Strikes Down Part of PATRIOT Act List-Archive: <http://www.cdt.org/pipermail/cdt-announcements/> A federal judge today found unconstitutional a part of the USA PATRIOT Act that allows federal law enforcement officials to obtain confidential financial records without a court order or other safeguards. The lawsuit, brought by the ACLU, challenged the use of so-called "National Security Letters," a type of administrative subpoena power that was expanded by the USA PATRIOT Act. For more on the USA PATRIOT Act: http://www.cdt.org/security/010911response.shtml For more information on the ACLU lawsuit [offsite]: http://www.aclu.org/SafeandFree/SafeandFree.cfm?ID=15543&c=262
On Sunday, September 26, I attempted to exchange a $21.99 cable for a $26.99 cable at my local Radio Shack. The manager informed me that all 7000 Radio Shack stores nationwide were unable to process transactions due to a computer outage. I asked if I could simply leave the $5 difference in cash and let the store sort things out when they were back online, but I was told that this was not possible and to please come back in a couple hours.
A note in RISKS-23.52 about the state computers in Illinois being offline for an hour prompts me to send in the following. Georgia may be last in piddlin' stuff like SAT scores and teacher salaries, but we know how to have *major* downtime! "A 16-hour shutdown of the state government's computer networks Tuesday could have been prevented if officials had heeded an earlier warning that the computers needed replacement batteries. The state's computers froze for the entire business day Tuesday, shuttering tag offices and delaying court-ordered child support payments to 516,000 Georgia children, among other problems. The shutdown was caused by a power outage at Georgia Power Co. as the remnants of Hurricane Frances swept through the state. But the computers never should have been running on electricity. An April report by a state consultant noted that batteries that normally power the computers had gone bad and two backup generators had failed. Officials with the Georgia Technology Authority told The Atlanta Journal-Constitution that they learned of that consultant's report just last month, and didn't have time to implement its recommendations before this week's bad weather." http://wsbradio.com/news/090904statecomputercrash3a.html I particularly like the part about "the computers never should have been running on electricity." White lightnin', maybe? Bob Harbort, Southern Polytechnic State U., CS/Software Engineering 1100 S. Marietta Pkwy. Marietta, GA 30060-2896 firstname.lastname@example.org 1.678.915.7405
With California just wisely enacting a secure, voter-verified paper trail law relating to electronic voting machines, many other states following a similar path, and related federal legislation also being considered, it appears that this methodology is likely to become a fixture in many, most, or even all U.S. jurisdictions where touch-screen or other e-voting machines are in use. However, I haven't seen discussion of a likely side-effect of this welcome trend -- its impact on proponents of voting over the Internet. If a secure, voter-verified paper trail is being required for e-voting machines operating in the theoretically "secure" environment of polling places, it's quite possible that we're finally putting a stake in the heart of the extremely ill-advised and highly risky idea of Internet-based voting, even if the laws regarding paper trails may not address this issue specifically. Keep in mind that typical voter-verified paper trail systems permit the voter to inspect the receipt but not to handle or remove it -- the receipt must stay under the control of the voting authorities at all times. These twin requirements cannot be simultaneously met in remote Internet voting situations (e.g., people voting from their homes or offices, which are the big "selling points" for those persons pushing Internet voting). No doubt the proponents of Internet voting will suggest all manner of bizarre schemes involving encoded receipts that could be physically mailed back to voting authorities or other similar completely impractical ideas. But the bottom line is that if a secure, voter-verified paper trail is needed for e-voting machines -- and it is -- then Internet voting should be considered to be dead on arrival for the foreseeable future at least. Lauren Weinstein email@example.com firstname.lastname@example.org +1 (818) 225-2800 http://www.pfir.org/lauren http://www.factsquad.org [Incidentally, the October issue of the *Communications of the ACM* has a special section with 8 papers devoted to voting systems. PGN]
Switzerland has declared Internet voting a success after being used without problems in a national referendum in which 2,723 people in four Geneva suburbs visited a special Web site to cast their votes on various issues. Swiss officials says the test has proven their systems are robust and secure, but e-voting critic Avi Rubin of Johns Hopkins University is unconvinced: "Just because nobody attacked a referendum that involved 2,723 people does not mean that it was secure. When these trials are viewed as successful and justify more in-depth electronic voting, eventually there will come a point where it will be worth someone's while to attack the election." Geneva's e-voting system uses software developed by local election authorities with the Swiss office of Hewlett-Packard Co. and the Geneva-based online security firm Wisekey. [AP/*USA Today*, 27 Sep 2004; NewsScan Daily, 28 Sep 2004] http://www.usatoday.com/tech/news/2004-09-27-swiss-evotes_x.htm
The Netherlands is currently holding the election for the Regional Water Management Boards (my translation of "Waterschappen"). One can vote by mail or by Internet. The latter attracted my curiosity, and I poked around the 'net a bit to see what people thought about the idea. It appears that a test election was held in order to test the procedure and get some feedback from test voters. An often quoted feedback was that "Only 26% of the test voters expressed concern about the possibility of fraud". ONLY 26%?? This response seems to be interpreted as a vote of confidence for the system. Another nugget: "The secrecy of the vote is guaranteed. The relationship between the voter identity and his login code is removed from the file before the votes are counted". The FAQ also has an interesting statement. An independent body (TNO) has investigated the security of the voting method. They concluded that "Voting by Internet is not less safe than voting by mail or phone". This formulation implies that the procedure is actually not very safe, and they know it. I cast my vote today. And my wife's! With her permission, but I could equally well have voted for her without her knowing about it. All you need in order to vote is a couple of codes contained in a letter delivered by post. Since I happened to be the one emptying the mailbox yesterday, I retrieved my own ballot, my wife's and my daughter's. And what about mail delivered to the wrong address, that happens quite regularly. But not today, so, sadly, I was unable to vote on behalf of any of my neighbours. Slightly to my surprise, the voting web site worked well in Netscape, except that Netscape aborted just after I had completed the second vote. At the end of the voting process, you get a code, consisting of a total of 40 hex digits in 3 sub-fields. Allegedly, this code can be used, after the election has closed, to "check whether the vote was counted". If you do not take note of these codes here and now, they are lost for good, there seems to be no way to retrieve them later. The page displaying the codes posts the warning "Keep these codes secret, your vote can be derived from them". It seems to me that there is no way to guarantee that "the vote was counted", only that it was registered somewhere. You have to take their word that this is actually the file that is counted, that nobody messed with it, and that counting is done correctly and honestly. The Water Management Board election is not a very high-profile election, many show little interest in what these boards are doing. You vote for individuals, not for political parties, and the campaign preceding the election is not very intense, possibly because no party politics is involved. So it may not be very fraud-sensitive. But I am afraid that if this type of elections is declared a success, the technology may show up in more important elections.
Great news to share -- California Governor Arnold Schwarzenegger signed SB 1438 into law. This bill, co-authored by Senators Ross Johnson (R-Orange) and Don Perata (D-Alameda) requires there to be a voter verified paper record to back up every electronic ballot cast in California by 2006 Primary election. California is the first state in the nation where paperless, electronic voting systems have been widely deployed that is requiring by law that the machines be retrofitted or replaced. With the enactment of SB 1438, California continues to lead the nation on electronic voting reform. Two other states -- New Hampshire and Oregon -- have laws that mandate the use of voting systems that allow for manual recounts. Illinois passed a law that requires a voter verified paper trail for e-voting machines once that state begins purchasing them. Five Secretaries of State have elected to implement the voter verified paper trail. The first to do so is Dean Heller of Nevada, who is implementing the paper trail this election season. In addition, the Secretaries of State in Washington, Missouri, California, and Ohio will require the paper trail by 2006. Although paper trail legislation was introduced in as many as 20 states this year, it appears that California is the only state so far to enact a paper trail law. SB 1438 essentially codifies California Secretary of State Kevin Shelley's November 2003 and April 2004 security directives, and advances the deadline for implementing the paper trail by one election. Under the Secretary of State's orders, California would have the paper trail by the November 2006 election. SB 1438 ensures the paper trail will be in place for the 2006 Primary. The new law also prohibits the Secretary of State from certifying any new, paperless electronic voting systems after January 1, 2005, and prohibits counties from purchasing such systems after January 1, 2006. Proclaimed "dead" just last month, SB 1438 was brought back to life by its authors in the 11th hour of the legislative session, and sailed out of the Legislature on unanimous votes of both houses. For more information about SB 1438, visit http://www.leginfo.ca.gov/cgi-bin/postquery?bill_number=sb_1438&sess=CUR&house=B&author=johnson http://www.leginfo.ca.gov/cgi-bin/postquery? bill_number=sb_1438&sess=CUR&house=B&author=johnson [SPLIT URL] For past CVF-NEWS updates on SB 1438, visit http://www.calvoter.org/news/cvfnews/2004archive.html . -- Kim Alexander, President, California Voter Foundation email@example.com, http://www.calvoter.org, 916-441-2494 Contact the California Voter Foundation: http://www.calvoter.org 530-750-7650 firstname.lastname@example.org U.S. Mail - 503 4th Street, Suite 6, Davis, CA 95616
If you have not been living under a rock (in security terms), you will likely have heard something about the GDI+ vulnerability in the past few days. JPEGs and other files that may be handled in the same way are now potentially "dangerous" data files. In 1994 a graphics file was spread via Usenet that contained oddities in the header, and at about the same time a virus warning hoax was created that warned of a viral JPEG file. Neither of these was, in fact, related to actual malicious software, but I did some study on the subject and found header structures in both formats that could, potentially, have been used as malware vectors, under certain conditions. The specifics of the current JPEG/GDI+ vulnerability are very difficult to obtain, even when you have copies of the various "exploits" that have been released. However, it does seem to be simply your common or garden buffer overflow. As I write I am not aware of any specific exploits that have been released with the intent to use them maliciously. However, given the number of "exploit" samples that have been released I dare say that it will not be long before we see the real ones come out. It is unlikely that viruses will be created using this vulnerability, but it is quite probable that viruses will be created that carry graphics files (likely pornographic) that will use the vulnerability to open links to malware on Web sites, or simply open backdoors on machines for exploitation and amalgamation into botnets of various types. Microsoft security bulletin MS04-028 (http://www.microsoft.com/technet/security/bulletin/ms04-028.mspx) has some links that, if you manage to follow them all the way through, will lead you to a patch. Affected systems use certain versions of the gdiplus.dll file. The most widespread of the affected versions of the file come with Microsoft Windows and Office, 2003 and XP versions. Other Microsoft, and other, products also have vulnerable versions of the file. The file is fairly ubiquitous. I've got eleven copies (and two compressed copies) of five different versions of gdiplus.dll on my machine. The Microsoft site does provide details of which version numbers are vulnerable or not--but no information about file sizes or dates that might allow you to determine which versions are which. If you follow links through from that page there is also a "detection" tool--but it only tells you that you *are* vulnerable, rather than identifying specific instances. SANS also has provided a scanning tool, at http://isc.sans.org/gdiscan.php. (Actually two, a GUI version and a command line version. The GUI version, as provided, seems to want a disk in drive F:, but if you tell it to continue seems to function.) This tool identifies which versions are vulnerable and which are not, and also scans other filenames which are, in fact, renamed copies of the gdiplus.dll file, such as: C:\I386\ASMS\1000\MSFT\WINDOWS\GDIPLUS\GDIPLUS.DLL Version: 5.1.3097.0 <-- Vulnerable version C:\Program Files\ArcSoft\Software Suite\PhotoImpression 5\Share\gdiplus.dll Version: 5.1.3097.0 <-- Vulnerable version C:\Program Files\Common Files\Microsoft Shared\OFFICE11\MSO.DLL Version: 11.0.6360.0 C:\Program Files\Common Files\Microsoft Shared\VGX\vgx.dll Version: 6.0.2800.1106 <-- Possibly vulnerable (Win2K SP2 and SP3 w/IE6 SP1 only) C:\Program Files\Microsoft Office\OFFICE11\GDIPLUS.DLL Version: 6.0.3264.0 Banning JPEGs is unlikely to be effective as a security measure. Untrained users will probably not know how to turn off the relevant functions, or be willing to so "cripple" their Web browsing. In any case, graphics files of various types can be renamed, and Windows will still identify them from internal structures, and run them through GDI+. Microsoft has provided some new patches (patches for Office and Windows apparently have to be installed separately), and others will possibly do so as well. It may be difficult to find the appropriate patches for all applications. One would assume that all versions of gdiplus.dll could simply be replaced by the latest (safe) version, but, knowing the industry, one would probably be wrong. email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade [Later update, Tue, 28 Sep 2004:] a) I've seen at least one actual use of the exploit in what appears to be a malicious situation. b) There are serious questions about whether the Microsoft updates (for both Windows and Office) actually work.
"Phone a call centre and you are likely to spend ages on hold listening to canned music - and then find the operator cannot find the information you need. But an artificial intelligence system that hunts down the required information is aiming to slash the time people waste this way. "Using a mixture of speech recognition and search engine technology, the system, being developed by IBM, will trawl a call centre's databanks for the information a customer wants and present it to the operator before the caller has finished explaining what they want. By giving operators rapid access to the right information, calls will be dealt with faster. "The system works by listening in to the conversation and identifying keywords spoken by the customer.... http://www.newscientist.com/news/print.jsp?id=ns99996430 Risks: aside from the commercial aspects, how long before these programs start looking for any "disturbing" phrases in more and more communications, and then immediately redflagging the call and forwarding the info to Law Enforcement Agency of Your Choice?
Source: Burt Helm, *Business Week*, 23 Sep 2004 It's called Worklenz, and it can be a powerful management tool for tracking projects and people -- or a scary Big Brother Look busy -- Worklenz is watching. Designed by privately held information-technology company Métier in Washington, D.C., Worklenz is software designed to help companies manage large projects and maximize efficiency. But unlike an enterprise resource program, which tracks a company's inventory, invoices, and assets, Worklenz tracks workers -- what they do, when they do it, and how long it takes. And it's spreading fast. Métier says it has been profitable for just over two years and has won contracts with Lockheed Martin ( LMT ), BMW, Northrop Grumman ( NOC ), and the U.S. Agriculture Dept. In the next week, BusinessWeek Online has learned, Métier will announce a contract with the FBI to manage all of the bureau's IT-related projects. In its essence, Worklenz uses an extreme form of micromanagement to help a company make broad decisions. The program can sync with each employee's Microsoft Outlook e-mail account, Microsoft Project scheduling software, and his or her PeopleSoft timesheet, to let a boss see everyone's schedules, what tasks they're working on, and how soon each employee will complete his or her work. ... http://www.businessweek.com/technology/content/sep2004/tc20040923_0520_tc024.htm
Background: a Spanish bank issues its customers with a passbook instead ofan ATM card on certain types of account (like UK building societies used to do). Its ATMs have a wide slot so that the passbook, open at a certain page, can be inserted. The book is about the size of a passport and contains a history of transactions on the account. From a hotel window overlooking such an ATM, I recently watched a woman trying to use the service for the first time. She opened the book and inserted it correctly, and the machine pulled it completely inside. However, the screen stayed in what pinball machine designers would call "attract mode": it continued idly to display rolling adverts as if nothing had happened. Thirty seconds passed before a bank employee noticed her waving through the window and beckoned her inside. A few seconds later, the machine spat out the book saying it couldn't be read. It sat hanging out of the slot for a full minute before the woman came out and retrieved it. The risk is obvious, and I've also noticed in the last year or so that newer ATMs in the UK also exhibit this behaviour, leaving the customer wondering whether it even noticed that their card has been inserted. It's so easily mitigated ("Please Wait") that I find it hard to understand how these things ever passed their testing phase.
Here in Taiwan there are tons of free ISPs. One just dials up with the username and passwd from their ads. But how long before one of them starts snooping the data they pass for fun and profit?
Citibank has an e-mail account to send fraud/Phishing messages to, presumably so that their security people can track down the perpetrators. I received an obvious (both to me and to my Spam catching software -- it was in my "probable spam" file) phishing message so I dutifully forwarded it to their address: firstname.lastname@example.org. Later on I get a delivery failure: Error transferring to mail4.citigroup.com; SMTP Protocol Returned a Permanent Error 554 5.7.1 Virus present: Phish-BankFraud.eml I suppose it is a good thing that Citibank has something that detects fraudulent e-mails, but wouldn't it be better if they didn't use it on messages coming into their fraud account?
The risk here seems not to be the possibility that compiled programs can be decompiled (I've heard of decompilers for various languages and system architectures), but that there are people who wrongly think that a compiler somehow conceals the algorithms used in a program. Since a compiler's job is to translate a source specification of an algorithm into a machine-executable form, the compiler's job is to exactly preserve the programmer's "work and intellectual property" in that sense. The machine-executable form might be less human-readable, but it is still susceptible to analysis and reverse-engineering. Compiled machine code is often easy to decompile, even by hand, because compilers tend to generate code with more conventional structure than human-written machine code. > This new version would be an exact copy of the original program, but > with a malicious payload. How can such a program be "an exact copy" while having also been modified "with a malicious payload"? If it's been modified, this modification will be easily detectable by comparison with the original. At one time, "binary patching" (direct modification of machine code) was commonly used for fixing bugs in code which could not be conveniently recompiled or reassembled. Apparently the now-ubiquitous use of compiled high-level languages is causing people to forget what compilers actually do, and ignorance of the details of low-level machine code leads to the erroneous idea that a compiled form of a program is somehow "protected" from modification or exposure of its inner workings. [RISKS received a similar note from Russ Perry Jr., and another reminder of the futility of security by obscurity from Dave Minter. Scott Nicol cited two Java decompilers http://kpdus.tripod.com/jad.html http://jode.sourceforge.net/ and observed that .Net code can also be decompiled. He also added "Think how much easier Y2K fixes would have been if 1960's Cobol programs compiled into a form that was decompilable." See a somewhat related article that has just appeared: Huaiqing Wang and Shuozhong Wang, Cyber Warfare: Steganography vs Steganalysis, *Communications of the ACM*, 47, 10, October 2004, 76--82. PGN]
Please report problems with the web pages to the maintainer