What could have been done differently?

Wed Jan 29 17:03:34 UTC 2003

On Tue, 28 Jan 2003, Scott Francis wrote:

> I'm still looking for a copy of the presentation, but I was able to find a
> slightly older rant he wrote that contains many of the same points:
> http://www.bsdatwork.com/reviews.php?op=showcontent&id=2

> Good reading, even if it's not very much practical help at this moment. :)

I'm reminding of the two men that were sent out to chop a whole lot of
wood. One judged the amount of work and immediately started, chopping
away until dark. The other stopped to sharpen his blade from time to
time. Despite the fact he lost valuable chopping time this way, he was
home in time for dinner.

> > Another thing that could help is have software ask permission from some
> > central authority before it gets to do dangerous things such as run
> > services on UDP port 1434. The central authority can then keep track of
> > what's going on and revoke permissions when it turns out the server
> > software is insecure. Essentially, we should firewall on software
> > versions as well as on traditional TCP/IP variables.

> The problem there is the same as with windowsupdate - if one can spoof the
> central authority, one instantly gains unrestricted access to not one, but
> myriad computers.

I din't mean quite that central, but rather one or two of these boxes
for a small-to-medium sized organization. If there are different
servers authenticating and authorizing users on the one hand and
software/network services on the other hand, an attacker would have to
compromize both: the network aaa box to bypass the firewalls, and the
user aaa box to actually log on.

> > It would proably a good thing if the IETF could
> > build a good protocol parsing library so implementors don't have to do
> > this "by hand" and skip over all that pesky bounds checking. Generating
> > and parsing headers for a new protocol would then no longer require new
> > code, but could be done by defining a template of some sort.

> It's the trust issue, again - trust is required at some point in most
> security models.

This isn't a matter of trust, but a matter of well-designed and
well-tested software. If the RFC Editor publishes and RFC with the C
example code for a generic protocol handler library, this code will have
seen a lot of review, especially if people intend to actually use this
code in their products. Since this code will be so important and not
all that big, a formal correctness proof may be possible.