Netscape Logic Bomb detailed by IETF
With all of the Noise on this list, and all of the opinion that has been expressed, opinion which would seek to slander, misrepresent or opinion which would like to represent itself as fact, it has increasingly become difficult to separate the wheat from the chaff. Clearly, someone has a vested interest which they are expending a great deal of effort to protect. My email to Netscape detailing their logic bomb has gone unanswered, and unacknowledged for ten days now. Ten days is a long time for no "official" comment. Just as ten days is a long time not to answer email. Rather than attacking individual posters, rather than questioning credentials, rather than scaring journalists, rather than intimidating and wilfully spreading misinformation to create confusion, rather than doing any of this, I will simply quote the official minutes of the Internet Engineering Task Force (IETF) which is the protocol engineering, development and standardization arm of the Internet Architecture Board (IAB). The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet protocol architecture and the smooth operation of the Internet. Request-For-Comments are a series of memorandums which act as official minutes of the IETF. Request-For-Comments No. 1521 (RFC-1521) Subsection 7.4.2 is authoritative and has been reviewed and has received international approval. To avoid the accusation, of misquoting, I will simply quote Section 7.4.2 of RFC1521 in its entirety. This memorandum has unlimited distribution and is available by FTP from DS.INTERNIC.NET, NIS.NSF.NET, NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, FTP.CONCERT.NET, or FTP.SESQUI.NET. European readers might be advised to use the United Kingdom repository at SRC.DOC.IC.AC.UK. Asian & Pacific Users should probably use the local mirror for WUARCHIVE.WUSTL.EDU, or alternatively, their local National RFC repository.
7.4.2. The Application/PostScript subtype
A Content-Type of "application/postscript" indicates a PostScript program. Currently two variants of the PostScript language are allowed; the original level 1 variant is described in [POSTSCRIPT] and the more recent level 2 variant is described in [POSTSCRIPT2].
PostScript is a registered trademark of Adobe Systems, Inc. Use of the MIME content-type "application/postscript" implies recognition of that trademark and all the rights it entails.
The PostScript language definition provides facilities for internal labeling of the specific language features a given program uses. This labeling, called the PostScript document structuring conventions, is very general and provides substantially more information than just the language level.
The use of document structuring conventions, while not required, is strongly recommended as an aid to interoperability. Documents which lack proper structuring conventions cannot be tested to see whether or not they will work in a given environment. As such, some systems may assume the worst and refuse to process unstructured documents.
The execution of general-purpose PostScript interpreters entails serious security risks, and implementors are discouraged from simply sending PostScript email bodies to "off-the-shelf" interpreters. While it is usually safe to send PostScript to a printer, where the potential for harm is greatly constrained, implementors should consider all of the following before they add interactive display of PostScript bodies to their mail readers.
The remainder of this section outlines some, though probably not all, of the possible problems with sending PostScript through the mail.
Dangerous operations in the PostScript language include, but may not be limited to, the PostScript operators deletefile, renamefile, filenameforall, and file. File is only dangerous when applied to something other than standard input or output. Implementations may also define additional nonstandard file operators; these may also pose a threat to security. Filenameforall, the wildcard file search operator, may appear at first glance to be harmless. Note, however, that this operator has the potential to reveal information about what files the recipient has access to, and this information may itself be sensitive. Message senders should avoid the use of potentially dangerous file operators, since these operators are quite likely to be unavailable in secure PostScript implementations. Message- receiving and -displaying software should either completely disable all potentially dangerous file operators or take special care not to delegate any special authority to their operation. These operators should be viewed as being done by an outside agency when interpreting PostScript documents. Such disabling and/or checking should be done completely outside of the reach of the PostScript language itself; care should be taken to insure that no method exists for re-enabling full-function versions of these operators.
The PostScript language provides facilities for exiting the normal interpreter, or server, loop. Changes made in this "outer" environment are customarily retained across documents, and may in some cases be retained semipermanently in nonvolatile memory. The operators associated with exiting the interpreter loop have the potential to interfere with subsequent document processing. As such, their unrestrained use constitutes a threat of service denial. PostScript operators that exit the interpreter loop include, but may not be limited to, the exitserver and startjob operators. Message- sending software should not generate PostScript that depends on exiting the interpreter loop to operate. The ability to exit will probably be unavailable in secure PostScript implementations. Message-receiving and -displaying software should, if possible, disable the ability to make retained changes to the PostScript environment, and eliminate the startjob and exitserver commands. If these commands cannot be eliminated, the password associated with them should at least be set to a hard-to-guess value.
PostScript provides operators for setting system-wide and device- specific parameters. These parameter settings may be retained across jobs and may potentially pose a threat to the correct operation of the interpreter. The PostScript operators that set system and device parameters include, but may not be limited to, the setsystemparams and setdevparams operators. Message-sending software should not generate PostScript that depends on the setting of system or device parameters to operate correctly. The ability to set these parameters will probably be unavailable in secure PostScript implementations. Message-receiving and -displaying software should, if possible, disable the ability to change system and device parameters. If these operators cannot be disabled, the password associated with them should at least be set to a hard-to-guess value.
Some PostScript implementations provide nonstandard facilities for the direct loading and execution of machine code. Such facilities are quite obviously open to substantial abuse. Message-sending software should not make use of such features. Besides being totally hardware- specific, they are also likely to be unavailable in secure implementations of PostScript. Message-receiving and -displaying software should not allow such operators to be used if they exist.
PostScript is an extensible language, and many, if not most, implementations of it provide a number of their own extensions. This document does not deal with such extensions explicitly since they constitute an unknown factor. Message-sending software should not make use of nonstandard extensions; they are likely to be missing from some implementations. Message-receiving and -displaying software should make sure that any nonstandard PostScript operators are secure and don't present any kind of threat.
It is possible to write PostScript that consumes huge amounts of various system resources. It is also possible to write PostScript programs that loop infinitely. Both types of programs have the potential to cause damage if sent to unsuspecting recipients. Message-sending software should avoid the construction and dissemination of such programs, which is antisocial. Message- receiving and -displaying software should provide appropriate mechanisms to abort processing of a document after a reasonable amount of time has elapsed. In addition, PostScript interpreters should be limited to the consumption of only a reasonable amount of any given system resource.
Finally, bugs may exist in some PostScript interpreters which could possibly be exploited to gain unauthorized access to a recipient's system. Apart from noting this possibility, there is no specific action to take to prevent this, apart from the timely correction of such bugs if any are found.
Hopefully this sets the record clear, once and for all with authority whose credentials cannot be questioned nor attacked. I wonder though, did Netscape not know about RFC1521?? You'd expect them to, wouldn't you?? Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.
Mr. Anonymous has a good reason to be anonymous -- he's an annoying fool. Yes, Mr. Anonymous, we all know postscript is dangerous. Thank you for this stunning revelation. We've read the IETF documents before, and some of us even helped write them. anonymous-remailer@shell.portal.com writes:
Clearly, someone has a vested interest which they are expending a great deal of effort to protect. My email to Netscape detailing their logic bomb has gone unanswered, and unacknowledged for ten days now.
Maybe because you're an idiot and they don't feel that its necessary to answer. What more need be said? Those of us who care run our postscript interpreters with all the dangerous commands stripped out, but given that Netscape doesn't supply postscript interpreters, its not really their fault or problem. Perry
Mr. Anonymous has a good reason to be anonymous -- he's an annoying
Perhaps.
fool.
I don't agree.
Yes, Mr. Anonymous, we all know postscript is dangerous. Thank you for this stunning revelation. We've read the IETF documents before, and some of us even helped write them.
Then you should support his point which is valid.
anonymous-remailer@shell.portal.com writes:
Clearly, someone has a vested interest which they are expending a great deal of effort to protect. My email to Netscape detailing their logic bomb has gone unanswered, and unacknowledged for ten days now.
Maybe because you're an idiot and they don't feel that its necessary to answer. What more need be said?
Being insulting and calling people names benefits nobody.
Those of us who care run our postscript interpreters with all the dangerous commands stripped out, but given that Netscape doesn't supply postscript interpreters, its not really their fault or problem.
I strongly disagree. If Netscape provided a way to execute shell commands on your host from a remote computer, it would certainly be a hole created by their product. The fact that the default shell is potentially dangerous means it's incumbant on those who provide access to it to provide adequate protection. If Netscape wants to claim their product doesn't degrade security, they should provide a safe postscript interpreter or not provide hooks to unsafe ones. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
On Mon, 23 Oct 1995, Dr. Frederick B. Cohen wrote:
Yes, Mr. Anonymous, we all know postscript is dangerous. Thank you for this stunning revelation. We've read the IETF documents before, and some of us even helped write them.
Then you should support his point which is valid.
I don't think they have vested interests at all. I think that they are able to see that the problem is not with the browser. You know "/bin/login" is insecure because it allows hooks for unpasswded logins, I mean if the user wanted to they could leave root unpasswded and if they are using "/bin/login" someone could get into their system just like that. That point is NOT valid IMO.
I strongly disagree. If Netscape provided a way to execute shell commands on your host from a remote computer, it would certainly be a hole created by their product. The fact that the default shell is potentially dangerous means it's incumbant on those who provide access to it to provide adequate protection.
NO, postscript provides the method for executing shell commands if you accept postscript from anywhere. Netscape can NEVER be "fool"proof against all hardware errors, particularly loose nuts on the keyboard. Nesta Stubbs "Betsy, can you find the Pentagon for me? Cynico Network Consulting It has five sides and a big parking lot" nesta@cynico.com -Fred McMurray-
In message <9510231413.AA26514@all.net>, Dr. Frederick B. Cohen writes: [...]
I strongly disagree. If Netscape provided a way to execute shell commands on your host from a remote computer, it would certainly be a hole created by their product. The fact that the default shell is potentially dangerous means it's incumbant on those who provide access to it to provide adequate protection.
They do, add: application/x-shell; sh %s to your .mailcap. They had better stop supporting mailcap alltogether, after all *any* of the programs in there could have buffer overflows, or other security problems. I'll bet some of them even do, anyone want to see if sox (a program that transforms sound files from format to format - frequently used to convert .wav files to .au files) has any overruns in the chunk handling code?
If Netscape wants to claim their product doesn't degrade security, they should provide a safe postscript interpreter or not provide hooks to unsafe ones.
Sure, and they had better find a way to keep us from editing the binary and adding whatever insecure features we may want to their program. obcrypto: mabie it would be a good idea for programs to list problems that are beoynd their control. To many people it may be supprising that anything in their .mailcap could hurt them. To others it is hardly a shock and seeing alot of messages about it tends to get rather boreing, esp. as a few people jump up and down and yell about the Danger To Us All...
Dr. Frederick B. Cohen wrote:
In message <9510231413.AA26514@all.net>, Dr. Frederick B. Cohen writes: [...]
I strongly disagree. If Netscape provided a way to execute shell commands on your host from a remote computer, it would certainly be a hole created by their product. The fact that the default shell is potentially dangerous means it's incumbant on those who provide access to it to provide adequate protection.
They do, add:
application/x-shell; sh %s
to your .mailcap.
They had better stop supporting mailcap alltogether, after all *any* of the programs in there could have buffer overflows, or other security problems. I'll bet some of them even do, anyone want to see if sox (a program that transforms sound files from format to format - frequently used to convert .wav files to .au files) has any overruns in the chunk handling code?
This is where the difference between your view and mine seem to part company. I am not talking about some bug in postscript or the shell. I am talking about a program that grants remote access to run these programs in the normal manner, which is unsafe.
To support the position you seem to be taking (and the one currently taken by Netscape), you would have to say that the last several Sendmail "bugs" were not sendmail problems but rather shell problems because all sendmail did was allow you to execute a shell from the remote machine (perhaps via a queue file).
The execution of shell commands by sendmail was not approved by the user. The execution of a shell or postscript interpreter, or whatever, by netscape must be configured by the user. These are not the same situation at all.
If Netscape wants to claim their product doesn't degrade security, they should provide a safe postscript interpreter or not provide hooks to unsafe ones.
Sure, and they had better find a way to keep us from editing the binary and adding whatever insecure features we may want to their program.
That's correct. Secure software has to have secure distribution in order to maintain its security when distributed through an untrusted channel. I think that Netscape uses an MD5 checksum which the members of this list seem to place unlimited trust in (incorrectly in my view, but that would be picking two nits with one keyboard entry).
I posted a list of MD5 checksums as a personal favor to various cypherpunks who asked for them, since I have access to the original bits. The official Netscape solution for checking your downloaded distribution will be announced later in the year. In the mean time anyone who is uncomfortable with downloading the bits from the net can always buy a copy. We will ship them the distribution on floppy. Do you have something better than MD5 to suggest? If so, on what do you base this opinion? --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
I posted a list of MD5 checksums as a personal favor to various cypherpunks who asked for them, since I have access to the original bits. The official Netscape solution for checking your downloaded distribution will be announced later in the year. In the mean time anyone who is uncomfortable with downloading the bits from the net can always buy a copy. We will ship them the distribution on floppy.
That's quite lame.. (not on your part jeff, obviously, because you posted the md5s) Netscape's responses in the past has been pretty quick, but this is damn slow. I am disappointed. -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer@c2.org
DOCTOR Frederick B. Cohen writes:
[...] uses an MD5 checksum which the members of this list seem to place unlimited trust in (incorrectly in my view, but that would be picking two nits with one keyboard entry).
Can you elaborate with facts on the supposed weakness of MD5 ? [btw who talked about 'unlimited' trust ?] dl -- Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|... Freedom Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept AK-47 PGP domestic disruption CIA cracking strategic Clinton
[...] uses an MD5 checksum which the members of this list seem to place unlimited trust in (incorrectly in my view, but that would be picking two nits with one keyboard entry).
Can you elaborate with facts on the supposed weakness of MD5 ?
I didn't say that there were any weaknesses in MD5, all I said was: "unlimited trust ... (incorrectly in my view...)" The lack of adequate demonstration of strength is not the same as a weakness. It represents only a lack of adequate assurance for placing more than a certain amount of trust in MD5 for the purpose it is being used to accomplish. As to weaknesses, I seem to remember that someone managed to forge a modification to a program used to observe networks on a Sun so that it had the same MD5 checksum as the official trusted version. But whether this is real is not strictly the issue. In the case of the trust being placed in MD5 by Netscape, the assumption being made (without adequate support as far as I can tell) is that an MD5 checksum cannot be forced, through a chosen plaintext attack, to yield checksums of 1, 2, 3, 5, 7, 9, ... on up to enough primes to allow the known plaintext attack that gets the RSA private key used to authenticate messages. As far as I am aware (and I may not be aware of everything) there is no reference work to support this assumption. If the assumption is wrong, then the whole SSL can fall to a selected plaintext attack launchable (presumably) through those general purpose Java aplets we have heard so much about.
[btw who talked about 'unlimited' trust ?]
There has been no limit given by anyone on this list to the level of trust they place in MD5. Several people have posted (without contention) that MD5 is sufficiently trustworthy to trust billions of dollars in commerce to it's being able to prevent a selected plaintext attack as eluded to above. If you think we should trust it, and you don't limit your assessment of trust, what other assumption should I make? If several people proclaim that trust and nobody stands up in disagreement, tacit agreement is my normal (although not necessarily justified) assumption. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
As to weaknesses, I seem to remember that someone managed to forge a modification to a program used to observe networks on a Sun so that it had the same MD5 checksum as the official trusted version. But whether this is real is not strictly the issue.
Ron has not mentioned such an event to me and if that were the case I would seriously doubt that he would not have been told about it. The only comment he generally makes is that he wrote MD5 because "MD4 was making me nervous".
In the case of the trust being placed in MD5 by Netscape, the assumption being made (without adequate support as far as I can tell) is that an MD5 checksum cannot be forced, through a chosen plaintext attack, to
Netscape do not simply use the MD5 of the message, they are using (as I understand it) the PKCS#1 standard for makoing the signature. If not they probably have severe problems.
There has been no limit given by anyone on this list to the level of trust they place in MD5. Several people have posted (without contention) that MD5 is sufficiently trustworthy to trust billions of dollars in commerce to it's being able to prevent a selected plaintext attack as eluded to above.
NIST and the NSA trusted MD4 sufficiently to base SHA upon it. SHA is preferable in many ways to MD5, it has a different approach to extending the scheduling and resist differential cryptanalysis. There is a problem with the compressor function of MD5 which I dislike. This is fairly irrelevant though since SSL allows other digests to be used. Phill
As to weaknesses, I seem to remember that someone managed to forge a modification to a program used to observe networks on a Sun so that it had the same MD5 checksum as the official trusted version. But whether this is real is not strictly the issue.
Ron has not mentioned such an event to me and if that were the case I would seriously doubt that he would not have been told about it. The only comment he
generally makes is that he wrote MD5 because "MD4 was making me nervous".
In the case of the trust being placed in MD5 by Netscape, the assumption being made (without adequate support as far as I can tell) is that an MD5 checksum cannot be forced, through a chosen plaintext attack, to
Netscape do not simply use the MD5 of the message, they are using (as I understand it) the PKCS#1 standard for makoing the signature. If not they probably have severe problems.
There has been no limit given by anyone on this list to the level of trust they place in MD5. Several people have posted (without contention) that MD5 is sufficiently trustworthy to trust billions of dollars in commerce to it's being able to prevent a selected plaintext attack as eluded to above.
NIST and the NSA trusted MD4 sufficiently to base SHA upon it. SHA is preferab le in many ways to MD5, it has a different approach to extending the scheduling a nd resist differential cryptanalysis. There is a problem with the compressor function of MD5 which I dislike. This is fairly irrelevant though since SSL allows other digests to be used.
Phill
I hesitate to jump in to this exchange given the defensive and vague nature of the discussion, but... While I agree that SHA seems preferable, for a number of reasons, to MD5, it is worth noting that Hans Dobbertin of the German Information Security Agency recently found a collision in MD4. His attack allows you to generate a pair of plainexts that generate the same hash. A fast technique for finding a second plaintext that hashes to some given value remains an open problem with MD4 (and SHA and MD5, for that matter). As far as I can tell the attack does not readily generalize to MD5 or SHA. -matt
On Tue, 24 Oct 1995, Dr. Frederick B. Cohen wrote:
[...] In the case of the trust being placed in MD5 by Netscape, the assumption being made (without adequate support as far as I can tell) is that an MD5 checksum cannot be forced, through a chosen plaintext attack, to yield checksums of 1, 2, 3, 5, 7, 9, ... on up to enough primes to allow the known plaintext attack that gets the RSA private key used to authenticate messages. As far as I am aware (and I may not be aware of everything) there is no reference work to support this assumption. If the assumption is wrong, then the whole SSL can fall to a selected plaintext attack launchable (presumably) through those general purpose Java aplets we have heard so much about.
The above paragraph is complete crap. - Andy, speaking only for himself.
As to weaknesses, I seem to remember that someone managed to forge a modification to a program used to observe networks on a Sun so that it had the same MD5 checksum as the official trusted version. But whether this is real is not strictly the issue.
From memory that particular attack had more to do with altered operating systems which reported back the correct information than anything to do with a md5 hole. It is much easier to tell a program to say "abcdef" than it is to come up with a series of bits that hash to the same md5 result as another series of bits.
Keep trying Fred... you may get somewhere one day. Mark mark@lochard.com.au
Dr. Frederick B. Cohen writes: # MD5 [...] which the members of this list seem to place unlimited trust in # (incorrectly in my view, Laurent Demailly writes:
Can you elaborate with facts on the supposed weakness of MD5 ?
Remember the can-you-trust-PGP flamewar we had a few months ago ? I believe Dr. Cohen's point is that no-one knows, AFAIK, how to prove that a one-way hash is truly one-way (uninvertible). We cannot prove that MD5 is secure, ergo we cannot (completely) trust it. [Please correct if this is a substantially incorrect inference.] One of the standard responses is "it's the best we can do". When people said this about PGP, FBC made some (IMHO) interesting comments about the encryption he uses in various circumstances. Perhaps he would like to share his personal choices of one-way hash functions with us. -Futplex <futplex@pseudonym.com>
Futplex writes:
I believe Dr. Cohen's point is that no-one knows, AFAIK, how to prove that a one-way hash is truly one-way (uninvertible). We cannot prove that MD5 is secure, ergo we cannot (completely) trust it. [Please correct if this is a substantially incorrect inference.]
There are hashes that can, in fact, be proven to have the properties we assign to cryptographic hashes given certain modest assumptions about some number theory problems and their complexity. True "proof" is likely impossible. Perry
...
I believe Dr. Cohen's point is that no-one knows, AFAIK, how to prove that a one-way hash is truly one-way (uninvertible). We cannot prove that MD5 is secure, ergo we cannot (completely) trust it. [Please correct if this is a substantially incorrect inference.]
One of the standard responses is "it's the best we can do". When people said this about PGP, FBC made some (IMHO) interesting comments about the encryption he uses in various circumstances. Perhaps he would like to share his personal choices of one-way hash functions with us.
Since you asked: It's a really complex issue. As a fundamental, we know that any "one-way" hash function must be many-to-one, which means that, in practice, there are always large numbers (2^large numbers) of sources for any given hash. This means that forgeries are always possible. I know of no way to prove that (and no convincing argument that the workload for creating) a forgery is hard for any "one-way" hash function. This seems to mean that we are always betting on faith about these things. The techniques that seem to be reasonably good are; modular exponentiation in a modulus that's the product of two appropriate primes (a.k.a. RSA but throw out the private key when you create it); certain classes of non-linear feedback shift registers of high degree; and some general class of mixing algorithms like MD5. The RSA-type hash is slow, and some great mathematician may show up tomorrow and lay waste to the whole thing. Non-linear feedback shift registers have the advantage that we don't know how to factor high-degree equations, so we don't know how to make simple closed form solutions to find output values. MD5-type systems are good because they combine diffusion and confusion and avoid a lot of the more well-known flaws as far as we know. None of these reasons are particularly convincing, so I think we have to take a risk management approach. So the ultimate question here is, how much are we willing to bet that nobody can break one of these in the intended application over a particular time frame. I trust the RSA and NLFSR systems, if reasonably well implemented, for a single short time-frame low-valued transaction. For example, pick a good pseudo-random number and create an RSA one-way hash of 512 bits (the random number issue is of course another whole area), encrypt the first bloack, Xor with the second block, encrypt the result, etc. till done, then Xor again with the original random seed, send the file and the hash along with the one-way key, and get a confirmation back within a few days. I don't trust any of them as a basis for running a major part of an economy over open communications links, and I especially don't trust them when combined or when the security of one depends on another. To run an economy, I think you need more redundancy, more personnel security, more stop-loss capabilities, physically secure devices, independent checks and balances, etc. Someone on this list mentioned that the banking system trusts the RSA and MD5, etc. but this seems to me to be a mischaracterization. They trust these systems to an extent, but they have key change requirements, regular audits, physical security, relatively secured communications lines (when compared to the Internet), strong procedural controls (most of the time), and other such protections, and they still get hammered for a few million now and then. This is probably enough for now, since the list is probably getting tired of my posts and I have made the major points. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
<grrrrrrr> Frederick B. Cohen writes:
[...] uses an MD5 checksum which the members of this list seem to place unlimited trust in (incorrectly in my view, but that would be picking two nits with one keyboard entry).
[me]> Can you elaborate WITH FACTS on the supposed weakness of MD5 ? ********** I wonder what is your definition of facts...
I didn't say that there were any weaknesses in MD5, all I said was: "unlimited trust ... (incorrectly in my view...)"
The lack of adequate demonstration of strength is not the same as a weakness. It represents only a lack of adequate assurance for placing more than a certain amount of trust in MD5 for the purpose it is being used to accomplish.
As to weaknesses, I seem to remember that someone managed to forge a modification to a program used to observe networks on a Sun so that it had the same MD5 checksum as the official trusted version. But whether This is absolute bullshit with a probability of (2^128-1)/2^128 this is real is not strictly the issue. On the contrary real things should be the issue... not random thoughts
In the case of the trust being placed in MD5 by Netscape, the assumption being made (without adequate support as far as I can tell) is that an because you can't tell 1+1=2 doesn't imply people have to worry... MD5 checksum cannot be forced, through a chosen plaintext attack, to yield checksums of 1, 2, 3, 5, 7, 9, ... on up to enough primes to allow the known plaintext attack that gets the RSA private key used to authenticate messages. As far as I am aware (and I may not be aware of everything) there is no reference work to support this assumption. If The fact that you obviously didn't take the time to do any search/reading on the subject does not allow you to go on with mad assumptions... the assumption is wrong, then the whole SSL can fall to a selected plaintext attack launchable (presumably) through those general purpose Java aplets we have heard so much about. FYI, ( false => false ) is a true expression... starting from false assumption you can demonstrate *anything* { if 1+1!=2, lots of things "fall"} [me]> [btw who talked about 'unlimited' trust ?] There has been no limit given by anyone on this list to the level of trust they place in MD5. Several people have posted (without contention) that MD5 is sufficiently trustworthy to trust billions of dollars in commerce to it's being able to prevent a selected plaintext attack as eluded to above. If you think we should trust it, and you don't limit your assessment of trust, what other assumption should I make? If several people proclaim that trust and nobody stands up in disagreement, tacit agreement is my normal (although not necessarily justified) assumption.
AGAIN, the limit is 2^128 computer operations (as I quoted from the rfc days ago), which is imo certainly NOT the weakest part of the security chain... Do you actually read anything people are mailing or writing ? </grrrrrrr> sorry again, I feel tested... dl -- Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|... Freedom Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept cracking SEAL Team 6 counter-intelligence DES Pasqua Qaddafi class struggle
In message <9510231413.AA26514@all.net>, Dr. Frederick B. Cohen writes: [...]
I strongly disagree. If Netscape provided a way to execute shell commands on your host from a remote computer, it would certainly be a hole created by their product. The fact that the default shell is potentially dangerous means it's incumbant on those who provide access to it to provide adequate protection.
They do, add:
application/x-shell; sh %s
to your .mailcap.
They had better stop supporting mailcap alltogether, after all *any* of the programs in there could have buffer overflows, or other security problems. I'll bet some of them even do, anyone want to see if sox (a program that transforms sound files from format to format - frequently used to convert .wav files to .au files) has any overruns in the chunk handling code?
This is where the difference between your view and mine seem to part company. I am not talking about some bug in postscript or the shell. I am talking about a program that grants remote access to run these programs in the normal manner, which is unsafe. To support the position you seem to be taking (and the one currently taken by Netscape), you would have to say that the last several Sendmail "bugs" were not sendmail problems but rather shell problems because all sendmail did was allow you to execute a shell from the remote machine (perhaps via a queue file). You would also apparently say that it's secure to allow a server to grant unlimited shell access to unknown, unauthenticated remote users. This seems foolhearty to me.
If Netscape wants to claim their product doesn't degrade security, they should provide a safe postscript interpreter or not provide hooks to unsafe ones.
Sure, and they had better find a way to keep us from editing the binary and adding whatever insecure features we may want to their program.
That's correct. Secure software has to have secure distribution in order to maintain its security when distributed through an untrusted channel. I think that Netscape uses an MD5 checksum which the members of this list seem to place unlimited trust in (incorrectly in my view, but that would be picking two nits with one keyboard entry).
obcrypto: mabie it would be a good idea for programs to list problems that are beoynd their control. To many people it may be supprising that anything in their .mailcap could hurt them. To others it is hardly a shock and seeing alot of messages about it tends to get rather boreing, esp. as a few people jump up and down and yell about the Danger To Us All...
That's not true. Certain things in their .mailcap file can create holes, but not just anything. One of the standard things we do in external audits is look for files such as this and examine their contents to see if unsafe configurations are in use. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 On Tue, 24 Oct 1995, Dr. Frederick B. Cohen wrote:
Date: Tue, 24 Oct 1995 05:29:33 -0400 (EDT) From: Dr. Frederick B. Cohen <fc@all.net>
In message <9510231413.AA26514@all.net>, Dr. Frederick B. Cohen writes:
I strongly disagree. If Netscape provided a way to execute shell commands on your host from a remote computer, it would certainly be a hole created by their product. The fact that the default shell is potentially dangerous means it's incumbant on those who provide access to it to provide adequate protection.
They do, add:
application/x-shell; sh %s
to your .mailcap.
[..rant removed..] To support the position you seem to be taking (and the one currently taken by Netscape), you would have to say that the last several Sendmail "bugs" were not sendmail problems but rather shell problems because all sendmail did was allow you to execute a shell from the remote machine (perhaps via a queue file). You would also apparently say that it's secure to allow a server to grant unlimited shell access to unknown, unauthenticated remote users. This seems foolhearty to me.
This is compleate bullshit. Equating bugs on sendmail to adding the above to your mailcap, is compleately of the wall. Why not try this: compare it to adding stupidfuck: "|/bin/sh" Obiously no one in their right mind will put the above on their aliases file. And please tell me of one MTA does check for this? You want to add to sendmail so that it checks for this? Maybe it should also check for pipes to perl, sed, awk, csh, python, ad nauseum. Now if you would understand that *people* are supposed to know what to put into their aliases file, you would understand they need to know what they have to put in their mailcap files. There is nothing a program can do about it. If you scan for certain interpreters and outlaw them, new ones will be created you dont know about. Your logic is compleatly flawled.
That's correct. Secure software has to have secure distribution in order to maintain its security when distributed through an untrusted channel. I think that Netscape uses an MD5 checksum which the members of this list seem to place unlimited trust in (incorrectly in my view, but that would be picking two nits with one keyboard entry).
Question: Does your software (your striped down http server, etc) do this? I bet not.
Aleph One / aleph1@dfw.net typed: ...
fc@all.net typed:
That's correct. Secure software has to have secure distribution in order to maintain its security when distributed through an untrusted channel. I think that Netscape uses an MD5 checksum which the members of this list seem to place unlimited trust in (incorrectly in my view, but that would be picking two nits with one keyboard entry).
Question: Does your software (your striped down http server, etc) do this? I bet not.
How much do you owe me? The differences between my secure http server and Netscape's browser are quite dramatic, so I think you deserve a fairly comprehensive answer. My get-only server cannot run outside applications, and hence does not have the vulnerability of Netscape's browser. Note also the distinction between a server and a browser. My get-only server is available in source form, is 80 lines long and thus easily understood, has been shown to meet security properties, is now in the process of being mathematically proven to meet those properties, and is published in a refereed journal which can be used to confirm its contents in detail. Hence, I do provide secure distribution through purely physical means. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
Umm, your get only server sounds like it is secure, but what is the point advertising it to this list? I could program a GET only server in far fewer than 80 lines in just a few hours. You could do it in even fewer lines of perl, or /bin/sh. A real HTTP server must support all of HTTP/1.0 however for it to be considered a server. Since yours doesn't, it isn't, it's just a toy. a better project would be to make HTTP requests under CERN more secure. In fact, if you don't handle CGI, you can't handle forms, which means you can't handle commerce securely. secure perl "get only" server server copy perl to a secure filesystem have a chroot c-wrapper there the wrapper chroot's to this directory and runs the perl script perl is effectively boxed in #!/securedir/perl $line = <STDIN>; ($method, $url, $protocol)=split(/\s+/, $line); $url =~ s/[^a-zA-Z0-9_]/g; if($method =~ /^GET/i) { open(FILE, "$url"); print "HTTP/1.0 200 OK\nContent-Type: text/html\n\n"; print <FILE>; close(FILE); } exit 0;
Umm, your get only server sounds like it is secure, but what is the point advertising it to this list?
I wasn't advertising. I was simply answering questions brought up about my secure W3 server by another person who posted to the list. For some reason they thought that they should bring it into the discussion, so I responded.
I could program a GET only server in far fewer than 80 lines in just a few hours.
As I have said many times to many others, please go ahead and do it. I only wrote the secure server to demonstrate that it was no big deal to have a secure server and to ease my own fears about protecting all.net from outside attacks like the ones with buffer overflows. The source is on-line and available to anyone, and I only ask a fee if you decide to use it for commercial purposes. Nobody has paid me yet, and I assume they never will.
You could do it in even fewer lines of perl, or /bin/sh.
But how would you demonstrate the security properties?
A real HTTP server must support all of HTTP/1.0 however for it to be considered a server.
It's a secure get-only server. It only handles 99+% of the real uses of web servers.
Since yours doesn't, it isn't, it's just a toy. a better project would be to make HTTP requests under CERN more secure.
I agree, but rather than redesign their server, I wrote my own in a few hours and made it available as an example. I think that CERN should make their server secure.
In fact, if you don't handle CGI, you can't handle forms, which means you can't handle commerce securely.
I now do handle forms (another separate 100 line server not yet released). Please see the experimental version on-line at all.net.
secure perl "get only" server server copy perl to a secure filesystem have a chroot c-wrapper there the wrapper chroot's to this directory and runs the perl script perl is effectively boxed in
My secure server includes the chroot and setUID code in it. Your C-wrapper would be part of your code - that adds several lines. And I don't need Perl which I think makes it much more secure. (There I go casting doubts on Perl security!)
#!/securedir/perl
$line = <STDIN>; ($method, $url, $protocol)=split(/\s+/, $line); $url =~ s/[^a-zA-Z0-9_]/g; if($method =~ /^GET/i) { open(FILE, "$url"); print "HTTP/1.0 200 OK\nContent-Type: text/html\n\n"; print <FILE>; close(FILE); }
exit 0;
Pretty close, but you don't provide any protection against denial of services (e.g. by openning up 1024 simultaneous sessions and leaving them open indefinately) against accessing files that aren't there (you need an error message of some sort - mine does a redirect to the home page), you don't enforce access controls on the host machine, there may be buffer overflows associated with long requests, you don't handle some possible URLs, you don't seem to handle the default URL, you don't identify the kind of error that caused the failed access, and you don't provide an audit trail. Add those and I'll look again to see if there are other possible problems. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
Fred Cohen writes:
The differences between my secure http server and Netscape's browser are quite dramatic, [snip]
No doubt about that. One's a real product, one's (primarily) a piece of puffery.
My get-only server cannot run outside applications, and hence does not have the vulnerability of Netscape's browser. Note also the distinction between a server and a browser.
Note in particular the distinction between Fred's server and a real HTTP server: It does not run CGI scripts (i.e. no forms support). It does not have per-user access control. It does not have URL mapping. It cannot redirect. All configuration is hard-coded into the binary. It doesn't support user directories (e.g. http://site/~yourname). It doesn't do server-side includes. It can't process the HEAD method. It cannot create a directory index (if no index.html is present). It does not support conditional retrieval (i.e. "If-modified-since"). It is slow (requires a separate process for each request). It is initiated by inetd for each HTTP connection and hence relies on that program's security as well (the "line-by-line analysis" of inetd is conspicuously missing from Fred's self-congratulatory whitepaper -- not to mention the OS on which it is intended to run). It does not even have the capability to identify the content type of the retrieved file (apparently you must embed "Content-type: text/html\n\n" [or whatever] at the beginning of each HTML source file). I'm not saying it's completely useless, only that it does not constitute an HTTP server in the usual sense of the word. Hence, Fred's continued boasting of this prodigious feat of programming prowess is complete bullshit. And, incidentally, the programming style, with its reliance on global fixed-length buffers, shared variables, lack of prototypes, forgotten function arguments, absence of error checking on system call returns, etc. is more suggestive of a first year CS student than an alleged PhD, *and* demonstrates a style more typical of a BASIC programmer than a C programmer. Don't try this at home, kids; this is NOT the way to write "secure" software unless your whole program fits in 80 lines too.
My get-only server is available in source form, is 80 lines long and thus easily understood, has been shown to meet security properties,
[blah blah] Big deal. It is the web equivalent of "Hello World". -- Jeff
Dr. Frederick B. Cohen wrote:
Yet it services more than one request per minute, 24 hours, 7 days, and has done so without denial of services, corruption, or leakage since its first implementation. It's so small it can be verified, it's faster than the retail brand, and it doesn't have all the holes we keep finding in tho other servers. Different strokes for different folks.
I really tried to resist but.... 1 request a minute!!!! That's a whopping 1440 a day! Try 20+ a second or over a million a day which is the current rough load which most of our servers on our site handle...(our peak day last week was 17 million hits). I don't disagree that there is value in producing a trivial server which can be guaranteed to have zero bugs (since it is so small). It, however, should be treated as an intellectual excercise. Comparing it to a production-level retail server is simply meaningless..they have different goals (as your last post emphasized)... -Jon
On Tue, 24 Oct 1995, Jon Mittelhauser wrote:
Dr. Frederick B. Cohen wrote:
Yet it services more than one request per minute, 24 hours, 7 days, and has done so without denial of services, corruption, or leakage since its
I really tried to resist but....
Thanks for saving me from the temptation but I guessed you were so taken aback by the performance claims that you missed the most amazing claim: an httpd that is proof against Denial Of Service. I'd love to know how Dr. Fred does this, since DoS is believed impossibly to defend against for unauthenticated TCP... The usual DoS attack is to send a stream of connection-initiating SYNs to the target port, and never ACK the returned SYN. This fills up the listen queue, and jams the port. As long as you can generate SYNs faster than the TCP implementation times out the older pending requests, the port is jammed (modulo a small window of, er, invunerability between one of your SYNs timing out and its replacement turning up). Ob Crypto: Has anybody thought about running Photuris over a TCP connection to do application-level key-exchange? The cookie stuff isn't really needed in this application, but it's still quite a nice wheel. Simon ----- (defun modexpt (x y n) "computes (x^y) mod n" (cond ((= y 0) 1) ((= y 1) (mod x n)) ((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n)) (t (mod (* x (modexpt x (1- y) n)) n))))
On Tue, 24 Oct 1995, Jon Mittelhauser wrote:
Dr. Frederick B. Cohen wrote:
Yet it services more than one request per minute, 24 hours, 7 days, and has done so without denial of services, corruption, or leakage since its
I really tried to resist but....
Thanks for saving me from the temptation but I guessed you were so taken aback by the performance claims that you missed the most amazing claim: an httpd that is proof against Denial Of Service. I'd love to know how Dr. Fred does this, since DoS is believed impossibly to defend against for unauthenticated TCP...
It's detailed to some extent in the on-line paper about the server.
The usual DoS attack is to send a stream of connection-initiating SYNs to the target port, and never ACK the returned SYN. This fills up the listen queue, and jams the port. As long as you can generate SYNs faster than the TCP implementation times out the older pending requests, the port is jammed (modulo a small window of, er, invunerability between one of your SYNs timing out and its replacement turning up).
Right - that's why you have to have timeouts. Unfortunately, I only prevent denial of services attacks once things hit the server. I think the TCP wrapper also has a timeout on it's request for authentication. As I said, the system is not made less secure by the server. It's very common for other http servers to start a process, lose the link to the calling host, and leave processes hung out to dry. Even without an intentional attack, servers end up with hundreds of processes hanging around after a few weeks of uptime. If you get 1024 hung channels, you have denial of services on most http implementations. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
Dr. Frederick B. Cohen wrote:
Yet it services more than one request per minute, 24 hours, 7 days, and has done so without denial of services, corruption, or leakage since its first implementation. It's so small it can be verified, it's faster than the retail brand, and it doesn't have all the holes we keep finding in tho other servers. Different strokes for different folks.
Is this the server running on port 80 of all.net? I've tried connecting to it quite a few times at various times of day and night, using netscape and telnet, and all I ever get in response to 'GET /' is a closed connection. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
Is this the server running on port 80 of all.net? I've tried connecting to it quite a few times at various times of day and night, using netscape and telnet, and all I ever get in response to 'GET /' is a closed connection.
Could it be that you are from IP addresses 198.95.250.69? If so, your firewall (or other mechanism) is presenting an incomplete falsehood about the mapping between your host name and your IP address. Oct 24 21:19:15 all in.thttpd[20865]: warning: can't verify hostname: gethostbyname(unknown.netscape.com) failed Oct 24 21:19:15 all in.thttpd[20865]: refused connect from 198.95.250.69 Oct 24 21:19:46 all in.thttpd[20919]: warning: can't verify hostname: gethostbyname(unknown.netscape.com) failed Oct 24 21:19:46 all in.thttpd[20919]: refused connect from 198.95.250.69 Oct 24 21:19:58 all in.thttpd[20945]: warning: can't verify hostname: gethostbyname(unknown.netscape.com) failed Oct 24 21:19:58 all in.thttpd[20945]: refused connect from 198.95.250.69 My server refuses connections from hosts when the IP address doesn't match to the host name. This is a common method for reducing the level of address forgery on the Internet. Please ask your firewall manager to repair the firewall so we can authenticate you. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
This is a failure in the (TCP wrappers?) that should be reconfigured. Since the service you are providing is available without any authentication, there is no reason to match hostnames to IPs with a double reverse lookup. Since your server is secure, what does it really matter where the connections are coming from? If netscape chooses to hide host information, they should be allowed to. Cypherpunk relevance? Its wrong to demand authentication when you don't care. Airports, bars, 'anonymous' FTP servers and the like should all take the level of authentication they need. Adam | If so, your firewall (or other mechanism) is presenting an incomplete | falsehood about the mapping between your host name and your IP address. | | Oct 24 21:19:15 all in.thttpd[20865]: warning: can't verify hostname: gethostbyname(unknown.netscape.com) failed | Oct 24 21:19:15 all in.thttpd[20865]: refused connect from 198.95.250.69 | My server refuses connections from hosts when the IP address doesn't | match to the host name. This is a common method for reducing the level | of address forgery on the Internet. Please ask your firewall manager to | repair the firewall so we can authenticate you. -- "It is seldom that liberty of any kind is lost all at once." -Hume
I must disagre here and side with *gasp* FC. If your so called *secure* server happens to get broken into by grace of god, you want to know at least where the attack came from. If Netscape wants to hide internet hostnames they would to well setting up to DNS servers, one for internal resolutions where IPs resolve to their real hostname, and one in front of the firewall that resolves all IP's to unkown.netscape.com. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 On Wed, 25 Oct 1995, Adam Shostack wrote:
This is a failure in the (TCP wrappers?) that should be reconfigured.
Since the service you are providing is available without any authentication, there is no reason to match hostnames to IPs with a double reverse lookup.
Since your server is secure, what does it really matter where the connections are coming from? If netscape chooses to hide host information, they should be allowed to.
Cypherpunk relevance? Its wrong to demand authentication when you don't care. Airports, bars, 'anonymous' FTP servers and the like should all take the level of authentication they need.
Adam
This is a failure in the (TCP wrappers?) that should be reconfigured.
That's a policy decision, not a technical one. The policy I have decided to follow is that I don't support people with non-authenticable IP addresses. I feel it is in the best interest of the Internet and of the organizations using the Internet (like Netscape) that I prevent people from claiming to be from Netscape with possibly forged IP addresses. You should feel free to make your policy decisions as you feel best, while I certainly exercize that freedom on my end.
Since the service you are providing is available without any authentication, there is no reason to match hostnames to IPs with a double reverse lookup.
That's not right. My service requires authentication in the sense of not allowing obviously forged IP addresses. The audit trails generated by the process allow me to my services, send mail (when people use the ident daemon) about improvements. For example, there was an inaccessible file due to an error on my part - my automated error detection system popped the error up on the screen within a few seconds, I investigated, fixed the proteciton setting, and sent email to the person letting them know that the file was now accessible and that it way my fault. This is also used as part of the identification process used to assure that information is not sent to locations where I am aware it is illegal to send it. For example, Singapore has restrictions that make it illegal to send them certain things, and I check for their addresses as part of my access controls - made feasible via the IP address verification process.
Since your server is secure, what does it really matter where the connections are coming from? If netscape chooses to hide host information, they should be allowed to.
Because secure means more than "you can't harm me by using it". It implies integrity, availability, confidentiality, and redundancy to provide assurance that those things are the case. It implies not only keeping my site from being attacked, but trying to obey the laws of countries from all over the world, keeping my site from being use to attack other sites, limiting legal liabilities, and on and on. If someone choses to use a non-verifiable network address, I choose to not provide services.
Cypherpunk relevance? Its wrong to demand authentication when you don't care. Airports, bars, 'anonymous' FTP servers and the like should all take the level of authentication they need.
It's wrong to make assumptions about what I care about when you haven't asked me. I care about you and everyone else using the Internet. I care enough to help prevent forgeries by not supporting them, and to help people debug their (perhaps faulty) firewalls by identifying the source of problems and helping them resolve them. I think that authentication at some level is appropriate for anyone who uses computers, even anonymously. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
Fred Cohen writes:
The differences between my secure http server and Netscape's browser are quite dramatic, [snip]
No doubt about that. One's a real product, one's (primarily) a piece of puffery.
A secure get-only server for those of us who want security and the normal functions required by most Web users most of the time.
My get-only server cannot run outside applications, and hence does not have the vulnerability of Netscape's browser. Note also the distinction between a server and a browser.
Note in particular the distinction between Fred's server and a real HTTP server: It does not run CGI scripts (i.e. no forms support).
That certainly increases the security. Actually, we are now experimenting with an execution server that allows some level of security while running executables - have you tried using our secure forms interface? Probably not.
It does not have per-user access control.
Actually, it uses TCP wrappers, which provides a different sort of access control.
It does not have URL mapping.
It is a secure, get-only server - as advertised.
It cannot redirect.
Actually, it does redirect, but not in the way you are used to.
All configuration is hard-coded into the binary.
That's one of the ways it is made secure. If you want to change configurations, you have to recompile. Otherwise, dangerous config changes can easily be made - that would be risky.
It doesn't support user directories (e.g. http://site/~yourname).
It doesn't allow access to the whole file system, thus gaining additional protection from configuration errors, misuse, mismanagement, etc.
It doesn't do server-side includes.
Get only - that's what it claims and that's what it does.
It can't process the HEAD method.
Get only - that's what it claims and that's what it does.
It cannot create a directory index (if no index.html is present).
Get only - that's what it claims and that's what it does.
It does not support conditional retrieval (i.e. "If-modified-since").
Get only - that's what it claims and that's what it does.
It is slow (requires a separate process for each request).
Actually, it's faster (I've clocked it) than the NCSA server.
It is initiated by inetd for each HTTP connection and hence relies on that program's security as well (the "line-by-line analysis" of inetd is conspicuously missing from Fred's self-congratulatory whitepaper -- not to mention the OS on which it is intended to run).
The claim is that it does not weaken the security provided by the operating system. Nothing else.
It does not even have the capability to identify the content type of the retrieved file (apparently you must embed "Content-type: text/html\n\n" [or whatever] at the beginning of each HTML source file).
Get only - that's what it claims and that's what it does.
I'm not saying it's completely useless, only that it does not constitute an HTTP server in the usual sense of the word.
Right. It's a SECURE get only http server. The usual sense of the word means insecure.
Hence, Fred's continued boasting of this prodigious feat of programming prowess is complete bullshit.
I never boasted it was a prodigious feat at all. In fact, I published the fact that it was written in a few hours because I got tired of worying about and fixing the insecure servers available over the net. It is in the process of being proven to meet the security requirements, which is a prodigous feat (and which I am not doing).
And, incidentally, the programming style, with its reliance on global fixed-length buffers, shared variables, lack of prototypes, forgotten function arguments,
Actually, not true. The global fixed-length buffers, shared variables, and lack of prototypes provide protection against allocation problems which sould result in denial of service, corruptions at near-capacity load, and other similar security problems.
absence of error checking on system call returns,
The error checking on system call returns is quite thorough for the purposes required. Where no check is done, it is because the check is not required.
etc. is more suggestive of a first year CS student than an alleged PhD, *and* demonstrates a style more typical of a BASIC programmer than a C programmer.
I realize now that you think that all Ph.D.s program like you do, but in this case, the style of the program is intended to meet the requirement of the task. Unlike many who learned in the "structured programming" method, I believe that different program requirements call for different programming styles. This program is in a style suited to the requirements which include, among other things, verifiability, small size, ease of unsderstanding, controls on the flow of information, integrity, availability, confidentiality, and redundancy. But at any rate, there's no accounting for taste.
Don't try this at home, kids; this is NOT the way to write "secure" software unless your whole program fits in 80 lines too.
If it doesn't, it's probably going to be very hard to demonstrate security.
My get-only server is available in source form, is 80 lines long and thus easily understood, has been shown to meet security properties,
[blah blah]
Big deal. It is the web equivalent of "Hello World".
Yet it services more than one request per minute, 24 hours, 7 days, and has done so without denial of services, corruption, or leakage since its first implementation. It's so small it can be verified, it's faster than the retail brand, and it doesn't have all the holes we keep finding in tho other servers. Different strokes for different folks. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
On Tue, 24 Oct 1995, Dr. Frederick B. Cohen wrote:
Actually, not true. The global fixed-length buffers, shared variables, and lack of prototypes provide protection against allocation problems which sould result in denial of service, corruptions at near-capacity load, and other similar security problems.
Please explain how a lack of prototypes (and shared variables for that matter) provide protection against the problems you describe. - Andy
On Tue, 24 Oct 1995, Dr. Frederick B. Cohen wrote:
Actually, not true. The global fixed-length buffers, shared variables, and lack of prototypes provide protection against allocation problems which sould result in denial of service, corruptions at near-capacity load, and other similar security problems.
Please explain how a lack of prototypes (and shared variables for that matter) provide protection against the problems you describe.
The design of the server is documented in a white paper stored in our W3 server. Look under the URL below and select: Management Analytics -> Software -> Daemons -> White Paper -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
Dr. Frederick B. Cohen writes:
If Netscape wants to claim their product doesn't degrade security, they should provide a safe postscript interpreter or not provide hooks to unsafe ones.
By the same logic, it might be claimed: "If Netscape wants to claim their product doesn't degrade security, they should provide a safe Internet or not provide access to unsafe Internet sites." I disagree. And yes, I'm arguing in my spare time. -Futplex <futplex@pseudonym.com>
-----BEGIN PGP SIGNED MESSAGE----- Alice de 'nonymous keeps on going. Hey, Alice... either post an EXPLOIT using this supposed hole or SHUT UP! - -- Roy M. Silvernail -- roy@cybrspc.mn.org "I used to be disgusted, but now I'm just amused." -- from an old T-shirt(ca. 1975), not an Elvis Costello lyric -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMIuHXxvikii9febJAQF3XQQAnhkpoyPSuDxrBgl3LlpC9oeXXs0j6AHi Vd5CX7cvF6lSd9aMPVfa/3hzDz6aMawEnXURRTfzsnhMb7B+Y0VvC8D+rqXKE5jb Doma3efaYYr8oi8xism0P8BASwabP2kUnGjBXdrg5PteiRfihh0SBCcj7u3klsI5 hEuOQAI9uO4= =3xvF -----END PGP SIGNATURE-----
participants (20)
-
Adam Shostack -
Aleph One -
Andy Brown -
anonymous-remailer＠shell.portal.com -
fc＠all.net -
futplex＠pseudonym.com -
hallam＠w3.org -
Jeff Barber -
Jeff Weinstein -
Jon Mittelhauser -
Josh M. Osborne -
Laurent Demailly -
Mark -
Matt Blaze -
Nesta Stubbs -
Perry E. Metzger -
Ray Cromwell -
roy＠cybrspc.mn.org -
sameer -
Simon Spero