Re: [fw-wiz] How automate firewall tests

The previous message suggested that formal grammars would make it easier to
define and model a network protocol to make it more secure. My example of ASN.1
is of exactly a formal grammar used to define and model a network protocol. It
is a grammar for a much simpler "language" than most Internet protocols, so one
would expect that the interpreters for it should be more likely to be proven
correct than more general ones like HTTP.
The Mitre CVE set has 22 ASN.1 vulnerabilities or candidates since 2004. These
have been very significant ones that have crossed multiple operating systems and
caused some harm.

Writing secure software, even with a formal mechanism for defining what one
wants, is still a very hard problem.

Since most firewall rules are tuplets of form:
<allow|deny, source location set, destination location set,services,times>,

perhaps formal set theory might help in enumerating the effect of firewall
One could find the transitive closure of these rules using graph theory
algorithms to reach a summary of the effective firewall rule set. This would
make a nice Ph.D. thesis for someone.

-----Original Message-----
From: firewall-wizards-bounces@xxxxxxxxxxxxxxxxxxxxx
[mailto:firewall-wizards-bounces@xxxxxxxxxxxxxxxxxxxxx] On
Behalf Of Chuck Swiger
Sent: Monday, August 21, 2006 7:56 PM
To: Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] How automate firewall tests

On Aug 21, 2006, at 3:51 PM, Bill Royds wrote:
ASN.1 is a formal language to describe data structures for
use of a
number of


One would expect that protocols that use ASN.1 as their structure
grammar should be quite secure.

How does this follow?

I would expect that using ASN.1 would make it easier to validate
whether a protocol statement is grammatical, and make it easier to
write a sane LR(0,1) or LALR(1) parser for it, but that doesn't mean
that J. Random Hacker isn't going to roll their own parser and maybe
allocate a 1024-byte buffer which can be over-run regardless. Good
specification != good implementation.

This also says nothing about whether the protocol has paid any
attention to security. Just because something parses, doesn't mean
it makes sense or that the application should answer the query
without considering whether the request is legit and properly
authorized. In particular, people very rarely define security
policies or access rules within the grammar of a protocol, with the
notable exception of firewall ruleset languages like PF, IPFW,
Cisco's IOS, etc....

But there have probably been more vulnerabilities in ASN.1 based
than any other. SO even a formal grammar is probably not good
enough to define
"correct" input.

What are you counting, here? :-)


firewall-wizards mailing list