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

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...

> 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

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

> 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 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

> 	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

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

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

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

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. 

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

>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>

...
> 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

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

<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

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

Dr. Frederick B. Cohen writes:
> > Mr. Anonymous has a good reason to be anonymous -- he's an annoying
> 
> Perhaps.
> 
> > fool.
> 
> I don't agree.

Could that be because his style and yours are rather similar? I
haven't had an opportunity to compare word statistics yet...

.pm

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>

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-

-----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-----