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…
>From an article about security of various control systems (dams, trains, etc.). My favorite quote from this article: "Most of these devices are now being connected to the Internet. But because the digital controls were not designed with public access in mind, they typically lack even rudimentary security, with fewer safeguards that accompany the purchase of flowers online." (this and other good stuff at: http://www.siliconvalley.com/mld/siliconvalley/3554402.htm)
(*The Vancouver Sun*, 27 Jun 2002) Four anglers were rescued by helicopter Wednesday from a small island in the Capilano River after a control malfunction at the Greater Vancouver regional district's Cleveland Dam released an unexpected torrent of water. The malfunction of the drum-gate water-control mechanism, which occurred during a computer upgrade, is expected to prompt the installation of more signs along the river warning fishermen of the potential for rapid increases in water levels. The Cleveland Dam had been releasing snow-melt water through the drum-gate at the rate of about 1,000 cubic feet per second when the malfunction occurred at 7 a.m. Wednesday. By the time dam employees brought the problem under control about an hour later, the flow had increased four-fold to about 4,000 cubic feet per second. At that rate, it would take about 30 seconds to fill an Olympic-sized swimming pool. Thomas Dzubin note: the GVRD does not tightly control physical access to the land around the Capilano river and I've walked by various points along its banks quite a few times. I guess the Risk here might be that you shouldn't automate a system where you can't control access to all directly affected points or at least have an independent feedback system in place to not allow (or send an alarm) a 4x increase in flow over a short period of time. (Although, I'm not a civil engineer...such a feedback mechanism might be tough to implement and still allow the dam to "let-go" water in emergency situations such as the week-long rainstorms which we sometimes have in Vancouver.) Thomas Dzubin, Vancouver, Calgary, or Saskatoon, CANADA
John Gittings in Shanghai, writing for the Guardian Weekly, published an article entitled "China bans toxic American computer junk: Electronic scrap puts the lives of rural villagers at risk" (GW, 2002-06-01, < http://www.guardian.co.uk/international/story/0,3604,725756,00.html >). "Beijing has announced a clampdown on the import of electronic junk from the US and other developed countries which is being stripped by Chinese peasants in primitive and dangerous conditions. The ban follows an outcry by western environmental groups and in the Chinese press about reports that young children are employed to smash up computers and that local water supplies have been poisoned by toxic waste. A new list of banned items will include "TV sets, computers, Xerox machines, video cameras and telephones", according to the national environment agency." The article goes on to describe threats to the health of >100,000 unprotected workers, including children, who extract heavy metals from circuit boards plus severe environmental degradation to farmland surrounding the recycling centers. Most of the waste comes from the US because, "The US is the only industrialised country to have failed to ratify the 1989 UN Basel convention which calls for a total ban on the export of hazardous waste." This article highlights the RISKS of assuming that bringing our defunct computer gear to a recycling center is "protecting the environment." It may be protecting our part of the environment, but on a global basis, we seem to be causing a great deal of harm to many poor people and to the long-term future of our planet. In addition, we ought to look at the morality of treating other human beings as if they are expendable tools for protecting ourselves at their expense. Seems to me that the only sustainable approach to reducing the harm we can cause by discarding computer gear is to include the price of safe recycling in the purchase price and to have manufacturers, wholesalers and retailers contribute to an economically viable treatment process where users live -- not in some shantytown on the far side of the planet. Perhaps signing and abiding by the Basel convention would be a good first step. M. E. Kabay, PhD, CISSP, Dept CompInfoSys, Norwich University, Northfield VT http://www2.norwich.edu/mkabay/index.htm
Four fascinating articles in RISKS-22.13: > Microsoft's secret plan to secure the PC (Monty Solomon) The referenced article included such gems as "Palladium stops viruses and worms. The system won't run unauthorized programs, preventing viruses from trashing your system." Setting aside all the other issues in the article, this by itself is a remarkable piece of misdirection. Why? Well, let's look at viruses... There are four main avenues that viruses and worms use to spread. There are others, but the vast majority of outbreaks have used these avenues of attack. The first, and oldest, is "social engineering". You trick a human into running a program for you. This is the electronic equivalent of calling up the sysop at a company and saying "hey, this is Jack Smith in accounting, I can't get in, I forgot my password because I had it programmed into my mail program, can you clear it for me?". Making the OS more secure can help somewhat, but you don't need to wait for Palladium to do this... most multi-user operating systems are designed so that users normally run with restricted privileges, and so can only damage their own files... not the OS or other user's programs. The second is exploiting a straightforward bug, usually a buffer overflow. To fix this you don't need a new security model, you need a programming language that doesn't allow buffer overflows. The third is a "cross frame attack": you trick the client software (web browser, e-mail program, music player) into running untrusted code without restrictions. This is almost always an attack on Microsoft's poorly-advised merge of the web browser (which is almost always dealing with untrusted objects) with the desktop, mail software, and so on. If they had integrated the HTML rendering engine in the OS and left the Internet access code in a separate program that used the HTML rendering code but otherwise managed its own access controls... at least 90% of the widespread virus outbreaks would never have happened. The fourth is conversion attacks. You encode the message containing the attack code inside a package the outer layers of the OS or application don't know how to open. Ironically, Palladium is likely to make this kind of attack easier, because it's almost certain that part of the security model will involve separating the system up into components that don't have the keys to each other's files. Ironically, one of the latest security issues with a Microsoft product is due to the first Palladium-type software having three of the kind of security holes I just listed above... Windows Media Player. The second of the three holes would not exist if Media Player didn't have to have access to the OS internals to implement Digital Rights Management. Of more concern, the integration of the browser and the desktop and other components that created the possibility of "cross frame attacks" is due specifically to Microsoft's attempt to avoid complying with their original agreement with the Justice Department by bundling the Browser and the OS. Microsoft has maintained this dangerous design despite years of massive virus outbreaks caused by this decision, because otherwise they'd have to admit fault. Even now, when they have been found at fault, and there's nothing left to lose, they refuse to unbundle the Internet access from the rendering code. So, not only has Microsoft never before shown much concern for this problem, they have actively worked to prevent a straightforward fix that they are legally required to implement. Using this issue as a hook to get more control of the computer is, well, there are polite terms for it and I'll let you decide which one to apply. Even if you don't care about this specific issue, what does this say about their likely behaviour if security problems crop up in the design of Palladium? > Risks to your privacy from using MSN Messenger 4.6? (Michael Weiner) > Microsoft sent Nimda worm to developers (Mike Hogsett) The implications of these two, in light of the first, are obvious. > Microsoft's Allchin: API disclosure may endanger U.S. (Brien Webb) This article basically says that Microsoft knows they have fundamental design flaws in their protocols, which if discovered will open up your computer to uncontrolled access. So now they want us to trust them that this time, honest, they'll really get it right?
you from using "other software" on your computer
The latest from MS is buried deep in the EULA if you download the Windows
Media Player security update:
"You agree that in order to protect the integrity of content and software
protected by digital rights management ('Secure Content'), Microsoft may
provide security related updates to the OS Components that will be
automatically downloaded onto your computer. These security related
updates may disable your ability to copy and/or play Secure Content and
use other software on your computer. If we provide such a security update,
we will use reasonable efforts to post notices on a web site explaining
the update."
"may disable your ability to copy and/or play Secure Content and use other
software on your computer" is an interesting phrase. If you remove one
item from the sentence it becomes "may disable your ability to
....................... use other software on your computer".
Wonder what "other software" Bill G. might decide to not let us use at some
point in the future?
See http://www.theregus.com/content/4/25435.html
Bill Tolle <BillTolle@ExclusiveBuyersAgents.com>
>The risk is that the customer-relations programmers are living in a >world of [a-z0-9_] for mailbox names, while the standard has long >allowed for virtually any character (including NULL). Actually, they live in an MS Outlook world (try to send e-mail to "@ @"@nmt.edu using outlook). In fact, Outlook would refuse to send e-mail to a number of perfectly valid addresses, including any that contain the end dot for the root domain. This is obviously a feature, not a bug!
According to Network News (the UK rag) today, MI5, the Home Office, and others don't use PGP signing at RIPE (the European Internet registry), although its the only really secure method for updating records. So anyway, I thought I'd look into it, and, well, its true (edited highlights follow): www.mi5.gov.uk. 6715 IN A 128.98.11.23 inetnum: 128.98.0.0 - 128.98.255.255 mnt-by: QINETIQ-UK-MNT mntner: QINETIQ-UK-MNT auth: MD5-PW $1$tSMW1DGk$GIAERGLu5BwBUXabmYjvs1 I'm sure Qinetiq haven't been so foolish as to choose a guessable password (after all, they've shown their IT expertise by the masterly handling of the 1901 Census website), but even so, their e-mail must contain the password in plain text. Of course, if anyone out there runs their password cracker on that and finds I'm wrong, I'd _love_ to hear about it. Note: all data above is from publicly available sources. Incidentally, the article suggests that some people are still using MAIL-FROM auth, which is, frankly, astonishing. I can't be bothered to track down who, though. Ben http://www.apache-ssl.org/ben.html http://www.thebunker.net/ [PS. OK, I lied: I can be bothered. This is just too amazing: www.gov.uk. 35656 IN CNAME www.ukonline.gov.uk. www.ukonline.gov.uk. 283 IN A 195.33.102.13 inetnum: 195.33.96.0 - 195.33.127.255 mnt-by: AS12967-MNT mntner: AS12967-MNT auth: MAIL-FROM .*@att.nl auth: MAIL-FROM .*@icoe.att.com Yes, folks. The UK government's Website uses MAIL-FROM auth. And not even .uk addresses!]
------ Forwarded Message >Date: Sun, 30 Jun 2002 12:00:36 -0700 >From: "Joseph C. Pistritto" <jcp@jcphome.com> >Subject: Re: IP: The Telecom Crash of 2002 The most telling comment here is the comment about bankruptcy allowing new players to take over bandwidth debt-free, dropping prices. We've seen this pattern before. In Iridium for instance. Further, we see it in the equipment markets, where companies can buy equipment on the secondary market for 20% of list price. This is hurting all the equipment companies as well. (especially Sun, which is very vulnerable to this.) Cisco is probably hurting as well because of it. Its an interesting vicious circle: 1) People install something, (bandwidth, satellites, Sun machines, etc.) and don't have enough revenue to support the cost of it. 2) They go into debt, sometimes spectacularly 3) They go bankrupt servicing the debt, which gets written off. 4) Other people buy the assets debt-free, and can now cut prices 5) Driving all other providers to go into *more* debt. (if they can), or go bankrupt (if they can't). 6) Making more of them go bankrupt. - iterate to step (3). This can't stop until everyone's gone through bankruptcy, to get back on a "level" playing field. As a programmer at heart, I have to believe there's a bug here. Its clear that the worst iterations of this are where the item involved can only be used to provide *one kind* of service. If it's Sun machines, companies could buy them to put in their internal networks, they don't have to only build e-<something> web sites with them. But with Telecom bandwidth, you're stuck. Fiber only moves bits. Voice bits or Data bits, but still bits. Which is why this bug is much worse for the Telecom people than for other kinds of equipment makers, which have multiple non-competitive uses. jcp Dave's archives: http://www.interesting-people.org/archives/interesting-people/
I think that wireless networks and www based networks for hardware control are a thing of the past. I had often thought that this was the stupidest thing I had ever heard of and so despite the personal cost had never bothered to learn the technology. Sadly events are beginning to prove me correct. I expect my retro skills to be in high demand shortly. Remember the days when everything was going to be hooked up to the net? Let us hope those days are gone for good. Wires and hard connections. Still vulnerable but at least you need physical access. No doubt this will raise costs. But you have to balance that against what a plant is worth. I am aware of new aircraft designs that are using IP for moving data in an aircraft rather than a proprietary protocol as was usual in the past. Dumb, dumb, dumb. BTW I worked on the original Raytheon ATC when I got out of the Navy in '67. It is interesting to see how badly Raytheon has bungled the replacement. If only they had gone with advanced hardware capable of future expansion and simply directly replaced the old terminals and systems 1:1. No bells and whistles. Then once they had the simple replacements proved start doing revs. But no - like all fools they got too ambitious. All they could see was how much money and how much more capable the new system was going to be. And in C yet. Where you are at the mercy of the compiler writer rather than the now relatively defunct FORTH system which produces code that is always defined the same way in every instance and is much easier to test. Simpler is better. But try telling that to any young fool who never fought in the clone wars.
Did I mention that FORTH could be the assembly language of a relatively simple processor? The advantage is that you get a language on a par with C that runs directly on the processor. I know of no processor that runs C code directly. You need a relatively complex compiler and lots of hardware tricks to make it run fast. The compiler becomes untestable because of all of the possible combinations and the million transistor chips become untestable for the same reason. The FORTH model is a simple processor (30,000 transistors for 16 bit - 100,00 transistors for 32 bit) with lots of stack and local memory. Memory is very testable. So are simple processors. Because of the simplicity of design the FORTH chip needs only a one level deep pipeline and no branch predictors since a pipeline miss only costs you one cycle at most. Sometimes depending on the code there is no penalty. A few years back they were getting speeds of 500 MIPs from 1 micron design rules and a 32 bit wide bus. Instructions were 5 bits so you got 6 instructions per fetch (best case). With a memory rate of 90 million fetches a second. Go to 64 bits if you need to reduce the external memory rate to a very comfortable 45 million fetches a second. But every one today is in love with complexity. Stupid, stupid, stupid. Except from a marketing standpoint. Yechh. Did I mention that all the new complexity requires a very expensive and hard to test and verify BGA package for all the interconnects vs a less dense PQFP type package that is visually inspectable vs X-ray inspection which degrades the silicon.? Yechh again. But no one listens to me. I'm not bleeding edge enough. Too simple.
San Francisco. Check out http://www.usenix.org/sec02 for our early registration and student discounts. This year's program brings together an exceptional group of speakers to inform and educate including Keynote speaker Whitfield Diffie, co-inventor of public key cryptography and Chief Security Officer at Sun Microsystems. Diffie will talk about security policy and challenges for the 21st century. Other Invited Talks teach you why common security systems fail; how to validate and test security designs; how to make biometrics authentication work; legal aspects of the DMCA; and much more. For detailed information and to register, please visit our Web site at: http://www.usenix.org/sec02 Alex Walker, Production Editor, USENIX Association 2560 Ninth Street, Suite 215, Berkeley, CA 94710 1-510-528-8649 x33
"Decrypted Secrets", F. L. Bauer, 2002, 3-540-42674-4, U$44.95 %A F. L. Bauer %C 175 Fifth Ave., New York, NY 10010 %D 2002 %G 3-540-42674-4 %I Springer-Verlag %O U$44.95 212-460-1500 800-777-4643 rjohnson@springer-ny.com %P 474 p. %T "Decrypted Secrets: Methods and Maxims of Cryptology, 3rd Ed." Cryptology is the study of the technologies of taking plain, readable text, turning it into an incomprehensible mishmash, and then recovering the initial information. There are two sides to this study. Cryptography is the part that lets you garble something, and then recover it if you have the key. Cryptanalysis is usually seen as the "dark side" of the operation, because it is the attempt to get at the original meaning when you *don't* have the key. Most current and popular works on cryptology actually only speak about cryptography. For one thing, nobody wants to get into trouble by telling people how to break encryption. However, it is also much easier to blithely talk about key lengths and algorithms and pretend to know what you are doing than it is to demonstrate a sufficient mastery of mathematics to enable you to go about cracking a particular cipher. Bauer examines both sides, which is an important plus. If you need to decide how strong an encryption algorithm or system is, it is important to know how difficult it might be to break it. Chapter one looks at steganography, the science of hiding in plain sight, or concealing the fact that a message exists at all. In this he first demonstrates a wide ranging historical background which is quite fascinating in its own right. Basic encryption concepts are introduced by the same historical background, but move on to a very dense mathematical discussion of cryptographic characteristics in chapter two. Encryption functions are started in chapter three, and it is delightful to have examples other than Julius Caesar's substitution code. Polygraphic substitutions are in chapter four and the math for advanced substitutions is in chapter five. Chapter six introduces transpositions. Families of alphabets, and rotor encryptors such as ENIGMA, are reviewed in chapter seven. Keys are discussed in chapter eight, ending with a brief look at key management. Chapter nine covers the combination of methods resulting in systems such as DES (Data Encryption Standard). The basics of public key encryption are introduced in chapter ten. The relative security of encryption is introduced in chapter eleven, leading to part two. However, Chapter eleven also ends with a discussion of cryptology and human rights, concentrating mainly, although not exclusively, on the US public policy debates. Part two examines the limits of functions used in cryptography, and thus the points of attack on encryption systems. Chapter twelve calculates complexity, and thus the size of brute force attacks. Known plaintext attacks are the basis of chapters thirteen to fifteen, looking first at general patterns, then at probable words, and finally at frequencies. Frequency leads to a discussion of invariance in chapter sixteen. Chapter seventeen follows with a look at key periodicity. Alignment of alphabets is covered in chapter eighteen. Of course, cryptographic users sometimes make mistakes, and chapter nineteen reviews the different errors and various ways to take advantage of them. Chapter twenty one looks at anagrams as an effective attack on transposition ciphers. The concluding chapter muses on the relative effectiveness of attacks and of cryptanalysis overall. Those seriously interested in cryptology will really *need* to be serious: brush up on your number theory if you want to use this book for anything. This third edition is essentially and structurally unchanged from its predecessors, although it has been updated to reflect the latest algorithms and technologies. Bauer's history and vignettes from the story of codes and the codebreakers are interesting, amusing, and accessible to anyone. copyright Robert M. Slade, 1998, 2002 BKDECSEC.RVW 20020520 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer