Re: Netscape rewards are an insult
Alice here ... I know that this is *painfully* dated, and I apologize to the list for replying to a one month old post, but I felt I had to put some final items on the record. And I think that this is still timely ... so ... On Sat, 14 Oct 1995, Dr. Frederick B. Cohen wrote:
Phil typed:
Have things really come to this? Besides the legal implications of discovering a hole and then selling the information to someone, (who presumably will only want this information for one purpose) where has the attitude of doing for the sake of doing gone?
It's one thing to do good for the sake of doing good. Most of us do that every day by participating in this list. It's quite another thing to be insulted in the process. I think that Netscape's reward is an insult,
Dr. Frederick B. Cohen has nailed it once again. He's right. But Phil's comments really need to be addressed ... vis-a-vis the implications of "discovering a hole and selling it". Phil's hypothetical is rightfully worrisome, but we should remember it _is_ only a hypothetical. Let's not worry much about hypotheticals. Perhaps we should worry more about what in fact IS an ACTUAL, rather than what might possibly be. The hand-wringing should be over the existing reactions to publicly ignored security holes and the ETHICS of the new Internet players. The ones who are so very cock-sure of themselves. So cock-sure, that they willingly gamble with public security and think that their invasion of individuals personal boundaries and privacy is nothing noteworthy. That it will just somehow pass. My post detailing a structural flaw in Netscape Navigator was announced, very quietly, to this list OVER ONE MONTH AGO. And what has been done about it, by AT&T and/or Netscape?? Nothing. AT&T has its reputation attached to this code, as does Deutsche Telecom, as does Netscape. The only "action" they've taken is to info-freeload and then do absolutely, positively, definitely ... nothing. Diddly-squat. No one has taken any action whatsoever. How would we treat a company ... let's say a construction company that found out that one of its buildings was unsafe, and then proceeded not to barricade the complex. If the company found out that the girders were not up to the engineered spec, and simply allowed risk and harm to continue. If the Company thought it was OK to gamble with people's lives? Would we say that the reckless disregard for the public interest merited criminal sanction?? Hopefully, we would. To attack some hypothetical "information provider" for selling some "hypothetical" information which a corporation denies is actually of any value, at all -- nominal, or otherwise -- is an argument that just doesn't float. It completely misses the mark.
If they think you can find major security bugs in Netscape for as little as $1000, they should take the product off the market, or at least stop claiming that it offers security.
They should definitely take the product off the market. Period. They should also stop claiming that it offers any security. In fact, they should attach a product warning label, something that says that Netscape Navigator degrades your inherent safety and security as soon as you use it. That would be the "right thing" to do. Because that is truthful. AT&T's "brass" should have used the "Tylenol" or "Perrier" crisis management model on this one. Rather than, "The stick your head in the sand like an ostrich" model. Or the "Gee, maybe if I close my eyes, and pull the covers over my head, the boogie-man will go away" school. Someone has to call them on their collective jump into the World of Management by Denial. The issue here isn't the so-called "reward", the focus should rightly be placed on who knew what and when they knew it, and what they did as a consequence. The issue is whether these Goliath Companies, happily roll the dice when public safety and security is on the line. It's that simple. A real no brainer.
Has Netscape been pestering security experts on the net for free work? Have they been plaguing people or lists with email asking the net to do their jobs?
They do far worse. They claim security when they don't have it, and when the cypherpunks demonstrate the false claims, Netscape offer insulting future tribute. I think that if they are sincere, they should reward the individuals who found the last few holes with $25,000 each, and show that they really mean business.
Actually, they said that they want to "harness" the power of the internet, and in return offered a chance to be enrolled in a contest for a mug or a T-shirt, or maybe ... if they ... in "their sole discretion" thought something was a security bug, then they'd offer a $1,000 award. Not *pestering* security experts, but simply asking them to sorta, kinda take a look at the product. Look, and help build the Companies' fortunes, while the "Creative" talent might get a nice Netscape mug for their troubles. This is what Netscape DID, but this isn't the true issue. The true issue is a question of attitudes, not of monetary compensation. I really don't care if Netscape or AT&T offer gold stars and nice little pats on the head, or offer many "millions" or offer $25,000, or expect the world's foremost security auditors to work for T-shirts or a bitta Crackerjack. That's not the issue. I just don't believe that any company should on the one hand represent that they have a secure product -- that they actually care about security -- while on the other hand they take their black-box code and say that anyone who brings an error to their attention -- a critical security flaw -- agrees implicitly to make the report the Company's property -- property to be used at the Company's sole discretion. A security review audit is first and foremost for the benefit of the end users. The audit is not so that the company can use the information for its own purposes. The information is not there so that the company can use a confidential auditor's report on security flaws to spy on their own customers, and its certainly not there to enable a code cover-up. Hell, these firms try to cover up even when the information is PUBLIC, let alone when it's given to them in private. And the crying and whining is unbecoming, because the attempt at private communication was made. It was made with both Netscape, and with AT&T.
The ironic part is the people who have been the most successful at finding bugs are not the ones who are demanding money for it!
You're right. the people who find the bugs simply ask that the public interest be served ... that the Network's interest be served, and that the National interest be served. Defective product serves no one, and adding an object to an existing computing environment under the rubric of an experimental data type serves no-one. Correction, it serves no-one except those who would rather see harm come to the public. Those who value and place their own self-interest above that of others. And the consequnces be damned.
The ironic part is that a company that claims to have a "secure" method for using credit cards on the Internet thinks that their security is so weak that it only takes $1000 to find a major hole.
The ironic part is that even once a critical design flaw is identified, no action is taken by anyone -- even when the person who finds it demands no money whatsoever for it -- the real irony is that the press is silent, and so is the company. See no evil, speak no evil, hear no evil. Let the harm and damage continue ... by my calculation, it's been one month already ... shall we maybe try now for two?? I don't think so.
-- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
Alice de 'nonymous ... ...just another one of those... ...hunters... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.
Dr. Frederick B. Cohen wrote:
On a closely related vein, Sun has announced that they are severely limiting some functions in HotJava - from Risks-17-45:
[ excerpts from Sun announcement deleted ]
I had a rather lengthy discussion with a gentleman from Sun at the CSI conference last Tuesday night, and this announcement follows many of the things we discussed very closely. This kind of consistency between what people say and what the company published is refreshing, and it restores my faith in Sun's desire to do things well. Of course there are still some problems left unresolved:
[ more of Sun announcement deleted ]
I do think that this response by Sun, regardless of the technical merits of the particulars, demonstrates a desire to improve protection and a willingness to listen. My compliments for that.
All of these security measures are implemented by Netscape in the current release. Specifically, Netscape Navigator 2.0beta2 includes all the applet security precautions detailed in the recent comp.lang.java posting. Netscape has been shipping the fixed applet security model for over a month(since 2.0Beta1), and Netscape and Sun continue to cooperate and work closely on applet security issues. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
Jeff wrote:
All of these security measures are implemented by Netscape in the current release. Specifically, Netscape Navigator 2.0beta2 includes all the applet security precautions detailed in the recent comp.lang.java posting. Netscape has been shipping the fixed applet security model for over a month(since 2.0Beta1), and Netscape and Sun continue to cooperate and work closely on applet security issues.
All of these are very conservative measures and they seem to be the best approach for the present. They do remove some of the more interesting features of Java. Sun commented to me in an interview that "we would not see a more complex security model until they adding encryption and digi-sig's, etc." My question is, can a corporate user replace the security class in Netscape. I understand that all the class libs are in an external file. While a virus might exploit this... my reason for asking is for corporate developers who are building "intra"net systems.. making some tweaks to the security class would give them the flexibility they need. Otherwise we have taken much of the fun out of Java. (for good reasons).
Jeff Weinstein writes:
All of these security measures are implemented by Netscape in the current release. Specifically, Netscape Navigator 2.0beta2 includes all the applet security precautions detailed in the recent comp.lang.java posting. Netscape has been shipping the fixed applet security model for over a month(since 2.0Beta1), and Netscape and Sun continue to cooperate and work closely on applet security issues.
I've got to note just one thing -- every Netscape 2.0beta2 I've used has been so full of bugs, and so prone to problems, that I have my wonders about what the security code looks like. I know, Jeff, that its all done by different groups -- but the Java stuff I've run in 2.0beta2 is so weirdly different than the supposedly compatible stuff I've run under HotJava -- especially when it comes to crashing (and it HAS crashed on me) that I have serious worries about the security of the thing. I'd say the quality looks very much like an alpha release, not "beta". I don't want to turn this to Javapunks so I won't say more on this topic any time soon -- its already been beaten into the ground. Perry
Matthew James Sheppard wrote:
I've got to note just one thing -- what about the Netscape LiveScript language? is it opening up the same security can of worms as java? I realise that it provides functionality specific to browsing only (no network/files) but the potential for bugs when you add another language must increase.
One advantage that livescript has is that it was designed and implemented by one individual, removing communication problems as a possible source of holes. We are reviewing the set of reflected objects for possible security problems, and will be taking a conservative approach to what we include. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
Perry E. Metzger wrote:
Jeff Weinstein writes:
All of these security measures are implemented by Netscape in the current release. Specifically, Netscape Navigator 2.0beta2 includes all the applet security precautions detailed in the recent comp.lang.java posting. Netscape has been shipping the fixed applet security model for over a month(since 2.0Beta1), and Netscape and Sun continue to cooperate and work closely on applet security issues.
I've got to note just one thing -- every Netscape 2.0beta2 I've used has been so full of bugs, and so prone to problems, that I have my wonders about what the security code looks like. I know, Jeff, that its all done by different groups -- but the Java stuff I've run in 2.0beta2 is so weirdly different than the supposedly compatible stuff I've run under HotJava -- especially when it comes to crashing (and it HAS crashed on me) that I have serious worries about the security of the thing. I'd say the quality looks very much like an alpha release, not "beta". I don't want to turn this to Javapunks so I won't say more on this topic any time soon -- its already been beaten into the ground.
The version of Java in Netscape is not compatible with the version of Java in the summer release of HotJava. There were incompatible changes made by Sun between their alpha(summer HotJava) and beta (Netscape 2.0 and Sun's JDK Beta). As I understand the situation, applets that were written for HotJava must be ported to the beta API for them to work with more recent releases of Java. I would agree that Java is not as stable as the rest of the 2.0 release. That is one reason why we have added a preference to disable Java. If you are worried about it you can just switch it off. I argued for this switch because I knew that there would be people who would not want to trust Java until it had some mileage on it. The early beta releases we do are mostly intended for developers and early adopters who want early access to the new features. We had a great leap in quality between B1 and B2, and I expect that to continue with the future betas. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
The shadowy figure took form and announced "I am "Perry E. Metzger" and I say . ..
Jeff Weinstein writes:
All of these security measures are implemented by Netscape in the current release. Specifically, Netscape Navigator 2.0beta2 includes all the applet security precautions detailed in the recent comp.lang.java posting. Netscape has been shipping the fixed applet security model for over a month(since 2.0Beta1)...
I've got to note just one thing -- every Netscape 2.0beta2 I've used has been so full of bugs, and so prone to problems, that I have my wonders about what the security code looks like.
Well beta2 is heaps better than beta1, I can still crash beta2 with or without java under win3, sgi, solaris and alpha but it has to be used for a longer and few crashes are repeatable. Plus lots of new gizmos, the certificate authority interface (thanks Jeff). I've got to note just one thing -- what about the Netscape LiveScript language? is it opening up the same security can of worms as java? I realise that it provides functionality specific to browsing only (no network/files) but the potential for bugs when you add another language must increase. -- <URL:http://www.comp.vuw.ac.nz/~matt> |~ |~ |~ o| o| ('< o| ,',) ''<< ---""---
Alice here ... ... My post detailing a structural flaw in Netscape Navigator was announced, very quietly, to this list OVER ONE MONTH AGO. And what has been done about it, by AT&T and/or Netscape?? Nothing.
AT&T has its reputation attached to this code, as does Deutsche Telecom, as does Netscape. The only "action" they've taken is to info-freeload and then do absolutely, positively, definitely ... nothing.
Diddly-squat.
No one has taken any action whatsoever.
On a closely related vein, Sun has announced that they are severely limiting some functions in HotJava - from Risks-17-45: : The paper written by the two students at Princeton describes possible : attacks on the alpha3 HotJava browser, which have all been fixed in JDK : beta. Granted, until this week, the source code for JDK beta wasn't : available, so it's understandable that they analyzed the alpha3 source base. : : We understand people need more information on the security model, and we're : taking time right now to document the security story more rigorously. A : security FAQ, an updated whitepaper, detailed user documentation and : detailed implementor's documentation are all being worked on. : : ... : : Access Control Lists are greatly restricted in beta, : as compared to the situation in the alpha3 HotJava browser. : ACLs are initialized - only once - by the applet security : manager, and are not user configurable. : : For a file not on the access control list, an applet cannot : : - check for the existence of the file : - read the file : - write the file : - check the file type : - check if the file is a directory : - check the timestamp when the file was last modified : - check the file's size : - create a directory : - rename the file : - list the files in this file (as if it were a directory) : : Applets cannot : : - create a FileInputStream : - create a RandomAccessFile, either for reading or writing : - Open file descriptors : : 2. Sockets: : : Applets cannot : : - Create socket connections other than to its own host : - Create a socket factory : : 3. Loading/linking: : : Applets cannot : : - Create class loaders : - Access a package in the sun.* hierarchy : - Define a new class in the java.* hierarchy : - Link dynamic libraries using System.loadLibrary() : - Disable or override the AppletSecurityManager : : 4. Process control: : : Applets cannot : : - Define native methods : - Fork processes : - Manipulate threads or thread groups outside of the : applet's thread group : - Exit the virtual machine (e.g., the browser or the appletviewer) : : 5. awt: : : Applets cannot : : - Create toplevel windows that don't have a warning banner : : ... I had a rather lengthy discussion with a gentleman from Sun at the CSI conference last Tuesday night, and this announcement follows many of the things we discussed very closely. This kind of consistency between what people say and what the company published is refreshing, and it restores my faith in Sun's desire to do things well. Of course there are still some problems left unresolved: :... : It's very difficult, if not impossible, for a web browser to completely : prevent denial of service attacks. The JDK applet API doesn't claim to : prevent denial of service attacks. A "denial of service" attack is where : someone writes an applet whose goal is to consume all available resources on : your computer, forcing you to kill the browser you're running. For example, : someone could write an applet that creates a million pop-up windows. The : windows don't do anything, but creating a million of them might use up all : the virtual memory on your computer and you'd have to kill the web browser : to reclaim the virtual memory. : : Before people engage in too much wailing and gnashing of teeth about : how applets have been too severely restricted - : : We want to enable applets to do interesting things, including making : socket connections, and reading and writing to the file system. One : way to enable that is to used a signed class loader. When a trusted : applet is loaded, then the applet could be granted permission to do : some of the things they are prevented from doing by default. : : The goal is to ensure that untrusted applets can't steal or damage : information on a computer running a Java-enabled browser. Later, we can : allow trusted applets to do things that untrusted applets are not allowed to : do. Since an implementation bug in a trusted applet could open a loophole : that could be exploited by an untrusted applet, design matters. :... Similarly, if your HotJava allows an insecure Postscript implementation to interpret postscript files, you're still beat. I do think that this response by Sun, regardless of the technical merits of the particulars, demonstrates a desire to improve protection and a willingness to listen. My compliments for that. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
On a closely related vein, Sun has announced that they are severely limiting some functions in HotJava - from Risks-17-45:
The problems found however, were not fundamental flaws in the Java language itself nor in the Java virtual machine. As I've said many times, you can pretty much rip any i/o capability out of Java by changing the runtime class libraries. If someone finds as way to to defeat the Java bytecode verifier/class loader and replace a class in java.* with a more powerful one, then that will be really significant.
I had a rather lengthy discussion with a gentleman from Sun at the CSI conference last Tuesday night, and this announcement follows many of the things we discussed very closely. This kind of consistency between what people say and what the company published is refreshing, and it restores my faith in Sun's desire to do things well. Of course there are still some problems left unresolved:
[denial of service problems deleted. ]
Similarly, if your HotJava allows an insecure Postscript implementation to interpret postscript files, you're still beat.
This is not a flaw or a feature. If you download a helper app off the internet that has a flaw, it's not a flaw in the browser. Claiming that it is is like claiming that "ftp" or "nfs" has a fatal flaw because it allows you execute untrusted binaries from other computers. Helper apps are in the category of third party add-ons and the responsibility for their correct implementation rests on the companies which sell them. Netscape never claimed the ability to allow users to download executable binary applications from the net and run them without risk. Netscape doesn't come with a postscript interpreter nor does it have one configured by default, so if the user installs one and configures it, and it has a security flaw, it's not Netscape's fault. Installing helper apps is not "easy" compared with clicking on a Java applet so any user who does it must atleast be somewhat knowledgable. If a postscript interpreter is implemented in JDK Beta, and it is insecure and it is allowed to interpret postscript files, nothing bad will happen.
I do think that this response by Sun, regardless of the technical merits of the particulars, demonstrates a desire to improve protection and a willingness to listen. My compliments for that.
They've never demonstrated otherwise in my entire history on the Java mailing lists. Their whole mission is to produce a secure environment for executing untrusted applications. The alpha's and beta's of every product have problems, it's to be expected. The whole point of releasing a beta is so that you can get feedback. -Ray
participants (7)
-
anonymous-remailer@shell.portal.com -
fc@all.net -
Harry S. Hawk -
Jeff Weinstein -
Matthew James Sheppard -
Perry E. Metzger -
Ray Cromwell