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…
ResearchIndex http://citeseer.nj.nec.com/cs is a digital library that harvests documents from web pages (220,000 so far), builds a citation index (over 2.5 million so far) and provides text search. Each document has a page which gets you the original URL, a cached copy of the document, backwards citations, forward citations in context and links to other documents that are related or have substantial matching text. On the one hand this is a fascinating, audacious and extremely useful resource. On the other such digital libraries and research tools (and this research prototype in particular), and the radical new model of accreditation, access, and authentication for scientific information that they can potentially support, raise significant and far reaching security, rights and privacy questions for the scholarly community. For example look again at some features of ResearchIndex : * Anyone, apparently without authentication, can add so-called "Authors" comments and "Title correction" to any document record or suggest new URLs for ResearchIndex to harvest. Digital libraries need robust security and authentication mechanisms if they are to be a trusted part of the scientific process. * A "most cited" list: pause a moment, before awarding "J Smith" tenure on the basis of that spectacular Number 16 position, which is the result of concatenating several different people, to reflect on the problems of name reconciliation and the dangers of relying on unauthenticated data, particularly in matters that may be subject to legal challenge. * It provides a listing of what "Users who viewed this document also viewed": so think twice before using ResearchIndex to investigate that potential patent involving a novel application of YYY to the entirely unrelated ZZZ. Wonder about the "right of a scholar to the privacy of the study", and recall the privacy conventions about access to library borrowing records in your own state or country. Consider what such a service could or should track and analyse, what use might be made of such tracking information and who has rights to it: for example what if analysing usage patterns made a connection that beat someone else to a patent? * It caches copies of the documents, which are then available for download. Question exactly what versions of which documents have been harvested from where, and how accurate the analysis is: ResearchIndex gives one of my papers a bizarre ``Abstract'' consisting of the paragraph following an occurrence of the word ``Abstraction''. Wonder what happens when a document is later removed from the URL it was harvested from, for example for copyright reasons. Then figure out the authentication and rights issues. * Think about what is not there: for example citations of Turing's papers (he is Number 4101 in the most cited list), but not the papers themselves, and reflect on the future of our paper archives and libraries. We expect our on-line documents to be located, read and analysed by people and machines, that is why we put them on-line. Sooner or later there will be a production version of something like ResearchIndex that addresses these problems, but meanwhile we all have a chance to debate what we want, and the authentication, security, rights, privacy, legal and political implications of the "harvesting", mining and distribution of the world's on-line research documents. Starting points for further reading: The Coalition for Network Information has many relevant reports at http://www.cni.org/projects/ Henry Gladney, Safeguarding Digital Library Contents and Users, Interim Retrospect and Prospects, D-Lib Magazine, July/August 1998 http://www.dlib.org/dlib/july98/gladney/07gladney.html Ursula Martin University of St Andrews/SRI
Microsoft Outlook has a feature which allows you to tell the Exchange server to deliver a mail after a certain time. For example, you could use this to send your company's quarterly results to the press at 7am tomorrow and be sure they would not go out until the figures are officially published. However, due to a problem in the definition of time (!), it is possible for the delivery time to be an hour late or an hour early. An hour late is perhaps not so bad - after all, you said "do not deliver before 7am", and it's true, 8am is not before 7am. But an hour early ? Can you say arbitrage ? The problem is that all events in Exchange are scheduled in GMT, but Exchange does not correctly handle the automatic changes in the Windows NT system clock when daylight savings time kicks in. The result is that, after daylight savings time starts or ends, and until you reboot your Exchange server: - deferred mails sent in the fall, when the clocks go back, will be delivered an hour later than you expected. - deferred mails sent in the spring, when the clocks go forward, will be delivered an hour earlier than you expected. The workaround is, of course, to reboot your Exchange server (or completely restart Exchange, which involves more or less the same level of user downtime) when the time changes. But on sites which have a policy to reboot only one major server at a time (there are several good reasons to do this), this could take several days (Exchange servers are notoriously slow to shutdown). Doubtless Microsoft's preferred permanent fix is to lobby governments to abolish daylight savings time. Hmmm... isn't the French government pretty keen on that right now ? Is that what Bill was talking to Chirac about ? Nick Brown, Strasbourg, France. for more information, http://dct.coe.int/info/emfci001.htm
The home exchange organisation to which I belong has decided to put its catalog online. Anyone will be able to view the homes which are offered, but contact address and phone number details will be provided for members only. Today I received the instructions for logging on. Hoo boy - here we go again: - The Username is your country code followed by your membership number within the country. This is published in the paper catalogue. - The Password is "xxxxxxxx" (I have censored it). But - the password is the SAME for EVERY username. You read that correctly. So, the usual list of RISKs: 1) Member US1234 can log on as Member US5678. In theory this is no big deal because currently all you can do is read information which you could have obtained as the other member, although for auditing reasons I'm sure they'd like to know who is really logging on. But we are promised that in future versions, we will be able to update our site entries ourselves... 2) Non-member Z can very easily obtain a member number. And even if the site managers notice that Member US1234's account is being used by 500 PCs a day after someone posted it to DejaNews, and they close that account, it will not require a degree in computer science to work out that US1235 etc are worth a try, since there's none of the usual hassle to guess the password. Needless to say, I have asked the organisation to remove me from the Web site immediately. Nick Brown, Strasbourg, France. for more information, http://dct.coe.int/info/emfci001.htm
This is really just another of the risks we face from not adopting proper standards (i.e., satellite failure caused by US/Metric conversion error) In the case of dates, we have had an international (ISO) standard for many years now, according to this dates should be displayed as 1999-12-10 instead of 12/10/99 or 10/12/99 or even (heaven forbid!) 01/02/03. Here's one page showing some of the problems related to our current mess, and why all countries, not just Japan and Sweden, should switch to ISO 8601. This page also have links to the full standard text. http://www.saqqara.demon.co.uk/datefmt.htm Terje PS. The corporation I work for, Hydro, very sensibly decided some years ago to switch to ISO dates, even though this is different from the Norwegian standard. <Terje.Mathisen@hda.hydro.com> Using self-discipline, see http://www.eiffel.com/discipline
IMO, there many risks that the case against Mr. Smith for Melissa may bring to reality. 1. That a GUID may be accepted in court as a "signature" uniquely identifying a particular human being. At best the GUID is circumstantial, and it is far to easy to show GUIDs belonging to others (mistakenly or intentionally) resident on your machine. 2. That it may be accepted as possible to prove the route which a particular virus has traveled to get to the point where its deemed "in the wild", and presumably therefore actionable, solely on the basis of computer evidence. 2a. What is the crime? Making the virus, or releasing it "in the wild"? Surely making a virus is not a crime, so the test comes down to proving who released it "in the wild". Since that action must be done with intent, computer data alone, demonstrating that a particular file originated from a particular disk, still does not prove intent. If I were to co-opt Peter's machine and use it to send a virus to a Usenet list, should Peter be held liable for the damages of the virus? 2b. How is it proven? Computer data is malleable, and while Word documents may store revision information, and even information from RAM totally unrelated to the original document, it is possible that all of that information can be placed into another file either in addition to, or replacing, the 2nd document's original information. As such, its again circumstantial evidence of origin and even ownership. It is quite easy to villainize virus writers and infectors in the same way "two Arab men" were responsible for the Oklahoma bombing. An entire industry is available for testimony as to the damage suffered by Corporate America every day as a result of the actions of the few virus writers. The NIPC, and therefore the FBI, are desperate to show they have the savvy to catch Cyber-criminals and justify their stance and actions. IOWs, there's a significant weight against Mr. Smith if we allow prosecution testimony to go unchallenged for the vapor-thoughts it may well be. It must be shown that such conclusions, based solely on computer data, can easily be manufactured against anyone. I have thought long and hard about how it may be possible to prove an individual is guilty of a particular computer crime. A confession, today, could be given simply to garner the publicity and reap the benefits after the jail term is served (do you think any conference would not pay to have Mr. Smith talk after he was released, if he could speak intelligibly? ... book deals ... guest spots ...) Criminals used to take the rap and not talk in order to get the loot when they were released ...;-] Without another human being present during each of the steps required to release a virus into the wild with malicious or harmful intent, a conviction on circumstantial computer evidence would lead to many serious problems, IMO. If the above evidence, assuming its present and the basis of the case against Mr. Smith, is accepted in court and the jury finds its credible, it will be far too easy to convict innocent individuals of computer crimes in the future. Smith may well be guilty, and he is not my focus here. We must ensure that his conviction does not establish the wrong precedence's, lest we give the "enemy" the ammunition to get each and every one of us convicted of something, somewhere, based on the same quality of evidence. I remind you that I, like most of you, have not seen the evidence against Mr. Smith and this is based solely on the media reports about its content ... therefore, I may be totally off-base ... but the risk is real no matter. Russ - NTBugtraq Editor
I work for a large health maintenance organization. We share our campus with about a dozen other assorted companies. All of our upper management is absolutely terrified of the end of this year. They are convinced that there is going to be a major disaster at the stroke of midnight. To deal with a potential loss of power, we have installed a generator onsite. A storage tank next to the generator holds 1,500 gallons of fuel. An additional 2,000 gallons of fuel will be parked next to the generator the entire weekend of the new year. The risks? 1) The generator is in a hastily built wooden hut secured with a padlock. The hut is located on the outside wall of our data center. 3,500 gallons of boom. 2) One of the other clients on a campus constantly gets bomb threats. Often the threats are real. Who needs a Rider Truck? 3) Disaster recovery planning has taken a back seat to Y2k planning. We would not survive the loss of our data center. The disaster plans have not been updated to reflect our move from VMS to Unix over the last 5 years. 4) People ignore the large "No Smoking" signs posted on the generator shed. See #1. Who needs terrorists? The Unix team has started parking on the far side of the parking lot in the 'blast shadow' of another building.
"No browser has any business ever loading a URL unless the user requests it!" That sounds non-controversial — but what constitutes a request? o Typing it in the navigation window? Surely. o Clicking on a hyperlink? Probably (else hypertext becomes rather lame) -- but what if the user doesn't recognize it as a link? And how many users routinely screen the reference before clicking the link? Typically there is not enough information available to know just what a link will get you into. o Automatically loading images for embedded <img> tags? Well, there are times you wish it wouldn't, given the image bloat on the net, but the alternative is not very attractive either. o What about loading a URL in response to an onclick event? Or loading a new image in response to a mouseover event? As these are embedded in script or applets or components, it would be hard for the browser to distinguish between "requests" from the program and requests from user interaction. The alternative seems to be restricting user interaction to clicking on anchor tags. This is akin to restricting computer interaction to TTY mode. Sorry, but we've passed that stage. In the current state of the net there is no incontrovertible notion of what constitutes a request. There will always be a natural tension between the convenience (and power) of the user interface and the problems of letting a program decide how to proceed. You can push the extremes too far in either direction. Dick Shelton, Shavlik Technologies dicks@shavlik.com
I use Netscape running on a Win95 platform to read most of my mail from a particular account with a particular ISP. Recently I needed to get a second account from that same ISP (for a civil-rights group I'm working with). I set up another Dial-up Networking connection using Win95, with this new user name and new password. To test it, I connected to the new account. Everything seemed fine. I then clicked on the "Get Mail" icon in Netscape Messenger to get any mail that might be in the new account (typically there is a welcome message from the ISP). Imagine my surprise when what came in was all the mail from my first account! Of course, it turns out that Netscape stored (without my knowledge) the password to my first account internally (as has been noted previously in RISKS - I've just gotten around to reading that digest). Okay, I can understand that (but not agree with it). But why did it use the first user name and password when the Win95 dial-up networking program connected to a completely different account (I called my ISP, and I was indeed connected to the new account)? The risks are obvious. In any event, users should be told that their passwords are being stored by application code and that mail can be retrieved from one account via another without doing anything so esoteric as using telnet. There just no accounting for this. --Steve Greenwald http://www.gate.net/~sjg6
> Unfortunately, the encryption algorithm used by Netscape to scramble > passwords is exceptionally weak. Even if it weren't weak, it would still be equivalent to a plain text password. Netscape has to be able to send the password in the clear over the IMAP/POP3 protocols, so no matter what encryption mechanism is used, Netscape can always be reverse-engineered to retrieve the encryption algorithm and/or keys required to extract the password.
In defence of Netscape, I would like to point out that the only viable alternative to Netscape's "exceptionally weak" encryption is "security through obscurity." Storing passwords locally is inherently insecure. Once again, those UNIX people have solved this one in a particularly elegant way using the ".netrc" file: store unencrypted passwords in a file which may only be readable to the owner. The level of security is immediately obvious to the user; the user can then make an informed decision to live with this security or to type the password whenever needed.
Not to seem silly but: So what? I'm no crypto expert, but it seems obvious to me that if the password is being stored on your machine and requires no other input from you for Netscape to provide the password to the other end, then it's by definition insecure. No matter what crypto algorithm Netscape uses, ALL the secrets are on your machine - the encrypted password AND the code and secrets needed to decode it. Yes, it would take more time to reverse engineer the relevant portions of Netscape code than to simply break the algorithm the way you did, but only one person has to do so - then security is blown just the same. It doesn't matter that Netscape's local password storage isn't secure - ANY local password storage is going to be insecure. No matter how complicated the lock, if you hang the keys (or a technical manual on the lock's operation) on a hook next to the door, it doesn't do you much good. The only thing that encryption of the stored password prevents is accidental revelation during registry browsing. And yes, the only workaround is to not allow Netscape to remember your passwords. But that's what you need to do. In all programs. Always. It should also be noted that if I'm not mistaken, the POP protocol (I don't know about IMAP) transmits the password in clear text. So all someone needs is a sniffer somewhere in between you and your mail server (like your local lan) and the results are the same. It is a good thing to have folks like you point out security holes in well known applications, but I'd have to say that Netscape isn't as terrible as you make out on this one. All they did is decide that protecting the password in the local cache wasn't worth a lot of effort. And I have to agree with that sentiment. On the flip side, Chris Saito's statement about recovery was just silly, as you rightfully point out. One other point: In Risks you mention a Javascript based attack. Are you referring to using one of the known Javascript attacks to capture the user's encrypted password entries, or do you have something new? Michael Kohne <mhkohne@discordia.org>
You are correct Michael, there is NO perfect solution here. However, we believe using a well known crypto algorithm like DES and hiding the key material throughout the code is orders of magnitude better than Netscape's current approach. In other words, you raise the bar significantly by forcing people to reverse engineer for an attack (to find the key) and get much lower risk that way. The current approach is just too risky. Along those lines, Avi Rubin (ATT Research) said it best when he said Netscape needs to run out and get a bar so they can raise it! We agree. Of course the "one attacker is all it takes" comment you made remains completely accurate. With regards to the Javascript attack, we were referring to an old (presumably fixed) Javascript attack which was able to snag the "encrypted" password and lots of other private information from the prefs file. Because of Netscape's "patch through release" approach, the attack still works against Netscape 4.0 through 4.04. Yet another reason to update your browser. Yesterday we were informed that Dave Edis of Interactivetools created a Web-based password cracker (which requires someone to enter the obscured password through a dialog box) at least a year ago. We were not previously aware of his work. Though his code does not work against current versions of Netscape, the algorithm currently used (and cracked by us) is very similar. See: <http://www.thewebmasters.net/mailpass.html> One might wonder whether this implies that Netscape is taking an arms race approach to obscuring the POP3 password. If so, why the heck not use DES?? As for sniffers, I believe you are correct about POP3 and plaintext passwords. Yet another serious risk, but compounding not mitigating the one we raised. Ain't shrinkwrap wonderful? Gary McGraw, Ph.D, Vice President, Reliable Software Technologies, Dulles, VA gem@rstcorp.com <http://www.rstcorp.com/~gem> <http://www.securingjava.com>
Let's be honest, the only thing you need to do to exploit this bug even without a JavaScript flaw in the person's browser is to trick the user into running some code on his machine. That's not too tough. I can e-mail all my friends a "dancing pigs" demo, and 90% of them will run it. That's a given. Of course, if you can run code on other people's machine, there are lots of things you can do. The reason why this bug is a bigger problem is that POP/IMAP account info often doubles as a unix account. Also, people reuse their passwords on multiple accounts. Basically, this bug makes it much easier for a hacker to spread to new machines once one machine has been compromised. > Yesterday we were informed that Dave Edis of Interactivetools created ... I think that current WINDOWS versions might be more accurate. We only broke Windows encryption. Unix and Mac versions were slightly different; Windows pre-4.0 or so was different as well. We could tell it was similar, but not quite as complex. The primary difference seemed to be that there was no permutation of the bits. When we talked to Netscape, we were told they knew the algorithm could be a lot better, but they were hoping it was unlikely anyone would target it and break it. They never indicated that they knew about their old cipher being broken, either, but I'd bet they knew about it, prompting the changes that led to the current algorithm. > As for sniffers, I believe you are correct about POP3 and plaintext ... I didn't catch the original message, so I hope my response is appropriate. Sniffers are a big problem, but they generally require a person to have compromised administrative access on one machine on the local network to exploit. It can also be hard to mine the data, and there are reasonable detection techniques for sniffers (see l0pht's antisniff). In short, I think it'd be a fair bit easier for script kiddies to take advantage of this problem (assuming someone has given them a nice compact exploit) than to break in, install a sniffer, and retrieve and mine the results.
That's an excellent advisory regarding seemingly securely encrypted passwords by Netscape Communicator. Unfortunately, that particular issue was already previously discovered by others, as evidenced by BUGTRAQ mailings around November 7th and 8th, 1998 by Holger van Lengerich <gimli@uni-paderborn.de> and Thievco <thievco@sprite.netnation.com>. Credit where it's due and all. I seem to recall having also seen a C source file via BUGTRAQ before to decode the stored password, too. Also, the referenced link at http://www.rstcorp.com/news/bad-crypto.html returns a 404 Not Found error. I'm not sure that saving passwords is a bad thing per se; it is possible to approach this through technological means, but seems it would be better addressed by policy means such as user education and policies on diversity of passwords for various accounts, as well as better suggestions for (user) memorizable passwords. Or in the very least, put up an initial one time dialog box strongly discouraging the use of the option. That said, XOR'ing the password does seem somewhat weak, and the RISKS of employing either poor choices for passwords or storing them in a less than secure manner without making noise about it to users seems obvious. Dan Foster <dsf@gblx.net>
Please report problems with the web pages to the maintainer