RISKS-LIST: Risks-Forum Digest Tuesday 1 April 2003 Volume 22 : Issue 66 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 http://catless.ncl.ac.uk/Risks/22.66.html and by anonymous ftp at ftp.sri.com, cd risks . Contents: The Security Flag in the IPv4 Header (Steve Bellovin) The Angelic Bit vs the Evil Bit (Drew Dean) Alternative electronic recycling (PGN) 'Reverse production' system recycles all (NewsScan) Use a Firewall, Go to Jail (Ed Felten via Monty Solomon) Re: Use a Firewall, Go to Jail (Steven M. Bellovin) State Super-DMCA too true (William Allen Simpson) Voting machine article in *The Washington Post* by Dan Keating (James Paul) Internet vs. the recording industry (NewsScan) To unlock safe... please endanger your financial future (Jack Burke) Re: Friendly fire (Hugo Tyson) Aircraft software maintenance (Martyn Thomas) Risks in reading RISKS links (Doug Sibley) Re: Beware the spelling checker (Bodo Moeller) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: 1 April 2003 From: Peter Neumann <Neumannat_private> Subject: The Security Flag in the IPv4 Header Steve Bellovin's RFC 3514 (released today) assigns a meaning to the IPv4 packet header's last currently unused bit, which can be thought of as a Security Flag. Benign packets have this bit set to 0; those that are used for an attack will have the bit set to 1. Correct functioning of security mechanisms depends critically on the bit being set properly. If faulty components do not set the bit to 1 when appropriate, firewalls will not be able to do their jobs properly. Similarly, if the bit is set to 1 when it shouldn't be, a denial of service condition may occur. Following is a summary of the assigned values in the RFC: 0x0 If the bit is set to 0, the packet has no evil intent. Hosts, network elements, etc., SHOULD assume that the packet is harmless, and SHOULD NOT take any defensive measures. (We note that this part of the spec is already implemented by many common desktop operating systems.) 0x1 If the bit is set to 1, the packet has evil intent. Secure systems SHOULD try to defend themselves against such packets. Insecure systems MAY chose to crash, be penetrated, etc. It is well worth your reading the full RFC, which is now available: ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt [See the IETF Web site for the full set of RFCs, for those of you not used to reading them. It is an extraordinary view of the history of the ARPAnet and Internet: http://ftp.rfc-editor.org PGN] ------------------------------ Date: Tue, 1 Apr 2003 10:00:01 +1000 From: Drew Dean <ddeanat_private> Subject: The Angelic Bit vs the Evil Bit Steve Bellovin's proposed RFC 3514 finds a very constructive use for the last unused bit in the IPv4 header. In his proposal, the unused bit is sometimes affectionately referred to as the "evil" bit, although that naming convention reflects a fundamentally *pessimistic* world view. We prefer an *optimistic* world view, and therefore propose that this last bit should be used for the "angelic" bit. Our proposed semantics for the angelic bit are as follows: 0x1 The angelic bit is set. All routers, firewalls, switches, and any other network devices MUST forward this packet to its indicated destination. This packet MUST NOT have any undesirable effect on any network device. Anyone who improperly sets the angelic bit on any packet SHALL be subject to divine retribution. Civil authorities MAY subject the perpetrator to any punishment provided for in applicable law. 0x0 The angelic bit is reset. All routers, firewalls, switches, and other network devices MAY filter this packet according to any policy they deem fit. This packet MAY have undesirable effects if forwarded. The sender of the packet SHALL NOT be subject to divine retribution in case of undesirable effects. Civil authorities MAY subject the perpetrator to punishment provided for in applicable law. NB: The angelic bit may have miraculous properties in face of network links severed by backhoes; however, this SHALL NOT relieve the router of its responsibilities. Yours for a more genteel Internet, Drew Dean ------------------------------ Date: 1 April 2003 From: Peter Neumann <Neumannat_private> Subject: Alternative electronic recycling (Re: Reverse production, R-22.66) Perhaps inspired by the Georgia Tech 'reverse production' recycling scheme for computer hardware [see the FOLLOWING item], computer scientists have discovered a way to recycle previously used computer cycles and previously generated data. The trick is first to compress newly written programs using an approach similar to Kolomogorov Complexity analysis, and then map the results into callable elements of old programs that can directly give the desired results in return. Research is underway that would even enable the used cycles of old programs written in archaic languages such as COBOL and FORTRAN to be recycled in this way. Optimizing compilers are already being developed to make this practical, incorporating formal methods (e.g., theorem proving and model checking) to ensure that only provably correct program elements are allowed. In addition, some artificial intelligence groups reportedly believe that automatic program synthesis techniques could be used to avoid writing the new programs altogether, thus surmounting the existing limitations of bad software engineering while still obtaining highly efficient programs. It is estimated that this approach could substantially reduce the burgeoning need for more cycles and new storage capacity. When applied to Windows operating systems, initial experiments show that this could result in at least a 70% reduction in program size and execution time. Purveyors of electronic voting machines are intrigued by the possibility of reusing the results of previous elections, with suitable parametric transformations. However, several computer vendors are objecting on the grounds that widespread use of this technique could detrimentally result in a "compression depression" trickle-down effect of decreased revenue that could more than completely negate the beneficial hardware demands that result from steadily increasing bloatware and the constant need for upgrades. In addition, programmers' unions are contemplating strikes if this technique becomes widely adopted. The word 'reverse' also brings to mind some research results on programs that can be run backwards (for example, implementing information lossless algorithms that work forwards and backwards, and also environments in which 'undo' operations can be successfully executed). Use of such programs could result in saving a further factor of two. A previously proposed alternative approach of creating a very large number of randomly generated compressed programs and then finding the one that works best for the given application has unfortunately been temporarily abandoned as unworkable, pending further research. That approach had been conceived in response to the somewhat obscure but truly classical 1961 paper, subsequently reprinted as ``The Chaostron: An Important Advance in Learning Machines'', J.B. Cadwallader-Cohen, W.W. Zysiczk, and R.B. Donnelly, *Communications of the ACM*, April 1984, pages 356--357). ------------------------------ Date: Wed, 05 Mar 2003 09:25:28 -0700 From: "NewsScan" <newsscanat_private> Subject: 'Reverse production' system recycles all A study underway at Georgia Tech could offer a model for responsible recycling of electronic waste. Researchers have developed a "reverse production" system that enables every raw material contained in e-waste -- metals such as lead, copper, aluminum and gold, as well as plastics, glass and wire -- to be recovered and reused. Scientists say such "closed loop" manufacturing offers a win-win situation for manufacturers and consumers, and the project is generating buzz abroad, with officials in Taiwan and Belgium expressing interest in the system. Key to the process is chemical engineer Matthew Realff's design for a means to separate metals, as well as different qualities of plastics from crushed, ground-up components. From this work, new industries could be created to recover value not only from e-waste, but also from automobiles and other durable goods, says Realff. (*Science Daily*, 4 Mar 2003; NewsScan Daily, 5 March 2003) http://www.sciencedaily.com/releases/2003/03/030304073140.htm ------------------------------ Date: Fri, 28 Mar 2003 15:36:25 -0500 From: Monty Solomon <montyat_private> Subject: Use a Firewall, Go to Jail http://www.freedom-to-tinker.com/archives/000336.html March 26, 2003 Ed Felten, Use a Firewall, Go to Jail The states of Massachusetts and Texas are preparing to consider bills that apparently are intended to extend the national Digital Millennium Copyright Act. (TX bill; MA bill) The bills are obviously related to each other somehow, since they are textually similar. Here is one example of the far-reaching harmful effects of these bills. Both bills would flatly ban the possession, sale, or use of technologies that "conceal from a communication service provider ... the existence or place of origin or destination of any communication". Your ISP is a communication service provider, so anything that concealed the origin or destination of any communication from your ISP would be illegal -- with no exceptions. If you send or receive your e-mail via an encrypted connection, you're in violation, because the "To" and "From" lines of the e-mails are concealed from your ISP by encryption. (The encryption conceals the destinations of outgoing messages, and the sources of incoming messages.) Worse yet, Network Address Translation (NAT), a technology widely used for enterprise security, operates by translating the "from" and "to" fields of Internet packets, thereby concealing the source or destination of each packet, and hence violating these bills. Most security "firewalls" use NAT, so if you use a firewall, you're in violation. If you have a home DSL router, or if you use the "Internet Connection Sharing" feature of your favorite operating system product, you're in violation because these connection sharing technologies use NAT. Most operating system products (including every version of Windows introduced in the last five years, and virtually all versions of Linux) would also apparently be banned, because they support connection sharing via NAT. And this is just one example of the problems with these bills. Yikes. UPDATE (6:35 PM): It's worse than I thought. Similar bills are on the table in South Carolina, Florida, Georgia, Alaska, Tennessee, and Colorado. UPDATE (March 28, 9:00 AM): Clarified the paragraph above about encrypted e-mail, to eliminate an ambiguity. Posted by Edward W. Felten [Moderator's note: This item is NO JOKE, despite the date of this issue. Check out the thread that is occurring subsequent to Ed Felten's message: http://www.freedom-to-tinker.com/archives/000336.html as well as the next two messages in this issue, from Steve Bellovin and William Allen Simpson. PGN] ------------------------------ Date: Fri, 28 Mar 2003 19:08:42 -0500 From: "Steven M. Bellovin" <smbat_private> Subject: Re: Use a Firewall, Go to Jail After reading the full text of the Texas bill (http://www.capitol.state.tx.us/data/docmodel/78r/billtext/pdf/HB02121I.PDF), I think it may be even worse than Felten portrays it. First, a number of people have claimed that the bill isn't a problem, since it only applies if you intend to harm or defraud an ISP. I don't think that that's the case. Section 2 of the billl, which does contain the phrase "with the intent to harm or defraud a communication service", bars theft of service. (I'm speaking loosely here; read it for yourself.) Section 4 also contains that phrase; it bars possession of devices for defrauding providers. (The language is very broad, and seems to bar possession even a computer or modem if you have evil intent.) The ban on concealing origin or destination is in Section 6. That section does *not* have the "intent to harm" phrase. Given that the bill is amending three consecutive sections of the state penal code (31.12, 31.13, and 31.14), and given that the first two sections have that language but the third doesn't, it's hard for me to conclude that evil intent is required by the proposed statute. But it's worse than that: the bill bars concealment of "existence or place of origin or destination of any communication" from "any lawful authority". In other words, it would appear to outlaw many forms of cryptography or steganography, or anonymous remailers. (As an aside, I would note that the constitutional justification for easy law enforcement access to source and destination address information via the pen register statute is flimsy at best -- see my analysis at http://www.research.att.com/~smb/talks/Wiretaps/index.htm) Even Web proxy servers and the Ethernet connectivity from many hotels would be covered by this bill -- they obscure the origin, too. What's unclear to me is who is behind this. Felten implies it's content providers trying for a state-level DMCA; I think it's broadband ISPs who are afraid of 802.11 hotspots. In fact, if the "intent to cause harm" phrase were added to that section, it would clearly criminalize behavior that some ISPs are trying to ban today via their terms of service. Steve Bellovin, http://www.research.att.com/~smb http://www.wilyhacker.com ------------------------------ Date: Sat, 29 Mar 2003 15:53:32 -0500 From: William Allen Simpson <wsimpsonat_private> Subject: State Super-DMCA too true (from NANOG) [Courtesy of Steve Bellovin. PGN] Declan McCullagh sent out an e-mail this morning, referencing his full report at: http://news.com.com/2100-1028-994667.html I was shocked to see that Michigan has *already* passed such a law! (Also Virginia, Delaware, and Illinois.) I've found the new law(s), and they basically outlaw my living in Michigan starting March 31st (this Monday, two days from now): http://www.michiganlegislature.org/printDocument.asp ?objName=mcl-750-219a-amended&version=txt http://www.michiganlegislature.org/printDocument.asp ?objName=mcl-750-540c-amended&version=txt The Bill analysis basically quotes the MPAA website! http://michiganlegislature.org/documents/2001-2002/ billanalysis/house/htm/2001-HLA-6079-b.htm It outlaws all encryption, and all remailers. It outlaws connecting any device "without the express authority of the telecommunications service provider". No NATs. No wireless. (Some DSL/cable companies try to charge per machine, and record the machine address of the devices connected.) It outlaws configuring your ISDN to be a voice device, and then sending data over the device. (Most folks around here are willing to settle for 56Kbps + 56Kbps -- fixed fee -- instead of 64Kbps + 64Kbps -- per minute.) It outlaws configuring a wire pair purchased as a burglar alarm circuit, and then using it as DSL. It outlaws using Linux/*BSD for reading DVDs and a host of other things. Also, "reprogramming" a device (and software and computer chips are explicitly included) "that is capable of facilitating the interception, transmission, retransmission, decryption, acquisition, or reception of any telecommunications, transmissions, signals, or services" would seem to prohibit mod'ing of M$ Xboxen. Heck, it is possible to read this Act to prohibit changing your operating system from M$ to Linux. This was passed in a lame duck session (December 11, 2002) as part of a big omnibus crime act that covered everything from "adulteration of butter and cream", to "trick or acrobatic flying" to "false weights and measures", mostly increasing fines and/or jail for existing offenses. Michigan is a leader in overcrowding its prisons. There was other lame duck legislation passed, before a new Governor took office, almost all of it bad for civil liberties! William Allen Simpson ------------------------------ Date: Fri, 28 Mar 2003 01:27:21 -0500 (EST) From: james.paulat_private Subject: Voting machine article in *The Washington Post* by Dan Keating As election officials rush to spend billions to update the country's voting machines with electronic systems, computer scientists are mounting a challenge to the new devices, saying they are less reliable and less secure from fraud than the equipment they are replacing. Prompted by the demands of state and federal election reforms, officials in Maryland, Georgia, Florida and Texas installed the high-tech voting systems last fall. Officials in those states, and other proponents of electronic voting, said the computer scientists' concerns are far-fetched. [...] David Dill, the Stanford University professor of computer science who launched the petition drive, said, "What people have learned repeatedly, the hard way, is that the prudent practice -- if you want to escape with your data intact -- is what other people would perceive as paranoia." Other computer scientists, including Rebecca Mercuri of Bryn Mawr College, say that problems are so likely that they are virtually guaranteed to occur -- and already have. [Source: Dan Keating: New Voting Systems Assailed, *The Washington Post*, 27 Mar 2003; PGN-ed] http://www.washingtonpost.com/wp-dyn/articles/A39241-2003Mar27.html See David Dill's petition at http://verify.stanford.edu/evote.html PGN] ------------------------------ Date: Fri, 28 Mar 2003 10:47:35 -0700 From: "NewsScan" <newsscanat_private> Subject: Internet vs. the recording industry Media analyst Eric Garland of Big Champagne has told California lawmakers that the growth of music file-sharing on the Internet is "fundamentally unstoppable," because 61 million Americans and millions more worldwide are already downloading music and only 9% of them think they're doing something wrong. "We see only one trend. More people are downloading more copyrighted material." Garland's advice for the recording industry is to embrace digital distribution rather than institute lawsuits or education campaigns, but such advice is not well-received by industry executives, who are routinely urged by Internet enthusiasts to accommodate to technological realities. Phil Corwin, a lobbyist for Internet music service Kazaa, told the same group of state legislators: "The record business, in the digital revolution, has been a day late and a dollar short." [A dollar may not be the final figure.] The fight goes on. [AP/*San Jose Mercury News*, 28 Mar 2003; NewsScan Daily, 28 March 2003] http://www.siliconvalley.com/mld/siliconvalley/5502291.htm ------------------------------ Date: Fri, 28 Mar 2003 16:41:25 -0500 From: Jack Burke <jfb3at_private> Subject: To unlock safe... please endanger your financial future A local (Atlanta, Georgia) radio station is running a contest (what else is new?) for callers to enter. (I won't mention B98.5's call letters to save them the embarrassment.) It's the same standard formula: when you hear a particular song, be the 42,828,210,193 listener to call in for "your chance to win." The grand prize is $2 million. The "gimmick" in this one is that the money is in a safe. To unlock the safe, a potential vict^H^H^H^Hwinner must give the DJ the 5 one-digit numbers in the combination--but not just _any_ 5 numbers will do. Callers are asked for the last 5 digits of their social security number. (Presumably the station will require verification before actually paying out the "winnings.") Did I mention that this was all done on the air? Can anyone guess how many people I've heard willingly gush out five-ninths of their SS number and first and last name on the air? In 3 seconds or less, how many different things can you think of for which all or part of a social security number is used? - Social security "benefits" - credit applications - credit reports - PINs for telephone access to account information (banks, etc.) Can anyone say: "shortcut to identity theft"? (Not as far-fetched as you might think. The first three digits are based on the state in which you apply for the number in the first place, which stands a reasonable chance of being where you were born. That's an easy topic for a conversation with someone who you "accidentally" meet.) ------------------------------ Date: Fri, 28 Mar 2003 18:31:08 GMT From: Hugo Tyson <hmtat_private> Subject: Re: Friendly fire (was: Patriot software again a concern?) In Risks Digest 22.65 PGN wrote: > [Incidentally, NBC on 24 Mar 2003 had an item on self-inflicted > damage, noting that in the Vietnam War, 24% of U.S. fatalities were > due to friendly fire. I have heard reports that it was even higher > in the first Gulf War. That is truly astounding! PGN] Not sure whether it's a computer risk, but this is a social risk in terms of expectations about such things, due to the high-tech weapons now available to *some* armed forces: when one side has far better offensive weapons and far better defensive weapons than the other, a consequence is that friendly-fire incidents will dominate the casualty list for the better-armed side, simply because the less-well-armed side won't be able to harm the better as much as FF can. The same applies to night-vision gear, intelligence, surveillance and all that. For example: Offensively, if only one side can see clearly at night, only that side will be able to hit things *at all** - even if they're not sure whose things. Defensively, the flip-side: if only an Abrams round can kill an Abrams tank, then 100% of Abrams destroyed will be FF. Not suggesting this is so across all encounters in the current war by any means, but in tank vs. tank, aircraft vs. ground vehicle, and aircraft vs. anti-aircraft/anti-missile I think it has the ring of truth. ------------------------------ Date: Fri, 28 Mar 2003 18:18:24 -0000 From: "Martyn Thomas" <martyn@thomas-associates.co.uk> Subject: Aircraft software maintenance (Re: Ladkin, RISKS-22.65) In a recent posting on an A320 Airbus software fault that contributed to a loss of braking, Peter Ladkin wrote: "BCSU software Release 7 was on board; Release 8 provides a fix for the sensing discrepancy condition involved in this incident; Release 9 was released after in-service experience with Release 8." Does this mean that a fault was introduced in Release 8 that was not found in testing/recertification but that showed up fairly quickly in operational use? If so, does this suggest that the process for introducing maintenance changes needs improvement? I have never understood how changes to safety-related software can be introduced rapidly without the formal specifications and formally defined languages that might allow the maintenance group to be completely confident about the scope of the necessary reverification/revalidation. Can anyone explain? Or is there a process weakness here that will one day contribute to an accident? ------------------------------ Date: Fri, 28 Mar 2003 16:14:26 -0500 (EST) From: Doug Sibley <sibleyat_private> Subject: Risks in reading RISKS links With a referral from RISKS, an article by Dan Farmer, and the MIT name, I expected the link in RISKS 22.65 (http://www.technologyreview.com/articles/farmer0403.asp) to be viewable without any significant risks (sorry for saying the word "risk" so many times). Unfortunately, there were many. It requires registration (so I need to link my e-mail address to the viewing of this article -- privacy invasion but whatever (it gives me the idea for a server where people could create temporary/throwaway receive-only e-mail accounts where messages would only be stored for a few hours for the only purpose of signing up at places like this -- although I can imagine it would violate the DMCA in some way). Getting back to the risks: the form has one starred field for passwords instead of the usual two. I entered a username and then entered a password twice (as is normally required) and clicked submit. So I entered my password as my first name. Since the form required a postal code, etc. I had to re-fill-out the form. Given that they starred the password, one would expect that (a) the password would not be stored, and (b) that it would not be displayed. When you submit though, your password is e-mailed to you. I would expect large institutions like MIT to have figured out passwords by now but my cellular provider also does not. Bell Mobility stores passwords online and there are two account preferences-type views, one has the password starred and the other unstarred (of course the password is kept in all-caps to make password guessing easier). In fact, when I was having problems a Bell Mobility representative e-mailed asking for my password (which I reported but never got back from). American Express limits passwords to 8 character alpha-numeric. How long will it take for companies with reputation and value at stake to properly manage risks? Why is password security so poorly done in practice when it is such a well-studied problem? ------------------------------ Date: Mon, 31 Mar 2003 18:02:37 +0200 (MEST) From: Bodo Moeller <moellerat_private-darmstadt.de> Subject: Re: Beware the spelling checker (Cowan, RISKS-22.65) The interesting aspect about spilling chicken software is that it helps you make sure you keep only those errors that actually distort the meaning. Automatic correction is even more interesting in this respect. True story: a German collection of law texts (from by a private publisher) consistently uses the word "Regenschutz" when it should say "Regelsatz". The latter roughly translates to "standard rate" (this is in regulations concerning public-welfare aid); the former means "rain protection". It was not problem to figure out what the text should have said. The problem was just that you are not supposed to laugh loudly in public libraries. TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt Tel. +49-6151-16-6628, Fax +49-6151-16-6036 [Better known perhaps is the word "Regenschirm" -- an umbrella, or literally, a screen against the rain -- which of course was what was needed for protection during the Reagan administration. Danke! PGN] ------------------------------ 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. .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.66 ************************
This archive was generated by hypermail 2b30 : Tue Apr 01 2003 - 08:54:23 PST