Edmund L. Andrews: Controller Sent Jets Into Crash, Flight Data Show *The New York Times*, 9 July 2002 Information from the flight recorders aboard the two planes that crashed into each other one week ago over southern Germany show that a Swiss air traffic controller in effect put the planes on a collision course by ordering the Russian pilot to descend at the same time that the plane's own collision-avoidance system was urging him to climb. The new data, released today by German investigators, show that the two planes' automated systems communicated with each other exactly as they were meant to do and that the accident would probably not have occurred if the Russian pilot had simply ignored the Swiss controller in Zurich. The collision killed 52 Russian schoolchildren and 19 adults. In addition, German investigators said German controllers saw danger nearly two minutes before the crash and desperately tried to warn the controllers in Zurich, who had responsibility for both planes. ... http://www.nytimes.com/2002/07/09/international/europe/09CRAS.html
Since the death of _Byte_, the German magazine _c't_, or _Magazin fuer Computer Technik_, is probably the best technical computer magazine in the world. Some articles from this magazine are translated into English and made available on its WWW site at http://www.heise.de/ . One recent article of interest to comp.risks readers is "Biometric Access Protection Devices and their Programs Put to the Test", from _c't_ 11/2002, dated 22 May 2002, available at http://www.heise.de/ct/english/02/11/114/ . The conclusion is that "the products in the versions made available to us were more of the nature of toys than of serious security measures". One wonders whether the biometric security programs now used by corporations and governments, especially in the US, are any better. Yves Bellefeuille <email@example.com>, Ottawa, Canada Esperanto FAQ: http://www.esperanto.net/veb/faq.html Rec.travel.europe FAQ: http://www.faqs.org/faqs/travel/europe/faq
Arrest of hacker is requested Jornal do Brasil, Sexta-Feira, 12 Jul 2002 (tvv rough translation, thanks babelfish) The police of Mato Grosso do Sul yesterday asked for the re-arrest of the student Guillermo Amorim de Oliveira Alves, age 18 years, accused of the biggest theft yet carried out through the Internet in Brazil. Guillermo was arrested 19 Jun 2002 in the act of diverting R$25,000 from bank accounts using a notebook computer. He was held in custody for 14 days by the Federal Police and was released on 3 Jul on habeas corpus. But analysis of his computer, divulged on 9 Jul, showed that the hacker violated the sites of four national banks and diverted at least R$120,000 from 50 accounts. The analysis is incomplete, but there is evidence that the hacker has a bank account containing R$3 million. His computer also contained 3500 American credit-card numbers from two card issuers. The FBI will enter the case.
A computer security company has uncovered a flaw in PGP (Pretty Good Privacy) — a freely distributed, public key encryption system that's used to scramble e-mail messages — that could allow malicious users to unscramble sensitive messages. The flaw is found only in PGP plug-ins for Microsoft Outlook users distributed by Network Associates. "The PGP vulnerability enables an attacker to send a specially crafted e-mail to any Outlook address enabled with the PGP plug-in, which will in turn give them access to that system," says eEye Digital Security, which discovered the problem. EEye chief hacking officer Marc Maiffret says the flaw allows an attacker to do "anything a user of that machine could do — copy files, delete files, install a backdoor." Gartner research director for Internet security John Pescatore says, "This vulnerability means people using [the affected] version of PGP actually are less secure than if they weren't using security at all. It's always a really, really bad thing when a security product has a bug." (NewsFactor Network, 11 Jul 2002; NewsScan Daily, 12 Jul 2002) http://www.ecommercetimes.com/perl/story/18560.html
The recent Apache "scalper" worm, targeting FreeBSD systems, represents a dangerous precedent, even if it is a rather ineffective worm: it linearly scans randomly selected class Bs, it doesn't employ a very good scanner, and it can only infect a few types of machines (Apache 1.3.20, .22-24 running on FreeBSD). It was roughly 10 days between when Gobbles Security released an exploit for the recent Apache vulnerability (in response to ISS's statement two days earlier, announcing the vulnerability and stating that it was only exploitable on win32 and some 64 bit platforms) that the worm was seen in the wild. This compared with several months for Code Red and Nimda, between vulnerability disclosure and appearance of a worm. We can expect this time to reduce to nearly 0 in the future, as worm authors prepare worms in advance, or borrow existing worm code, and simply drop in exploits as they are published. As we have already seen mail worm toolkits, we can expect similar active scanning worm toolkits. This means that the window of vulnerability between when an exploit or flaw is published, and when it is actively exploited, will quickly reduce to zero. As important, this worm contained a controllable DOS and backdoor module, something directly useful to a blackhat, as did the Goner mail worm. The blackhat community has realized that worms are a great way to compromise machines with little effort and little risk. My personal, somewhat hazy crystal ball: Over the next year, we will see a lot of "1 day" worms, where shortly after an exploit is published, a corresponding worm will be released. These worms will almost invariably carry DDoS, credit card searchers, or similar payloads optimized for blackhat goals. We probably will see toolkits! We will also start to see worms appearing less than 2-3 days after a detailed vulnerability is reported, as slightly more sophisticated blackhats create an exploit, drop it into existing frameworks, and release worms. Be Afraid (tm). Scalper Worm code and first detection was at http://www.dammit.lt/apache-worm/ Nicholas C. Weaver <firstname.lastname@example.org>
I tried to look for a reference to the original NIST report, but could not access www.nist.gov at the time. *Computer Weekly*, 28 June 2002 http://www.cw360.com/article%26rd%3D%26i%3D%26ard%3D113682%26fv%3D1 Software bugs are costing the US economy an estimated 40bn [pounds?] each year, with almost two-thirds of the cost being borne by end-users, and the remainder by developers and vendors, according to a new study for the US government. Software faults could be costing the European Union, whose 15 member states have a combined gross domestic product (GDP) slightly less than the US GDP almost as much again. The US study, by the National Institute of Standards and Technology (NIST), said that testing could reduce the cost of bugs by about a third but would not eliminate all software errors.
Unsolicited Prozac arrived in a hand-addressed manila envelope, from a nearby Walgreens drugstore, with a "Dear Patient" form letter. "Enclosed you will find a free one month trial of Prozac Weekly. Congratulations on being one step to full recovery." This led one recipient to file a class-action lawsuit, stating that Walgreens, a local hospital, three doctors, and Prozac's maker Eli Lilly misused patients' medical records and invaded their privacy. It also accused the drugstore and Lilly of engaging in the unauthorized practice of medicine. [PGN-ed from article by Adam Liptak, *The New York Times*, 6 Jul 2002] http://www.nytimes.com/2002/07/06/national/06PROZ.html
Those who have been following the Palladium thread might be interested in the following article entitled "I told you so" by Robert X. Cringely:- http://www.pbs.org/cringely/pulpit/pulpit20020627.html The following is a long extract from his article: Let's concentrate on the Microsoft story. Last August, I wrote of a rumor that Microsoft wanted to replace TCP/IP with a proprietary protocol — a protocol owned by Microsoft — that it would tout as being more secure. Actually, the new protocol would likely be TCP/IP with some of the reserved fields used as pointers to proprietary extensions, quite similar to Vines IP, if you remember that product from Banyan Systems. I called it TCP/MS in the column. How do you push for the acceptance of such a protocol? First, make the old one unworkable by placing millions of exploitable TCP/IP stacks out on the Net, ready-to-use by any teenage sociopath. When the Net slows or crashes, the blame would not be assigned to Microsoft. Then ship the new protocol with every new copy of Windows, and install it with every Windows Update over the Internet. Zero to 100 million copies could happen in less than a year. This week, Microsoft announced Palladium through an exclusive story in Newsweek written by Steven Levy, who ought to have known better. Palladium is the code name for a Microsoft project to make all Internet communication safer by essentially pasting a digital certificate on every application, message, byte, and machine on the Net, then encrypting the data EVEN INSIDE YOUR COMPUTER PROCESSOR. Palladium compatible hardware (presumably chipsets and motherboards) will come from both AMD and Intel, and the software will, of course, come from Microsoft. That software is what I had dubbed TCP/MS. The point of all this is simple. It may actually make the Internet somewhat safer. But the real purpose of this stuff, I fear, is to take technology owned by nobody (TCP/IP) and replace it with technology owned by Redmond. That's taking the Internet and turning it into MSN. Oh, and we'll all have to buy new computers. This is diabolical. If Microsoft is successful, Palladium will give Bill Gates a piece of every transaction of any type while at the same time marginalizing the work of any competitor who doesn't choose to be Palladium-compliant. So much for Linux and Open Source, but it goes even further than that. So much for Apple and the Macintosh. It's a militarized network architecture only Dick Cheney could love. Ironically, Microsoft says they will reveal Palladium's source code, which is little more than a head feint toward the Open Source movement. Nobody at Microsoft is saying anything about giving the ownership of that source code away or of allowing just anyone to change it. Under Palladium as I understand it, the Internet goes from being ours to being theirs. The very data on your hard drive ceases to be yours because it could self-destruct at any time. We'll end up paying rent to use our own data! Can you tell I think this is a bad idea? What bothers me the most about it is not just that we are being sold a bill of goods by the very outfit responsible for making possible most current Internet security problems. "The world is a fearful place (because we allowed it to be by introducing vulnerable designs followed by clueless security initiatives) so let us fix it for you." Yeah, right. Yet Palladium has a very real chance of succeeding. How long until only code signed by Microsoft will be allowed to run on the platform? It seems that Microsoft is trying to implement a system that will enable them, once and for all, to charge game console-like royalties to software developers.
My thanks to the person who sent me the forwarded message below. (I have withheld his name just in case, although the URL he sent is a totally public source.) Please have a look at both of the URLs below. My informant is right: if the Cringely article scared you, after reading Ross Anderson's contribution, you'll turn green and have to change your pants! PS: It is not made clear in the article, but Ross Anderson is a very highly respected computer security guru at Cambridge University. ---------- Forwarded message ---------- Date: Thu, 11 Jul 2002 19:06:12 +0100 Subject: more palladium stuff Dear Colleagues, As a follow-up of Pete Mellor's mail "Cringely on Palladium ", here's another document, which is WAY more scary than what he sent: http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html I think everybody who is involved in computer stuff should read it... especially programmers and software developers!!! This information should be spread widely and people should know about it!!! Forward this to your friends! For those of you, who haven't received Pete Mellor's mail, here's the link to the document he sent (you may want to READ IT FIRST): http://www.pbs.org/cringely/pulpit/pulpit20020627.html
Excerpt from http://www.macintouch.com/toasttitanium3.html >Date: Wed, 10 Jul 2002s >From: [MacInTouch Reader] >Subject: Roxio Toast 5.1.4. Update EULA language >Like many people who use a computer daily, I prefer to keep my software >up to date. And so I generally utilize updates provided by the various >software manufacturers. > >However, given recent reports of Microsoft's impending Palladium >technology and its ability to invade a computer at will, I've taken to >actually reading the license agreements that one must accept in order to >install software or updates. > >Just a few days ago, I retrieved the v5.1.4 update for Roxio's Toast CD >mastering software. And was stunned to discovered the following verbiage >emplaced within the license agreement's "RESTRICTIONS" section. > >Content providers are using the digital rights management technology ("DRM") >contained in this Software to protect the integrity of their content >("Secure Content") so that their intellectual property, including copyright, >in such content is not misappropriated. Owners of such Secure Content >("Secure Content Owners") may, from time to time, request Roxio or its >suppliers to provide security related updates to the DRM components of the >Software ("Security Updates") that may affect your ability to copy, display >and/or play Secure Content through the Software or other applications that >utilize the Software. You therefore agree that, if you elect to download a >license from the Internet which enables your use of Secure Content, Roxio or >its suppliers may, in conjunction with such license, also download onto your >computer such Security Updates that a Secure Content Owner has requested >that Roxio or its suppliers distribute. Roxio and its suppliers will not >retrieve any personally identifiable information, or any other information, >from your computer by downloading such Security Updates. > >Note that these statements are nestled in the midst of a longer paragraph >containing the usual stuff about not reverse engineering the software, with >copy not directly related to these statements preceding and following these >statements. Almost as if Roxio hoped that this language would not be >noticed. > >I'd suspected something like this might be present within the agreement ever >since a recent session of burning music CD's from my collection of MP3's, >using Toast v5.1.3. The last discs I burned play normally, both on my >computer and in my CD players, but if you put one of them into the >computer's drive and open it as a data disc, you are presented with a list >of untitled files, all zero mb in length. > >I haven't tried to copy one these discs, as I've no reason to do so as yet. >And as I still have my mp3 files, I can make another whenever needed. > >But with this discovery, I find myself hoping for a viable alternative to >Toast. >Note here that I use an older Mac, a Performa 6360, upgraded with a Sonnet >G3/320 L2 card. Apple's DiscBurner software will not load, stating that it >requires a machine with built-in USB capability. I have not been able to >utilize iTunes' burning capability, either, which requires OS 9.2 and 9.2 >updates refuse to install on my machine.
> "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". AV software in case MS accidentally send out another virus, firewalls to allow MSN Messenger et al. free reign? There is a further risk here in the item that Bill removed from that sentence. For example, updated software looking at software version numbers refusing to allow plain text e-mailed content to be 'copied' to the updated recipient machine if the source is software which has not been updated to a version which included this new bit of the EULA. A second risk became evident when this new bit of the EULA was discussed in a newsgroup when all the posters after the original article stated they didn't apply any security patches.
A more interesting concern is the encoding used by MIME. Things like UUencode and BASE64 (and others, I am sure) create extremely large files of random (at least as far as language is concerned) letters. When I search some of my saved mail folders I can find pretty much any 3 or 4 letter combination. I have even mentioned in discussions around the department the concept that as the number of viruses increases and the amount of encoded e-mail increases the number of false positives will also have to increase. When you add "dirty word" filtering to the equation matters become much worse. In a system that automatically discards suspect e-mail, this could mean a lot of important information not getting through. Bill Gunshannon, University of Scranton, Scranton, Pennsylvania <email@example.com>
The United States Post Office is well-known for its confusion about whether it wants to be treated as a business or a government agency. The Louisiana Attorney General's office, however, by using the domain la-ag.com a couple years ago, was clearly stating that it's in business. Not sure what business it's in, or what its prices are :-) The domain is now owned by some agricultural company, which makes more sense, and the LA AG's office is using www.ag.state.la.us/
Similarly, the UK parliament has a perfectly good Web address: http://www.parliament.uk/ but insists on using a .tv suffix for its live video feed: http://www.parliamentlive.tv/ Conor O'Neill, Bristol, UK
[I have excerpted starkly from an extended exchange between George Roussos and Tony Finch, inspired by Colburn. PGN] You should read this in the context of the syntax for domains in RFC 821 and 822 (or rather 2821 and 2822 if you want to be up-to-date), which does not allow a . at the end of the domain. > In practice, I have not come across a mailer that would not recognise > or refuse delivery when the root dot is present, including all versions > of exchange (please check this, it is true). Sendmail and Exim are popular MTAs [that consider the dot invalid]. [Examples omitted. PGN] Other MTAs might not care if you violate the RFCs. f.a.n.finch <firstname.lastname@example.org> http://dotat.at/
Sadly, as a more recent trend that's true. For a while, some folks were on this track, though. Back in the early 80s, Rockwell had a couple of parts (65F11 and 65F12, IIRC) that had a Forth interpreter in mask ROM; New Micros (newmicros.com) still sells a 68HC11 with onboard Forth. And in the late-80s Harris sold a part (licensed from Novix, I think) that was a really speedy little thing optimized for Forth (with heavy emphasis on the stack). More information at: http://www.ultratechnology.com/chips.htm In all, though, you're right. In this business, the elegance of yore tends not to remain in vogue.
BKDIGSIG.RVW 20020520 "Digital Signatures", Mohan Atreya et al., 2002, 0-07-219482-0, U$59.99 %A Mohan Atreya %A Benjamin Hammond %A Stephen Paine %A Paul Starrett %A Stephen Wu %C 300 Water Street, Whitby, Ontario L1N 9B6 %D 2002 %G 0-07-219482-0 %I McGraw-Hill Ryerson/Osborne %O U$59.99 905-430-5000 +1-905-430-5134 fax: 905-430-5020 %P 368 p. %T "Digital Signatures" Although cryptography is generally considered to be useful for hiding information or holding it confidential, cryptographic methods can also be used to determine whether data has been altered. Slightly more specialized means can also be used to provide evidence that a certain individual composed or verified a certain message, in the same way that a handwritten signature is presumed to assert a person's intent or agreement with respect to a contract. Properly used and supported, these digital signatures can be stronger and more flexible than physical signatures as a means of binding an identity to a document. Chapter one is an introduction, both to some basic concepts, and to the book as a whole. (The material is disjointed in places: there is a section entitled "Legislation" on page six and another on page eight, although the content is different.) The overview of cryptography, in chapter two, has some very weak and some very good points: the explanation of the four modes of DES (Data Encryption Standard) is much clearer than in most texts. The description is, however, very generic, and does not address hash or signature topics at all, nor does it address algorithmic and key length strength and weakness. Certificates are a vital part of the common digital signature structure, but chapter three's discussion concentrates on X.509 fields and request procedures, without getting into the underlying concepts. Data integrity is another key (sorry) concept in the creation of digital signatures, but while the material on checksums and hashing starts out well, chapter four ends in something of a confusing mess. Chapter five flits between real and theoretical systems in such a way that no valid assessment of uses and shortcomings is possible. A number of miscellaneous topics are listed in chapter six. Chapter seven looks at various business issues and models, generally with respect to public key infrastructure, but is oddly unhelpful in real world terms. Some standards are listed and tersely described in chapter eight. Definition sections lifted from various pieces of legislation are reproduced in chapter nine. Chapter tens lists a number of legal concepts that may have a bearing on digital signatures: these are more practically related to systems and policies in chapter eleven. The technical and practical aspects of this book fall far short of being useful either to the security professional, or to the manager who may need to address the topic or make decisions about systems. The legal sections, however, might justify, for the professional, the purchase of this otherwise confused work. copyright Robert M. Slade, 2002 BKDIGSIG.RVW 20020520 email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer