On Sun, 30 Jun 2002, Mark Brown wrote: > On Sunday, June 30, 2002, at 03:50 PM, [EMAIL PROTECTED] wrote: > > > The article at > > > > http://www.washingtonpost.com/wp-dyn/articles/A50765-2002Jun26.html > > > > seems to blame the ASN.1 specification language itself for the > > problem. Can anyone say more about what they are discussiong ? > > At a guess this relates to some exploits found in a lot of SNMP > implementations as a result of some people constructing a test suite for > the protocol. This was widely discussed at the time the vulnerabilities > were published. See, for example: > > http://www.counterpane.com/crypto-gram-0203.html#1 > > and the readers comments in the following issue. The original advisory > can be found at: > > http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/ > > ASN.1 is no different to any other network protocol - it's possible > write a buggy, exploitable implementation using it.
Correct. Since February I and others in the ITU-T ASN.1 group have gone over the ASN.1 and encoding rule standards with a fine tooth comb looking for possible vulnerabilties, and we have come up with nothing. I was aware that the President's Critical Infrastructure Protection Board was investigating the threat to the U.S. and its allies posed by the newly detected security vulnerabilities, so I contacted key members of the Board to see if they were aware of any vulnerabilities in ASN.1 or BER. They responded that they are aware of flawed implementations, but no vulnerabilities in the ASN.1 or BER standards were found. One thing of interest that surfaced as a result of this close examination is that ASN.1, XML Schema and other similar notations possess similar implementation pitfalls that programmers need to pay close attention to. For this reason, the ITU-T will shortly be making available a document that makes suggestions on things that writers of network application programs should look out for. This hasn't anything to do with ASN.1 in particular, as the pitfalls have nothing to do with ASN.1, but is a good set of suggestions which if not heeded can result in vulnerable network applications. > There may be arguments for saying that the complexity of some of the > encoding methods makes it difficult a safe implementation or that > other aspects of the way people use ASN.1 can present risks but I > don't recall anyone identifying anything in particular about ASN.1 > itself. I have spent a good part of the last several months chasing down rumours to the effect that there may be vulnerabilities in ASN.1, and in every case have found that the rumors are unsubstantiated. In almost every case the problems are due to buffer overflows, where decoders blindly copy data into buffers without first checking to see if the buffers are large enough to hold the data. Many of the problems in the SNMPv1 implementations were traced back to a single origin, the UC Davis SNMPv1 toolkit that was created 14 years ago. Being one of the very first widely used application that uses ASN.1/BER, it is not surprising that such problems occurred. Fixes to the flaws in the UC Davis SNMPv1 toolkit has been available for some time, but it is obvious that vendors chose not to apply them, for as far as they could see their SNMP products never had any problems. Until now. Note that tools such as the OSS ASN.1 Tools and those from uniGone ran the tests from Oulu University without problems. (The Oulu University tests were created to test how well SNMPv1 applications handle not just valid, well-formed encodings, but also invalid or unexpectedly huge encodings). ------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 [EMAIL PROTECTED] Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023 http://www.oss.com
