Re: Protocol implementation errors
On Sat, Oct 04, 2003 at 05:58:49PM +1200, Peter Gutmann wrote: Bill Frantz [EMAIL PROTECTED] writes: This is the second significant problem I have seen in applications that use ASN.1 data formats. (The first was in a widely deployed implementation of SNMP.) Given that good, security conscience programmers have difficultly getting ASN.1 parsing right, we should favor protocols that use easier to parse data formats. I think this leaves us with SSH. Are there others? I would say the exact opposite: ASN.1 data, because of its TLV encoding, is self-describing (c.f. RPC with XDR), which means that it can be submitted to a static checker that will guarantee that the ASN.1 is well-formed. In other words it's possible to employ a simple firewall for ASN.1 that isn't possible for many other formats (PGP, SSL, ssh, etc etc). This is exactly what cryptlib does, I'd be extremely surprised if anything could get past that. Conversely, of all the PDU-parsing code I've written, the stuff that I worry about most is that which handles the ad-hoc (a byte here, a unit32 there, a string there, ...) formats of PGP, SSH, and SSL. We've already seen half the SSH implementations in existence taken out by the SSH malformed-packet vulnerabilities, I don't think so. The SSH packet format is _much_ simpler than ASN.1 and neither the original ssh-1.x nor OpenSSH had problems due to the packet parsing, both have been immune to last years malformed packet tests. I've seen more problems related to ASN.1 parsing than to SSH packet parsing... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protocol implementation errors
Markus Friedl [EMAIL PROTECTED] writes: On Sat, Oct 04, 2003 at 05:58:49PM +1200, Peter Gutmann wrote: We've already seen half the SSH implementations in existence taken out by the SSH malformed-packet vulnerabilities, I don't think so. According to the CERT advisory, roughly half of all known SSH implementations are vulnerable (some of the vendor statements are a bit ambiguous), and the number would have been higher if it weren't for the fact that several of the non-vulnerable implementations share the OpenSSH code base (there are a number of implementations not in the advisory, but we can take it as being a representative sample). The reason I appear to be defending ASN.1 here is that there seems to be an irrational opposition to it from some quarters (I've had people who wouldn't recognise ASN.1 if they fell over it tell me with complete conviction that it's evil and has to be eradicated because... well just because). I don't really care about the religious debate one way or the other, I'm just stating that from having used almost all of the bit-bagging formats (starting with PGP 1.0) for quite a number of years, ASN.1 is the one I feel the most comfortable with in terms of being able to process it safely. Incidentally, if anyone wants to look for holes in ASN.1 data in the future, I'd be really interested in seeing what you can do with malformed X.509 and S/MIME data. Peter (who's going to look really embarrassed if the NISCC test suite finds problems in his ASN.1 code :-). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [e-lang] Re: Protocol implementation errors
At 02:41 PM 10/5/2003 Sunday, Tyler Close wrote: On Sunday 05 October 2003 11:03, Jonathan S. Shapiro wrote: Peter: I agree that ASN.1 is statically checkable, and that this is an important property. What exactly does it mean for a format to be statically checkable? Peter's statement was: At 10:58 PM 10/3/2003 Friday, Peter Gutmann wrote: I would say the exact opposite: ASN.1 data, because of its TLV encoding, is self-describing (c.f. RPC with XDR), which means that it can be submitted to a static checker that will guarantee that the ASN.1 is well-formed. In other words it's possible to employ a simple firewall for ASN.1 that isn't possible for many other formats (PGP, SSL, ssh, etc etc). This is exactly what cryptlib does, I'd be extremely surprised if anything could get past that. Conversely, of all the PDU-parsing code I've written, the stuff that I worry about most is that which handles the ad-hoc (a byte here, a unit32 there, a string there, ...) formats of PGP, SSH, and SSL. We've already seen half the SSH implementations in existence taken out by the SSH malformed-packet vulnerabilities, I can trivially crash programs like pgpdump (my standard PGP analysis tool) with malformed PGP packets (I've also crashed quite a number of SSH clients with malformed packets while fiddling with my SSH server code), and I'm just waiting for someone to do the same thing with SSL packets. In terms of safe PDU formats, ASN.1 is the best one to work with in terms of spotting problems. Shap wrote: However, ASN.1 is notoriously hard to parse, which leads to errors. I do wonder if we shouldn't design a format that captures the best of both worlds... Tyler wrote: Does the Waterken Doc code format capture the best of both worlds? See: http://www.waterken.com/dev/Doc/code/ If I understand Peter's statement, the answer is yes for Doc, S-Expressions, Term trees, XML, Java serialization streams, and many other formats; both textual and binary. As for Corba IIOP and the CapIDL serialization format, only if the interface definition is included. Otherwise, I don't think these are self-describing in the sense Peter means. Text by me above is hereby placed in the public domain Cheers, --MarkM - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protocol implementation errors
Jerrold Leichter [EMAIL PROTECTED] writes: Both of these are helped by a well-specified low-level syntax. TLV encoding lets you cross-check all sorts of stuff automatically, once, in low-level calls. Ad hoc protocols scatter the validation all over the place - and some of it will inevitably be overlooked. Yup, and that's exactly what makes me so nervous about the ad hoc formats. Having had the experience of writing parsers for every major format used in crypto (oh, except IPsec, but that falls into the same class as PGP/SSH/SSL) and ranking things in the order in which I'd expect problems to occur, I get: ASN.1: Pretty much bulletproof, you should be able to throw anything at that code and it'll just bounce off (I should be able to run the recent malformed-ASN.1 attacks that hit OpenSSL on it within the next few days, but I'd expect all of those to be caught by the firewall and not even get to the actual ASN.1 code). Ad hoc formats (PGP, SSH, SSL): Should be OK because I apply anal-retentive amounts of checking everywhere and have done probably a dozen full audits of the code, but I'm still not fully confident about it (it did withstand the malformed-SSH-message weaknesses from a few months ago though). Text formats (XML): Full of arbitrarily-complex messages, variable-length encodings, special-case escape sequences, and other horrors, and that's without even thinking about the nightmare added by XSLT, XPath, DTDs, style sheets, XML namespace problems, and who knows what else. If anything goes wrong, it'll be in there. I can't even imagine how you could produce a truly safe parser for that stuff. While I'm not madly in love with ASN.1, in terms of safe data formats it's the one I feel most comfortable with. Jonathan S. Shapiro [EMAIL PROTECTED] writes: I agree that ASN.1 is statically checkable, and that this is an important property. However, ASN.1 is notoriously hard to parse, which leads to errors. ASN.1 has a *reputation* of being notoriously hard to parse, gained chiefly from some early bad experiences with OSI work (which would give anything a reputation of being hard to work with :-). I've implemented, and I know of others who have implemented, extremely compact and portable ASN.1 libraries. My ASN.1 library is about the same level of complexity as the PGP and SSH libraries, so the bit-bagging scheme being used has little to do with it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [e-lang] Protocol implementation errors
On Thursday, Oct 2, 2003, at 17:50 US/Eastern, Bill Frantz wrote:
From:
-- Security Alert Consensus --
Number 039 (03.39)
Thursday, October 2, 2003
Network Computing and the SANS Institute
Powered by Neohapsis
*** {03.39.004} Cross - OpenSSL ASN.1 parsing vulns
OpenSSL versions 0.9.6j and 0.9.7b (as well as prior) contain multiple
bugs in the parsing of ASN.1 data, leading to denials of services. The
execution of arbitrary code is not yet confirmed, but it has not been
ruled out.
This is the second significant problem I have seen in applications
that use
ASN.1 data formats. (The first was in a widely deployed
implementation of
SNMP.) Given that good, security conscience programmers have
difficultly
getting ASN.1 parsing right, we should favor protocols that use easier
to
parse data formats.
This is a little too anecdotal for my taste. When it comes to security
I think we can safely ignore anything SNMP. The OpenSSL crew didn't
(doesn't?) even have an exhaustive test-suite for their DER parsers
which I believe to be a requirement when a security requirement is on
the table.
I think this leaves us with SSH. Are there others?
While I like the SSH2 protocol because of its simplicity, it forces one
to use ad-hoc approaches for anything more complex than single-level
product types. Sum types are not supported at all, apart from those
offered as primitives, and have to be (are) handcrafted in some ad-hoc
fashion.
The implementation language seems to be more of a problem than the
actual data representation formats. I have found that typed high-level
(declarative) languages supporting sum/product types with pattern
matching provide near bullet-proof framework for safely marshalling
data of arbitrary complexity. The compiler will statically check that
all corner cases are handled. If it compiles, it tends to be correct.
And creating the corresponding proof is straightforward.
If one is really lucky, one's language supports polytypic programming,
in which case a single algorithm can marshall arbitrary data structures
correctly:
http://www.math.chalmers.se/~patrikj/poly/dc/
The bottom line is that these problems occur because presently
programmers are required to perform a compiler's job. Just like
persistence bugs occurs because programmers are forced to do what
should be the platform's responsibility (c.f. KeyKOS/EROS persistence).
When language support is not feasible, parser generators can go a long
way towards eliminating parser bugs.
Cheers,
-J
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protocol implementation errors
| This is the second significant problem I have seen in applications that use | ASN.1 data formats. (The first was in a widely deployed implementation of | SNMP.) Given that good, security conscience programmers have difficultly | getting ASN.1 parsing right, we should favor protocols that use easier to | parse data formats. | | I think this leaves us with SSH. Are there others? | | I would say the exact opposite: ASN.1 data, because of its TLV encoding, is | self-describing (c.f. RPC with XDR), which means that it can be submitted to a | static checker that will guarantee that the ASN.1 is well-formed. In other | words it's possible to employ a simple firewall for ASN.1 that isn't possible | for many other formats (PGP, SSL, ssh, etc etc). This is exactly what | cryptlib does, I'd be extremely surprised if anything could get past that. | Conversely, of all the PDU-parsing code I've written, the stuff that I worry | about most is that which handles the ad-hoc (a byte here, a unit32 there, a | string there, ...) formats of PGP, SSH, and SSL. We've already seen half the | SSH implementations in existence taken out by the SSH malformed-packet | vulnerabilities, I can trivially crash programs like pgpdump (my standard PGP | analysis tool) with malformed PGP packets (I've also crashed quite a number of | SSH clients with malformed packets while fiddling with my SSH server code), | and I'm just waiting for someone to do the same thing with SSL packets. In | terms of safe PDU formats, ASN.1 is the best one to work with in terms of | spotting problems. I think there's a bit more to it. Properly implementing demarshalling code - which is what we are really talking about here - is an art. It requires an obsessive devotion to detailed checking of *everything*. It also requires a level and style of testing that few people want to deal with. Both of these are helped by a well-specified low-level syntax. TLV encoding lets you cross-check all sorts of stuff automatically, once, in low-level calls. Ad hoc protocols scatter the validation all over the place - and some of it will inevitably be overlooked. A couple of years back, the place I work decided to implement its own SNMP library. (SNMP is defined in ASN.1) We'd been using the same free library done at, I think, UC San Diego many years before, and were unhappy with many aspects of it. The guy we had do it had the right approach. Not only did he structure the code to carefully track and test all suspect data, but he also wrote a test suite that checked: - Many valid inputs. Most people stop here: It gets the right results on valid data, who cares about the rest. - Many expectable forms of invalid data. A few people will write a few of these tests. Usually, they write test cases that match the error paths they thought to include in their code. Fine, but not nearly enough. - Many randomly-generated tests. The trick here is to shape the randomness: Most completely random bit strings will be rejected at very low levels in the code. What you want are strings that look valid enough to pass through multiple layers of testing but contain random junk - still with some bias, e.g., 1 too high or too low is a test you want to bias toward. Hardly anyone does this. The proof of the pudding came a couple of years later, when a group a OUSPG (Oulu University Secdure Computing Group) came up with a test that ripped through just about everyone's SNMP suites, leading to a CERT advisory and a grand panic. Our stuff passed with no problems, and in fact when we looked at OUSPG's test cases, we found that we had almost certainly run them all in some form or another already, since they were either in our fixed test list or were covered by the randomized testing. OUSPG's efforts were actually directed toward something more on point to this discussion, however: Their interest is in protocol test generation, and their test cases were generated automatically from the SNMP definitions. This kind of thing is only possible when you have a formal, machine-readable definition of your protocol. Using ASN.1 forces you to have that. (Obviously, you can do that without ASN.1, but all too often, the only definition of the protocol is the code. In that case, the only alternative is manual test generation - but it can be so hard to do that it just doesn't get done.) BTW, the OUSPG saga is another demonstration of the danger of a monoculture. There are, it turns out, vey few independent implementations of SNMP around. Just about everyone buys SNMP support from SNMP Research, which I believe sells a commercialized version of the old UCSD code. Find a bug in that, and you've found a bug in just about every router and switch on the planet.
Re: Protocol implementation errors
Bill Frantz [EMAIL PROTECTED] writes: This is the second significant problem I have seen in applications that use ASN.1 data formats. (The first was in a widely deployed implementation of SNMP.) Given that good, security conscience programmers have difficultly getting ASN.1 parsing right, we should favor protocols that use easier to parse data formats. I think this leaves us with SSH. Are there others? I would say the exact opposite: ASN.1 data, because of its TLV encoding, is self-describing (c.f. RPC with XDR), which means that it can be submitted to a static checker that will guarantee that the ASN.1 is well-formed. In other words it's possible to employ a simple firewall for ASN.1 that isn't possible for many other formats (PGP, SSL, ssh, etc etc). This is exactly what cryptlib does, I'd be extremely surprised if anything could get past that. Conversely, of all the PDU-parsing code I've written, the stuff that I worry about most is that which handles the ad-hoc (a byte here, a unit32 there, a string there, ...) formats of PGP, SSH, and SSL. We've already seen half the SSH implementations in existence taken out by the SSH malformed-packet vulnerabilities, I can trivially crash programs like pgpdump (my standard PGP analysis tool) with malformed PGP packets (I've also crashed quite a number of SSH clients with malformed packets while fiddling with my SSH server code), and I'm just waiting for someone to do the same thing with SSL packets. In terms of safe PDU formats, ASN.1 is the best one to work with in terms of spotting problems. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Protocol implementation errors
From:
-- Security Alert Consensus --
Number 039 (03.39)
Thursday, October 2, 2003
Network Computing and the SANS Institute
Powered by Neohapsis
*** {03.39.004} Cross - OpenSSL ASN.1 parsing vulns
OpenSSL versions 0.9.6j and 0.9.7b (as well as prior) contain multiple
bugs in the parsing of ASN.1 data, leading to denials of services. The
execution of arbitrary code is not yet confirmed, but it has not been
ruled out.
This is the second significant problem I have seen in applications that use
ASN.1 data formats. (The first was in a widely deployed implementation of
SNMP.) Given that good, security conscience programmers have difficultly
getting ASN.1 parsing right, we should favor protocols that use easier to
parse data formats.
I think this leaves us with SSH. Are there others?
Cheers - Bill
-
Bill Frantz| There's nothing so clear as | Periwinkle
(408)356-8506 | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
