Re: [e-lang] Re: Protocol implementation errors
At 5:36 PM -0700 10/5/03, Norman Hardy wrote: >I can't recall Keykos security problems stemming from hostile message >strings in a key invocation. >I don't know why. Perhaps we always expected hostile messages as a >cultural thing. I think there were several additional reasons for this: * Most of the strings passed were very simple, consisting of just one string. We didn't get much more complex than, for example, the record collection (which used byte string names to look up data and capabilities). Its string was: * 1 byte - length of name * n byte (0-255) name * the rest data. * We did not try to handle "infinite length" strings. In general, strings were limited to 4096 bytes. * We were programming in 370 assembler, which, IMHO, is better suited to writing secure code than C. For example, the string copy primitive in C is strcpy, where the source string determines the length. In 370 assembler, the primitive is MVCL (move long) which takes 5 parameters, the source address and length, the destination address and length, and the fill character. Having to specify those 5 parameters made the issues involved in a string copy very obvious each time one was coded. * We did not, as a general rule, have a stack. As a result, it was less likely to have program control data (return addresses) and buffers next to each other, where a buffer overrun could result in both hostile code, and the necessary changes to the program control data to pass control to it. At 10:58 PM -0700 10/3/03, 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. I think Peter has convinced me that ASN.1 (by which I mean DER specifically, since that is the form that the run-time code parses), is probably not a whole lot worse than the other formats (which also have shown significant parsing bugs). While some of the problems come from the details of the format, most probably come from the complex data structures that are part of the problem space. Given that this is a correct assessment, then we need to think of ways to protect ourselves against the programs that parse these data. If we were coding in KeyKOS or EROS, I would put the parsing code in a separate domain. To protect against denial of service that domain would have a limited space bank, a keeper, and a timeout to signal parse failure to the caller. To guard against attack, that domain would only have capabilities to: * The input string and/or the input byte stream * "No hole" creators for the output objects. Further protection can be built by limiting the privilege of the domains that use these output objects. (Note that the cost of a domain call is very small compared with the cost of a public key operation.) I don't really know how to apply this approach to a UNIX like system. I think for these systems, it might be best to write the parsing code in a "safe" language such as Java, Smalltalk, E, Scheme etc. That would result in an additional layer of protection from the runtime. If the cost of calling into and return from the language is small enough, the extra cost of the language should be tolerable. (Having to fire up a Java Virtual Machine each time could make public key operations look fast.) Cheers - Bill - Bill Frantz| "There's nothing so clear as a | Periwinkle (408)356-8506 | vague idea you haven't written | 16345 Englewood Ave www.pwpconsult.com | down yet." -- Dean Tribble | Los Gatos, CA 95032 ___ e-lang mailing list [EMAIL PROTECTED] http://www.eros-os.org/mailman/listinfo/e-lang - Bill Frantz| "There's nothing so clear as a | Periwinkle (408)356-8506 | vague idea you haven't written | 16345 Englew
Re: [e-lang] Re: Protocol implementation errors
Peter Gutmann wrote: > Ben Laurie <[EMAIL PROTECTED]> writes: > >>Peter Gutmann wrote: >> >>>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. >> >>Do you really mean ASN.1 or do you mean DER/BER? > > > Sorry, I meant BER/DER data, not the ASN.1 source text. In which case, I should comment that most of the bad reputation I'm aware of has to do with the difficultly of parsing ASN.1 source, and so people end up implementing the mapping by hand, and so get it wrong. Which is why X.509 is a nice theory, but don't even think about unpacking and repacking a cert and having it still work. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - 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: 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: [e-lang] Re: Protocol implementation errors
Ben Laurie <[EMAIL PROTECTED]> writes: >Peter Gutmann wrote: >>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. > >Do you really mean ASN.1 or do you mean DER/BER? Sorry, I meant BER/DER data, not the ASN.1 source text. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [e-lang] Re: Protocol implementation errors
Peter Gutmann wrote: > Jerrold Leichter <[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. Do you really mean ASN.1 or do you mean DER/BER? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - 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: [e-lang] Re: Protocol implementation errors
On Sunday, Oct 5, 2003, at 11:03 US/Eastern, Jonathan S. Shapiro wrote: Peter: 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. I take it you a saying that ASN.1 syntax is hard to parse? Having written two parsers (C & Java) I can say that ASN.1's DER encoding is in fact straightforward to parse correctly, provided that you don't underestimate the task *and* you create and use an 'exhaustive' test suite. The problems with ASN.1 seem to stem more from its ISO heritage and dense specifications. That and the fact that a low-level bit-packing library isn't as glamorous as writing crypto and thus doesn't get as much scrutiny as other parts of protocol libraries. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Protocol implementation errors
I agree with Peter. If we're concerned about security implications of a particular SW technique then obviously we should ban the C language and all the string libraries first ;-) John On 10/4/03 1:58, "Peter Gutmann" <[EMAIL PROTECTED]> 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 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] - 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] 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: [e-lang] Re: Protocol implementation errors
Peter: 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. I do wonder if we shouldn't design a format that captures the best of both worlds... shap - 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]
