RISKS-LIST: Risks-Forum Digest Tuesday 5 November 2002 Volume 22 : Issue 35 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/22.35.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Online job listing an ID theft scam (Monty Solomon) Want a driver's license? How about an ID card instead? (Mark Richards) The FBI Has Bugged Our Public Libraries (Bill Olds via Forno and Farber) What if they held an election and the pundits had nothing to say? (NewsScan) Vote-by-mail in Oregon (Andrew Morton) Software leaves encryption keys, passwords lying around in memory (Peter Gutmann via Monty Solomon) Risks of non-obvious user interfaces (Harry Erwin) Why Telemarketing Is Evil (Neil McManus via Monty Solomon) Re: BBC News: Fake bank website cons victims (Hal Murray) Re: Windows daylight saving and file time-stamp (Graham Mainwaring) Re: Risks of dual-boot systems (Scott Nicol, Tony Finch, Colin Andrew Percival, Nick Rothwell, David Crooke) Wireless networking and security: CERIAS/Accenture roundtable (Gene Spafford) REVIEW: "Internet Security Dictionary", Vir V. Phoha (Rob Slade) Digital System Design DSD 2003 cfp (Henry Selvaraj) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 5 Nov 2002 01:29:52 -0500 From: Monty Solomon <montyat_private> Subject: Online job listing an ID theft scam 'Background check' used to steal full slate of personal info By Bob Sullivan, MSNBC, 4 Nov 2002 It was just the job lead Jim needed: a marketing manager position with Arthur Gallagher, a leading international insurance broker. And only days after Jim responded to the job posting on Monster.com, a human resources director sent along a promising e-mail. We're interested in you, the note said. The salary is negotiable, the clients big. In fact, the clients are so valuable and sensitive that you'll have to submit to a background check as part of the interview process. Eager for work, Jim complied -- and sent off just about every key to his digital identity, including his age, height, weight, Social Security number, bank account numbers, even his mother's maiden name. IT WAS ALL JUST an elaborate identity theft scam designed to prey on the most vulnerable potential victims - the increasing ranks of the unemployed. ... http://www.msnbc.com/news/830411.asp ------------------------------ Date: Mon, 4 Nov 2002 21:59:35 -0500 From: Mark Richards <mark.richardsat_private> Subject: Want a driver's license? How about an ID card instead? As reported by the Associated Press, 4 Nov 2002, the Massachusetts Registry of Motor Vehicles' new online renewal system issued Massachusetts identification cards instead of renewed driver's licenses to 3,600 drivers requesting renewals between 21 and 23 Oct. The RMV's request to Digimark Corporation (which prints the licenses) apparently erroneously included a field indicating ID cards had been requested. The problem was then caught and corrected. (Each license costs the RMV $1.77.) [PGN-ed] [Not mentioned in the article:] The recent (but now former) head of the RMV, Daniel Grabauskas, is a political appointee who claims to have reformed the agency and improved efficiency. On that basis, he is running for State Treasurer. On the eve of a State-wide election, this revelation of goof does not have the most beneficent timing. http://www.boston.com/dailynews/308/region/Online_license_renewals_fouled:.shtml ------------------------------ Date: Tue, 05 Nov 2002 16:40:41 -0500 From: Richard Forno <rfornoat_private> Subject: The FBI Has Bugged Our Public Libraries (from Dave Farber's IP) [Source: A long and provocative article by Bill Olds, *The Hartford Courant*, 3 Nov 2002, excerpted here; PGN] http://www.ctnow.com/features/lifestyle/hc-privacy1103.artnov03col.story Some reports say the FBI is snooping in the libraries. Is that really happening? Yes. I have uncovered information that persuades me that the Federal Bureau of Investigation has bugged the computers at the Hartford Public Library. And it's probable that other libraries around the state have also been bugged. It's an effort by the FBI to obtain leads that it believes may lead them to terrorists. Many members of the public regularly use computers in libraries to access the Internet for research purposes or to locate information about particular interests. It's also not uncommon for students and others to communicate with friends and relatives through e-mail from there. The FBI system apparently involves the installation of special software on the computers that lets the FBI copy a person's use of the Internet and their e-mail messages. (Don't ask me how I know about this because I can't reveal how I was able to collect the information.) Members of the public who use the library have not been informed that the government is watching their activities. It's not just the computers. Circulation lists that show which books someone borrowed are also accessible to the government. What are the Hartford librarians saying? "I can't disclose that we were presented with anything," said Louise Blalock, Hartford's head librarian. I asked Mary W. Billings, the library's technical services manager, if the FBI had given her a subpoena or a court order for library information. Her response: "I cannot answer that question." [...] [Bill Olds, c/o *The Hartford Courant*, Features Department, 285 Broad St., Hartford, CT 06115 or docbilloat_private] ------------------------------ Date: Tue, 05 Nov 2002 08:14:58 -0700 From: "NewsScan" <newsscanat_private> Subject: What if they held an election and the pundits had nothing to say? Modern elections have become so much more than counting the votes: they've become opportunities for political analysts to show off by projecting the results before the votes are counted, as well as by using demographic data and exit polls to explain to the politically unwashed what it all really means, deep down. But there's one little glitch this time: last-day computer problems with the new system of the Voter News Service, the consortium of news organizations that does the exit polling. CNN's Tom Hannon said of the new system yesterday: "It is brand-new and has never been test-driven. This is the equivalent of a NASA space shot without any test runs. We are going to learn a few things tomorrow night in real time." [Great.] Gerald M. Boyd of the New York Times says: "The use of exit polls has been particularly important in terms of trying to get a sense of national trends or moods, so without it, we would have to do the best we can." [And the rest of us will just have to soldier on bravely.] [*The New York Times*, 5 Nov 2002; NewsScan Daily, 5 November 2002] http://partners.nytimes.com/2002/11/05/politics/campaigns/05VNS.html [A tangible benefit of exit polls arises in the use of today's all-electronic voting systems that have essentially zero accountability that your vote is correctly recorded and counted: if the exit polls differ radically from the officially tabulated reported results, then one might have good reason to suspect fraud that would otherwise be largely undetectable, or perhaps some egregious internal mishaps. PGN] [The *Times* item was also noted by Ian Alderman, who included this quote: "Without all the states, the papers count on the demographic and other details from the national poll to explain the reasons for the election results in their articles the next day. But Mr. Savaglio said Voter News Service could analyze the data for its national poll only after it finished analyzing its data by state. That makes the national poll the most vulnerable to any problems." PGN] ------------------------------ Date: Tue, 05 Nov 2002 12:12:40 -0800 From: andrew morton <drewishat_private> Subject: Vote-by-mail in Oregon (Re: Smith, RISKS-22.34) The ballot originally mentioned was the state of Oregon's. In Oregon, every ballot is essentially an absentee ballot, they're mailed out several weeks before the Nov 5th deadline, voters complete the optically scanned ballots at their leisure and in the privacy of their own home. Voters are allowed plenty of time to make their decisions and ensure that the ballot is marked correctly. The voted ballot can either be dropped off at a collection point or mailed so that (regardless of postmark) it is received by 8:00 pm on election day. More details about the system can be found on the Secretary of State's website. http://www.sos.state.or.us/executive/policy-initiatives/vbm/execvbm.htm ------------------------------ Date: Wed, 30 Oct 2002 22:31:46 -0500 From: Monty Solomon <montyat_private> Subject: Software leaves encryption keys, passwords lying around in memory http://online.securityfocus.com/archive/82/297827 Date: Thu, 31 Oct 2002 05:11:31 +1300 (NZDT) From: pgut001at_private (Peter Gutmann) Subject: Software leaves encryption keys, passwords lying around in memory The following problem was first pointed out (in private mail) by Michael Howard from Microsoft. His writeup is now available at http://msdn.microsoft.com/library/en-us/dncode/html/secure10102002.asp. From a representative check of a few widely-used open source crypto programs, this affects quite a bit of software. The problem he points out is that clearing sensitive information such as encryption keys from memory may not work as expected because an optimising compiler removes the memset() if it decides it's redundant. Consider for example the following: int encrypt( const void *key ) { puts( key ); /* Normally we'd encrypt here */ } void main( void ) /* Because we can */ { char key[ 16 ]; strcpy( key, "secretkey" ); encrypt( key ); memset( key, 0, 16 ); } When compiled with any level of optimisation using gcc, the key clearing call goes away because of dead code elimination (see the MSDN article for more details on this, which uses VC++ to get the same effect). While you can kludge enough stuff around a custom memory-clear call to fool the optimiser (hacks with 'volatile', touching the memory after it's cleared and hoping the optimiser is fooled, etc etc) there's no guarantee that it'll work for anything but the compiler(s) you happen to test it with - any future enhancement to the optimiser may turn it back into a nop. What it really needs is the addition of a #pragma dont_remove_this_code_you_bastard in the compiler. Until then, a lot of security code will be affected by this problem. [In RISKS, I tend never to alter British spellings. However, in American English, an "optimiser" must be the ultimate miser.] ------------------------------ Date: Tue, 5 Nov 2002 16:02:05 +0000 From: Harry Erwin <herwinat_private> Subject: Risks of non-obvious user interfaces I'm using a product called WebCT to web-enable a couple of classes that I'm teaching in the UK. I find I have students listed by WebCT as not having submitted a project, but when I download the project files, why there they are! Apparently the students have to take some positive action other than simply submitting the project for the software to believe they submitted it. There doesn't appear to be any mechanism, either, for logging marks for students who did this or submitted the project via some other mechanism. I used to teach at George Mason University (VA), where we used a similar package developed at the University of Maryland. The difference was that the UMD developers actually seemed to have thought through this stuff. ------------------------------ Date: Wed, 30 Oct 2002 01:23:49 -0500 From: Monty Solomon <montyat_private> Subject: Are you bothered by telemarketing? Why Telemarketing Is Evil Neil McManus, CHEAT SHEET, wired.com, Issue 10.11 - Nov 2002 Telemarketers may be relentless, exasperating, even unethical. But you have to give them this: They're good. With the help of technology - everything from autodialing software to cheap overseas labor connected by fiber optics - they've turned phone solicitation into a $270 billion industry. The key to the telephonic onslaught is predictive dialing, a breakthrough of the mid-'90s. These systems churn through huge databases of phone numbers, weeding out busy signals and out-of-service numbers, and routing answered calls to agents. They are mercilessly efficient: Out of an 8-hour day, agents can work the phones a staggering 7.2 hours. One loan company calling deadbeat borrowers boosted "promises to pay" by 129 percent. [...] [Nice article. Read it in its entirety. PGN] http://www.wired.com/wired/archive/10.11/start.html?pg=9 ------------------------------ Date: Tue, 05 Nov 2002 02:44:33 -0800 From: Hal Murray Subject: Re: BBC News: Fake bank website cons victims (Leeson, RISKS-22.34) The PayPal scam mentioned in RISKS 22.34 was relatively recent. The technology was developed several years ago on AOL. It was common enough that it inspired the coining of a new term - phishing (for passwords and/or credit card numbers). The part I know about was mostly used by spammers. With a password, they could use the victims AOL account to send spam. With a credit card, they could sign up for more throw-away dial-up accounts to use for spamming. Feed aolbilling to google-groups for more than you want to know: aolbilling.com is currently registered to somebody in Korea. Here is a URL from May, 2000 describing the second wave - Yahoo, Hotmail... http://news.com.com/2100-1023-240295.html?legacy=cnet&tag=st.ne.ron.lthd.ni ------------------------------ Date: Tue, 5 Nov 2002 15:22:27 -0500 (EST) From: Graham Mainwaring <grahamat_private> Subject: Re: Windows daylight saving and file time-stamp (Jakeman, R-22.34) In RISKS-22.34, Chris Jakeman reports that Windows "changes the time stamp on all of its files" when the local time is adjusted due to Daylight Savings Time. Windows does in fact get it wrong, but not in the way that Mr. Jakeman describes. Windows, like Unix, stores time stamps as GMT/UTC time. All file system transactions are performed using this internal representation. When times are displayed to the user, they are reported in the currently applicable local time, as adjusted. When the time change occurs, there are no retroactive changes made to the contents of the filesystem. The nature of the error is this: On most Unix variants, when a GMT time value is formatted for display to the user, the locale or timezone files are consulted to determine whether DST was in effect at the time in question. So a file that was created at 5:00pm (US) EST on March 1st, 2002 will always be reported as 5:00pm. Windows, on the other hand, appears to calculate whether DST is applicable *right now* and apply this offset to all dates indiscriminately. So a file created at 5:00pm EST on March 1st, 2002 will say "5:00pm" until the time change occurs on April 7. After that, the one-hour offset is applied, so this file is now reported to have been created at 6:00pm EDT. Which is sort of technically correct: If you interpret "EDT" to be a permanent timezone that is offset by one hour, and the time change as a movement of a region between EST and EDT, then reporting the time as "6:00pm EDT" is not actually wrong. It is, however, very misleading. The lesson to be learned is that if you are doing any sort of date comparison, date processing, etc., you really want to compare GMT to GMT times, not local to local times. If you do all internal processing in GMT then you don't have to know or care what time zone all your users are located in. If Mr. Jakeman's replication software had made its comparisons this way, it would have behaved correctly. Also note that this specific problem's first mention in RISKS (as far as I can determine) was in RISKS-6.55 (April 1988) as "Yet Another UnTimely Risk." The tone of the article was woeful that software engineers had continued to fail to implement correct solutions to this well-known problem - and that was more than fourteen years ago. There is also an interesting reference in RISKS-6.70 to what I assume was the forerunner of the Gnu libc6 locale system. ------------------------------ Date: Mon, 4 Nov 2002 21:53:49 -0500 From: "Scott Nicol" <snicolat_private> Subject: Re: Risks of dual-boot systems (Schreiber, RISKS-22.34) This is a well-known problem, and it seems to crop up in risks twice a year. Windows 98 stores the local time, Windows 2000 stores GMT and calculates the offset to the current time. Windows 98 is the real culprit here. Windows NT/2000/XP do the right thing, as does unix. I have no idea what older MacOS versions do, but I assume OS X does the right thing, too. Hopefully in a few more years, Windows 98 (also 95 and me) will be dead and buried. [In a response to Graham Mainwaring's item above, Scott also noted that "Up until about 5 years ago, RCS and CVS got this wrong." John Trammell said he would not blame this on dual-boot systems. "Perhaps a better description of the problem is 'not playing well with others,' or more simply, not following the Golden Rule. PGN] ------------------------------ Date: Tue, 05 Nov 2002 03:24:36 +0000 From: Tony Finch <dotat_private> Subject: Re: Risks of dual-boot systems (Schreiber, RISKS-22.34) It's good to see that the old jokes are still the best. RISKS items on this specific summer time problem include (numbers are volume.issue.subject.item from the catless/risks.org archive): 18.3.2.1 18.96.3.1 19.6.9.1 19.11.6.1 19.12.14.1 19.64.7.1 Hilarious. There are at least ten times as many other RISKS articles on other summer time problems, if you're after more laughs. I think I'd bust a gut if I listed them all here! My favourite variation on this theme is the Windows 95 bug that would set the clock back when summer time ended, then again an hour later (because that's when summer time ends), and again an hour later... Who needs to reboot into another OS? What a pity that planned obsolescence deprives us of such entertainment! Tony. f.a.n.finch <dotat_private> http://dotat.at/ ------------------------------ Date: Tue, 5 Nov 2002 05:43:08 -0800 (PST) From: Colin Andrew Percival <cpercivaat_private> Subject: Re: Risks of dual-boot systems (Schreiber, RISKS-22.34) The problem of adjusting for DST twice is not restricted to dual-boot systems. Last year, my computer (running windows 2000) adjusted itself automatically from 2AM to 1AM; I rebooted it at roughly 1:30AM; and half an hour later it adjusted itself back to 1AM again. One imagines that if a "Reboot" task was scheduled for 1:30AM, the machine might cycle indefinitely. While this particular bug has hopefully been fixed by now, the multitude of DST-related problems suggests that using UTC (or, even better, TAI) internally and treating DST (and leap seconds) as time zones -- restricted to user interface purposes only -- would be a much better solution. ------------------------------ Date: 5 Nov 2002 13:50:47 -0000 From: Nick Rothwell <nickat_private> Subject: Re: Risks of dual-boot systems This is an old problem - we first encountered it about five years ago when we started building dual-boot Linux/Windows boxes. The only sensible approach to daylight-savings on such systems is to keep the hardware clock on UTC and let the operating systems maintain their own local offsets. Windows systems have, as far as I know, never had this option (perhaps to discourage users from dual-booting into a competing operating system?). I allow Linux to do the Right Thing (hardware UTC, software adjustment) and when I need to boot into Windows during the summer I just disable the taskbar clock and use my wristwatch. nick rothwell -- composition, systems, performance -- http://www.cassiel.com ------------------------------ Date: Mon, 04 Nov 2002 19:34:41 -0600 From: David Crooke <daveat_private> Subject: Re: Risks of dual-boot systems (Schreiber, RISKS-22.34) I'd be interested to know the justification for using a dual-boot PC for a mission critical *anything*. Personally I wouldn't use Windows at all, far less a system that isn't even active some of the time, subject to the whims of a user. It's yet another example of legacy functionality (MS-DOS requires the hardware clock to be in current local time as it has no timezone support, so DOS-based Windows has a workaround, ...) propagating for years and years into unrelated and inappropriate environments (Win 3.x -> Win 9x -> NT -> NT5). ------------------------------ Date: Mon, 4 Nov 2002 09:48:11 -0500 From: Gene Spafford <spafat_private> Subject: Wireless networking and security: CERIAS/Accenture roundtable In May 2002, CERIAS and Accenture convened a roundtable of experts on wireless networking and security. The group met for 2 days to discuss the security challenges associated with wireless networking. The results of that roundtable discussion are now available online. http://www.cerias.purdue.edu/securitytrends/ for the full report, executive summary, and "best practices" document. ------------------------------ Date: Tue, 5 Nov 2002 08:00:52 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Internet Security Dictionary", Vir V. Phoha BKINSCDC.RVW 20020824 "Internet Security Dictionary", Vir V. Phoha, 2002, 0-387-95261-6, U$39.95 %A Vir V. Phoha %C 175 Fifth Ave., New York, NY 10010 %D 2002 %G 0-387-95261-6 %I Springer-Verlag %O U$39.95 212-460-1500 800-777-4643 mspano@springer-ny.com %P 259 p. + CD-ROM %T "Internet Security Dictionary" There are a few decent computer dictionaries extant, and at least a half dozen really good communications dictionaries among the many that have been published. However, until this, there was no security dictionary available in printed form, and there has been a need for one. (In fact, I've been working on one for a while, so, boring as it may be, I have to declare yet another possible conflict of interest.) There are 1,400 terms defined, but a number are simply minor variations on a theme. (There are, for example, twelve phrases beginning with "access.") Much of the material is based the old US military terminology from the (now, generally) superseded "Rainbow series" (which is listed), and so there are a number of traditional but obsolete expressions. Some new and slang terms have been included, but some of these are only very vaguely related to the security topic. (The phrase "ankle-biter" is defined as a synonym for "script kiddie," but this term is generally used for a young, or inexperienced, neophyte in any technical field, and doesn't have a specific meaning in security.) Definitions tend to be terse, and may lack necessary detail. (The definition of "Chernobyl packet" seems to fit a smurf attack [also listed], but, due to the lack of information, it is impossible to tell.) An attempt has been made to make sure the material is up to date: Carnivore is listed (but not wardialling or wadriving). (The definitions for virus and worm are, as usual, unfortunate.) Overall, despite the problems, this is a useful reference. Primarily, of course, this is because it is the first of its type. However, it does cover a reasonable range of the security field, and is, for the most part, reliable within limits. However, I would hope that the content is updated, expanded, and improved relatively soon, and regularly thereafter. copyright Robert M. Slade, 2002 BKINSCDC.RVW 20020824 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Fri, 01 Nov 2002 11:35:59 -0800 From: Henry Selvaraj <selvarajat_private> Subject: Digital System Design DSD 2003 cfp DSD 2003: EUROMICRO SYMPOSIUM ON DIGITAL SYSTEM DESIGN Architectures, Methods and Tools Antalya, Turkey, September 3-5, 2003 Submission date for papers: 3 Mar 2003 http://www.egr.unlv.edu/~selvaraj/dsd03 The Symposium on Digital System Design addresses architectures and implementations of (embedded) digital systems, as well as efficient design methods and tools. It is a premier discussion forum for researchers and engineers working on state-of-the-art investigations, development, and applications of digital systems, processor and memory architectures, application specific processors, systems-on-a-chip, hardware/software co-design, circuit design, system validation, and design automation. The main areas of interest are Processor and memory architectures; Special architectures; Specification and modeling; Validation; Synthesis; Systems-on-a-chip; Applications of (embedded) digital systems [PGN-ed] ------------------------------ Date: 29 Mar 2002 (LAST-MODIFIED) From: RISKS-requestat_private Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to <risks-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 21" for volume 21] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall 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/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> 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 ------------------------------ End of RISKS-FORUM Digest 22.35 ************************
This archive was generated by hypermail 2b30 : Tue Nov 05 2002 - 16:02:58 PST