RE: A fun smackdown...

["Marcus J. Ranum" <mjr () ranum com>]

Bill Royds wrote:
>  But RFC's don't have true descriptions of the protocol that they are supposed
> to be describing.  More than anything, they are basically descriptions of what
> they want the protocol to do, but not descriptions of exactly what the syntax
> and semantics of the protocol should be.

As you've probably noticed, I think that coding to the RFCs is not
the right approach. :) The description of the syntax and operations
of the protocols is usually more broad than the actual implementations
that get fielded. For example, I don't know of *any* SMTP clients that
issue a "HELP" command as part of their normal operation. So if
you don't support it you don't run into the potential SMTP HELP
command attack; it simply does not exist. This is the notion of
minimization applied to command-sets, and it's a good thing.
Effectively, it strips your application protocols down to the minimal
subset that are actually needed in order to get the job done.
Well, if they get the job done, screw the rest.

Back in the day, a lot of us used to make fun of the sendmail
MTA for being bloated and, by extension, full of security holes.
Back in 1990, sendmail was 17,362 lines of code and we
considered it dangerously large. Steve Bellovin used to call
it "sendwhale" ;)  - and a lot of us switched to Wietse
Venema's postfix MTA. Well, today, in 2005, postfix is 299,545
lines of code, and sendmail is 220,263. Postfix is still better,
because it was designed as cooperating processes to
separate security critical processing away from non-privileged
processing. But what's going on? ESMTP is part of it.
That extra functionality, whatever it is, is responsible for a
lot of bloat.

Now, of course, you can't implement a firewall anymore
that doesn't do ESMTP. Customers would complain.
But if your firewall didn't implement ESMTP I predict
that a day would come when you'd be laughing at all
the poor bastards who were getting screwed with some
ESMTP-specific flaw in their systems.

I haven't dug into the topic with Wietse but I suspect
that he read the RFC when he implemented the extensions
to postfix. So, in order to be compatible, he had to implement
a bunch of stuff that I bet some clients don't use at all,
and isn't necessary. Seldom-used code is a recipe for
disaster. That's where the next "arrggh!!" comes from.

In Marcus-land (which we can all agree is a very weird
place) the right way to do this is to implement a gateway
that accepts only the ESMTP commands that are
actually used in operational deployments. So, when
someone writes a new client that tries to exercise
the FNART command, the gateway logs an error
and refuses. Then, the gateway designer can sit down
and look at what the FNART command does and decide
whether or not to implement it, and what can be done
to apply logging, error and boundary checking to it.
Yeah, yeah, some "legitimate" traffic doesn't get through
for a little while. But if FNART turns out to be used and
useful, then it gets implemented safely with appropriate
controls, and everyone's happy.

> It would be almost impossible to write
> a proxy that took a grammar and verified the validity of a stream purporting to
> follow that proxy. You have to do what Marcus did with the DEC Seal/ Gauntlet
> and others, write proxy for a subset of a protocol that validates the semantics
> that the author feels to be somewhat securable and still useful.

When I did the SEAL and Gauntlet proxies I designed them
around the actual client-side implementations that were fielded
at the time. I never read the RFCs. (I still don't except for if I need
a laugh. Check the introduction of RFC 3164 - syslog - if you want
an example of the blithering stupid bullsh*t that finds its way
into IETF's RFC process)  I tested the gateway against every
client I could get my hands on and was surprised to discover
that most of them did a very small set of the total protocol
in order to get the job done.

If you can get the job done with a subset of the total protocol,
why is the other stuff there? It's baggage. Lose it.

>  But that is also why the Internet based on TCP/IP has been so successful. It
> is defined "close enough" so different manufacturers of hardware and software
> can create different products operate somewhat together so that there is plenty
> of choice of both hardware that will work over the Internet.

The problem with "close enough" is that it makes it
really hard to detect improper variants of protocols.
Unfortunately, that means a lot of hacks are going
to slip by under the radar screen.

> Lack of security is
> what made TCP/IP survive ahead of things like X-25

Lack of licensing/royalty is what did it, not lack of security.

The early Internet is a terrific case study of how free crufty garbage
will usually destroy well-designed stuff that costs something.
That's a dynamic that's playing itself out again as Linux
(free crufty garbage) is dooming Sun/Solaris and commercial
UNIX (well-designed and maintained stuff that costs $$) to
eventual extinction.

What short-sighted customers don't understand is that relying
on garbage is more expensive in the long run. By the time
you've bought all the duct tape, baling wire, and glue that
is necessary to make all the garbage appear somewhat
reliable, you could have actually afforded something that
didn't suck in the first place... 

mjr.  

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards