This is a discussion on Re: [fw-wiz] How automate firewall tests - Firewalls ; 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 ...
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:
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: email@example.com
> [mailto:firstname.lastname@example.org] 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
> > protocols.
> > 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
> > protocols
> > 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