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.