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