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…
Jon Lech Johansen (also known as DVD Jon), who was accused of illegally developing and distributing the DeCSS program for breaking the digital copy-protection mechanism on DVDs, has been acquitted in a Norwegian court. The rationale for the judge's decision was that the software could be used for legal purposes as well as illegal ones. "If a person's motive is to solely encourage or solicit illegal actions, then it would be illegal to distribute it" — but the court made the judgment that Johansen was not motivated in that way. [*PC World*, 7 Jan 2003, NewsScan Daily, 7 Jan 2003] http://www.pcworld.com/news/article/0,aid,108462,00.asp
The U.S. Supreme Court has rescinded an emergency stay barring defendant Matthew Pavlovich from distributing DeCSS, a software utility that descrambles the digital lock on most DVDs to prevent copying them. Pavlovich is now free to distribute the code, but could be sued again if he decides to do so. "The entertainment companies need to stop pretending that DeCSS is a secret," says Cindy Cohn, legal director for the Electronic Frontier Foundation, which is assisting Pavlovich. "Justice O'Connor correctly saw that there was no need for emergency relief to keep DeCSS a secret. It doesn't pass the giggle test." The rescission is just the latest twist in a case that has been winding its way through the courts since 1999, when the DVD Copy Control Association — a coalition of movie studios and consumer electronics makers — filed a lawsuit against scores of people, alleging violations of California's trade secret laws. [CNet News.com, 3 Jan 2003; NewsScan Daily, 6 Jan 2003] http://news.com.com/2100-1023-979197.html?tag=fd_top
An acquaintance found himself puttering around late New Year's Eve with an
allegedly general-purpose and high-quality date/time library he'd written.
He was using it to count down the seconds until midnight, as programmers are
wont to do. The witching hour, however, provided a rather dramatically
convincing demonstration that the code in question is *not* quite perfect
yet. The countdown showed:
2002-12-31 23:59:56.61
2002-12-31 23:59:57.52
2002-12-31 23:59:58.45
dateexpr: newtime.c:618: normalize:
Assertion `t2.subsec >= 0 && t2.subsec < 1000000' failed.
Aborted (core dumped)
2003-01-01 00:00:00.26
2003-01-01 00:00:01.17
2003-01-01 00:00:02.08
(There's some comfort, I suppose, in the fact that the core dump resulted
from an assertion failure, as opposed to a wholly unexpected bug...)
In an attempt to prevent spammers from using "robots" to sign up for multiple free email accounts, companies using Web-based email systems are using "Captchas" (Completely Automated Public Turing tests to tell Computers and Humans Apart). Roughly translated, a pass phrase is generated as an image, and then noise is added to the image. The user is then required to type the pass phrase in. The idea is that a human will be able to do this, but a "robot" will not. The method is not foolproof - some programs can read the pass phrase (admittedly slowly) and some spammers simply redirect the pass phrase to a human. The problem for legitimate users is that the image may be difficult to read if the user has impaired vision (or worse, is completely blind). Quoting from the article: "If this new way of presenting password information prevents visually impaired people from using a service then we have a serious problem on our hands," said Julie Howell, campaigns officer at the Royal National Institute for the Blind in the UK. She said legislation in the Britain and US demands that companies make Web sites accessible to people with disabilities. "Security and accessibility must co-exist, not conflict," she said. The article notes that work is now taking place on sound-based "Captchas". Sadly, this will only shift the problem to people with hearing difficulties. [Source: BBC News Web site] http://news.bbc.co.uk/1/hi/technology/2635855.stm
A federal appeals court has asked California's Supreme Court to rule on whether Network Solutions Inc., the largest U.S. domain registry, must face a multimillion-dollar damage claim from the rightful owner of the s*x.com domain name. The ruling could lead to a flood of lawsuits against domain registries, particularly NSI, from hundreds of people who claim their domain names were also stolen. The current case stems from a lawsuit filed in 1998 by Gary Kremen who registered the s*x.com name with NSI in 1994. In October 1995, NSI received a letter purportedly from Kremen asking that the name be reregistered to a company headed by Stephen Cohen. NSI complied without attempting to verify the validity of the request, and then refused to undo the transfer when alerted to the fraud. Meanwhile Cohen, who was using the domain name for a lucrative porn business, fled the country before Kremen's lawsuit against him went to trial in 2001. Kremen, who is now using s*x.com for his own porn business, was awarded $65 million in damages from Cohen for fraud (which he'll probably never collect) and is now requesting an additional $30 million from NSI for allowing the fraudulent transfer. [*San Francisco Chronicle*, 4 Jan 2003; NewsScan Daily, 6 Jan 2003] http://shorl.com/bigrifretomebro
My apologies for the error in RISKS-22.47 that seemed to run two unrelated contributions together. The header for Danny Burstein's contribution noted in the CONTENTS of the issue and in the second item by Jerry Leichter was inadvertently omitted. It has been corrected in the official archives, ftp.sri.com at SRI, and risks.org — which indirects to Lindsay Marshall's catless site at Newcastle. PGN
I am a bit curious as to how the GPS SmartTrack unti could get line-of-sight to the GPS satellites while under the metallic hood of the car, which should, unless I am mistaken, block GPS transmissions? Is it possible that the SmartTrack unit used cellular networking instead? It should be possible if you know the locations of all the cellular network base stations. You could determine the strength of each signal and thus triangulate the position. Cell phones do this all the time as it tries to to hand-off to a neighboring cell. [Perhaps an oversimplification in the reporting. PGN]
A few years ago my family moved to a new home and with the new home we were assigned a new phone number. After a few months, we began to get messages on our answering machine of the type: "...why did you call me and hang up" "...who is this" "...please stop calling us" and other more strongly worded versions. Since we were never home at the time these came in, I assumed that some neighbor with a similar cordless phone to ours was "borrowing" our line. This proved to be not the case and I wondered what might be happening until finally a person called to complain and was actually able to talk to me. They called and asked for Mr. Med-Deea, I advised them that there was no-one present with that name. They told me that someone just called from my number so they must be present. I asked them to spell the name...M-E-D-I-A, you know Mr. Med-Deea. Now we were getting somewhere. This was sounding like some fax-spam type company that either intentionally or by mistake programmed their equipment incorrectly. I attempted to pacify the ever-more-irritated lady by offering the above technical explanation. No, she said its my number showing on her box, so it must have been someone at my house that phoned her. Then I told her I would prove it to her. I will phone her myself and so I did. She instantly claimed I was wrong because the same number was showing on her phone. I asked her to look at the name....Oh..it was different. She was happier and I was happier. I tracked down the previous owner of the phone number, and despite being quite wary of me, seemed to know nothing about telcom, fax marketing, or phones in general, so I ruled out that someone had left the number in some peice of hardware and forgot to change it. Ultimately, there was not much I could do, although I did not try I assumed that the phone company would not be particularly helpful in this regard. If the calls were originating Intra-Lata, there might be some accounting records for them, but I doubt that anyone could have been convinced to check it out. Eventually, the calls stopped and we have not had one for over a year now. Either the marketer went bust, or fixed their hardware. There are many RISKS here, the most important one is that people who do not understand the technology will tend to not accept explanations that differ from their own.
While this is certainly unacceptable behavior on the part of the application in question and such behavior-- failing gracelessly at the merest hint of something erroneous-- is common to both $10 kiddie games and $5,500 studio tools (and everything in between), blaming it on the programmers-- on technical arrogance on their part-- is both misguided and counterproductive. The real problem lies in how the average software package, Web site, custom development solution, or embedded system is developed. Typically, the client / product manager / producer / art department / creative crew create a set of story boards / screens / photoshop images / line art on napkins / diagrams that represent the user experience with a hint of what the logic behind it may be required. It is rare that these "blueprints" include anything more than a hint as to what to do when something goes wrong. As such, handling exceptional situations is largely an afterthought. The developers may slap something in, but it isn't on their schedule and it is typically done at the last minute under a serious time crunch. It isn't up to the developer to specify the requirements of a system. As you indicate, their system is not the average and it is extremely unlikely that the average developer will be familiar with what an average system in the target market may be equipped with. The product manager / client / producer / marketing should have determined the minimum requirements and specified that to the developer. Furthermore, the 'blue prints' should have contained information as to how to handle exceptional situations-- how to fail gracefully. Most importantly, both time and budget should have been allocated to develop the error handling features properly and to test the software in conditions where it would fail. In other words: Don't blame the messenger.... and don't blame the soldiers for failing to take a hill when the generals send them into battle with incomplete information.
Conspicuously overlooked in the discussion about Total Information Awareness is the lack of any means for the US government to *obtain* the terabytes or whatever it's supposed to sift through. When I asked the deputy director of TIA about this last year, he acknowledged that they would be relying on publicly available and voluntarily supplied data for TIA — as is typically the case in the construction of prototypes. The story routinely presented in the media is that the government is just doing this to us, and the only hurdles to widespread deployment are purely technical ones. But it seems clear to me that Congress and the courts would have something to say about compelling private businesses to routinely submit their transactional data for government inspection. David Martin, Computer Science, UMass Lowell http://www.cs.uml.edu/~dm
Turing limits, like it or not, play a part in the actual application of software; the field would not exist without these limits, since absent the Halting problem automatic methods would have been used, long ago, to debug software. They apply a fortiori to man/machine systems insofar as the human members follow procedures. >... Does Mr. Nilges seriously believe that Groove, whatever it might do, > comes out of the box configured to search for terrorist activity? ... By announcing the use of Groove, the administration has done the bad guy's work for them. In terms of your example, we have sent them a letter saying "perg is grep." This indicates a fundamental lack of seriousness, and that the real purpose of the TIA program is a pork barrel for Bush's friends in the depressed data base industry. It's as if the British could buy the Enigma in Sweden, rather than capturing it! >Now, no one would propose using grep, or any such simple-minded search, for >this kind of thing today [...] This view is based on a mistake about language, in which the bad guys agree to follow syntactical and semantical rules known to both parties. Of course, hackerz and others generate the rules embedded in the usage as part of the usage and this means that no automated system can keep up. "Hackerz" is the simplest example because in terms of sound, z is a neighbor of s, due to the topology of our sound production equipment. You can tell the automated system what rules to follow but there is of necessity a boundary which moves but does not disappear. This presents you with a Hobson's choice. Either you take the time to figure out the rules completely or you use probabilistic models. The first alternative means your results are generally too late for the SAME reason large scale projects are so often late. The problem with the second alternative is that the probabilistic model is just as rigid as a deterministic and formal model for the SAME reason that, as von Neumann said, a computer cannot generate a truly random number. It is a form of "night vision" which has the probability that the gear will conceal just what you need to know. It gets worse, because you've told the bad guy that you are using Enigma or Groove. All he needs to do is buy, steal or reverse engineer your model! > [...] Cops keep crime scene details secret. But they do not set up a data system to do so because this presents the possibility that the details can be known. Cops are aware, unlike data systems people, that they are in a "dialogue" with "terrorists" in the sense of a probability that any one of their actions may be known as part of its being recorded. Ordinary computer users are told on day one that anything they write in e-mail must be treated as if it would appear in the local newspaper. The TIA seems to ignore this simple rule insofar as it encapsulates intelligence procedures in a form that is easy to copy. Note that its chief Poindexter was unaware in 1987 that his e-mail on the White House PROFS system was not completely erased when he erased his copy, and Congress as a result was able to use his e-mail in their investigation of his felonious conduct in Irangate. Poindexter may now realize that there are limits to file deletion, and since 1987 there have been a number of papers on "levels" of file delete. But more broadly, there is in Poindexter and the Administration a naivete (which is evident in the announcement of the purchase of Groove) about Turing limitations as well as the tendency of large networks to join as the result of one key gateway: a government Internet would become part of the World Wide Web on the day ANY hacker created a simple gateway in a literal sense. [I generally remove most of the interstitiated lines to which such point-by-point responses allude. If you find this item curious, please refer back to the earlier message from Jerrold. PGN]
I think we're seeing a meta-Risk: the risk of evaluating risks without enough understanding of the tools being discussed. In this case, Groove. I've been puzzled by the discussion of Groove in TIA. Groove is simply a piece of collaboration software. It lets you create a shared "workspace" that can contain a threaded discussions, a shared calendar, instant messaging, and shared files. You can also share a plug-in to share other types of documents (for example, I use Groove with the Mindjet "Mind Manager" plug-in, which lets me share mind maps with my colleagues). It may have been chosen for TIA because Groove is a peer-to-peer collaboration tool, a la the Napsters of the world, rather than hosting a shared space on a central server. So there's no obvious place for terrorists to eavesdrop if they wants to sabotage a Groove workspace; the space is distributed among its members' PCs. Groove does no detection or analysis of any sort. It's just a framework for sharing information. Check it out. You can download and use it for free from <http://www.groove.net>. I tried it a few months ago and like it so much I've been using it for a few projects I have going. One side note: if TIA will depend on Groove, then perhaps those of us in fear for our civil liberties needn't fear. Only about 60% of the people I've had download it seem to be able to install it and get it working. (I think it's written in Java, which apparently isn't as portable as one might wish.)
Bush's Year of U.S. Surveillance, Noah Shachtman, wired.com, 2 Jan 2003 It may seem unreasonable, unfair and downright mean-spirited to compare the Bush administration to the minions of Sauron, the granddaddy of evil in The Lord of the Rings trilogy. But here goes. The executive branch's attempts in 2002 to peer into the lives of Americans were more than a little similar to the exploits of Middle Earth's would-be rulers. Take, for example, the Bush team's most notorious proposal of the year: the Total Information Awareness system. TIA is an "ultra-large, all-source information repository" meant to track citizens' every move, from Web surfing to doctor visits, travel plans to university grades, passport applications to ATM withdrawals. For J.R.R. Tolkien fans, the scheme sounds eerily familiar. ... http://www.wired.com/news/privacy/0,1848,57005,00.html
Oleg Kolesnikov/Brian Hatch BKBLVPNS.RVW 20020916 "Building Linux Virtual Private Networks (VPNs)", Oleg Kolesnikov/Brian Hatch, 2002, 1-57870-266-6, U$44.99/C$69.99/UK#34.99 %A Oleg Kolesnikov oleg@buildinglinuxvpns.net ok@cc.gatech.edu %A Brian Hatch bri@buildinglinuxvpns.net brian@onsight.com %C 201 W. 103rd Street, Indianapolis, IN 46290 %D 2002 %G 1-57870-266-6 %I Macmillan Computer Publishing (MCP)/New Riders %O U$44.99/C$69.99/UK#34.99 800-858-7674 317-581-3743 info@mcp.com %O http://www.amazon.com/exec/obidos/ASIN/1578702666/robsladesinterne %P 385 p. %T "Building Linux Virtual Private Networks (VPNs)" Like "Practical UNIX and Internet Security" (cf. BKPRUISC.RVW) this book so thoroughly covers its general field, in this case virtual private networks (VPNs), that it is useful to security people regardless of whether or not they use Linux. There are abundant practical considerations in this work that other volumes ignore. Part one deals with the basics of VPNs. Chapter one is a good, readable, realistic introduction (and we will accept the mention of 40 bit DES in IPSec as a typo: it is listed as such in the errata at the associated Web site, http://www.buildinglinuxvpns.net). The title of chapter two, VPN fundamentals, is oddly both true and not: the items mentioned are not factors of VPNs as such, but aspects and considerations of VPNs that influence network choices, and network configurations that impel VPN architecture. Part two covers implementing standard VPN protocols. Chapter three provides a detailed and clear explanation of PPP (Point-to-Point Protocol) over SSH (Secure Shell). PPP over SSL (Secure Sockets Layer)/TLS (Transport Layer Security), in chapter three, outlines the basics, increased security, and scripts for troubleshooting. Excellent coverage of IPSec in general, plus some implementation details in Linux, is in chapter five. Chapter six explains FreeS/WAN from philosophy to source to configuration. There is good analysis of the design and weaknesses of PPTP (Point-to-Point Tunnelling Protocol) and how to run it on Linux, in chapter seven. Part three examines the implementation of nonstandard VPN protocols. Chapter eight looks at the design, options, and setup of VTun. The lightweight cIPe is covered in chapter nine. Designed for user level rather than kernel operation, as well as more modern and robust cryptography, tinc is explained in chapter ten. I have not found, to date, a book that does a better job of explaining the concepts and operations of virtual private networks. This should become the classic text. copyright Robert M. Slade, 2002 BKBLVPNS.RVW 20020916 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
BKKNYREN.RVW 20020916
"Know Your Enemy", Honeynet Project, 2002, 0-201-74613-1,
U$39.99/C$59.95
%A Honeynet Project
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2002
%G 0-201-74613-1
%I Addison-Wesley Publishing Co.
%O U$39.99/C$59.95 416-447-5101 fax: 416-443-0948
%O http://www.amazon.com/exec/obidos/ASIN/0201746131/robsladesinterne
%P 328 p. + CD-ROM
%T "Know Your Enemy: Revealing the Security Tools, Tactics, and
Motives of the Blackhat Community"
I have frequently said that any book with "hack," or any variant thereof, in
the title is automatically suspect. This work helps prove my point, first,
because the Honeynet Project members have *not* used the term (they refer to
attackers as blackhats), and the text also notes the problems with "exploit"
type books: they list old and known attacks, most of which are protected
against, and say nothing about the attackers and how they work. Chapter one
points out the value of "knowing the enemy" and the beginnings of the
Honeynet Project.
Part one describes the honeynet. Chapter two explains what a honeynet is,
and the difference between one and the traditional honeypots. Details on
how a honeynet works, in terms of architecture, policies, and the risks and
responsibilities of operating one, are presented in chapter three. Building
a honeynet, in chapter four, presents specific details, although a number
have already been given.
Part two concerns the analysis of data collected from the Honeynet. Chapter
five, on data analysis, points out the sources of data for logging, much of
which has already been discussed. There is some more information on what we
can find, but limited explanation of how to interpret it. The discussion of
analyzing a compromised system, in chapter six, is more detailed and does a
better job of explaining the logs, but relies on a blackhat document, which,
while better than most such, still has the holes and gaps that characterize
the genre. Additional details are provided in advanced data analysis, plus
some material on data that is (and some that is not) useful in packets, plus
forensic (data recovery) considerations, in chapter seven. (Interestingly,
the Honeynet Project does not seem to be concerned with wiping a drive in
order to deny information to blackhats.) Chapter eight examines data
recovery tools and some results.
Part three explains what the project has determined about "the enemy" by the
types of attacks that have been launched and detected. Chapter nine is a
general review of the random nature of attacks, the tools seen, motives
theorized, and trends in attacks. The activities and signatures of the
Bymer worm are described in chapter ten. An IRC conversation between a
group of blackhats is provided in chapter eleven. While there is some
interest in the account, the transcript occupies almost 100 pages (and
almost a third of the total length of the book). Chapter twelve suggests
the future activities of the Honeynet Project.
Much of the material in the book is repeated, sometimes in a number of
places. The text would definitely benefit from a tightening up of the
material. In addition, the early examples are not thoroughly explained,
making the reader initially feel that only a firewall audit log specialist
would be able to understand what is being said. However, most of the book
is written clearly and well, and it is definitely worth reading.
copyright Robert M. Slade, 2002 BKKNYREN.RVW 20020916
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