Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Fwd: [e-lang] Protocol implementation errors
 On Friday 03 October 2003 12:11, Alessandro Triglia wrote: > Tyler Close wrote: > > On Friday 03 October 2003 10:32, Bullard, Claude L (Len) wrote: > > > The first step will be to learn to dampen > > > Spy Vs Spy arguments with regards to who > > > has the safest system in situations where > > > it is the coding culture that is at issue. > > > > The point of the original post is that ASN.1 posed problems > > even in a coding culture that is, and has been, highly > > attuned to security issues. > > Any programmer highly attuned to security issues would make sure that: > > - the program checks that all memory allocation requests are satisfied > - the program does not write or read beyond the limits of the allocated > buffers > - the program does not try to allocate gigabytes of memory just because the > incoming message seems to require that > - the program does not try to recurse hundreds of levels down the stack > just because the the incoming message seems to require that > - etc. etc. > > However, these are precisely the kinds of bugs that have been found in the > faulty implementations of SNMP and OpenSSL. Therefore, the programmers who > wrote the code (and the people who evaluated and used their code) were > *not* in any sense "highly attuned to security issues". If those > programmers are still around and haven't learned the lesson, and if other > people use their code carelessly in building more-complex software, we will > still have problems. Your argument that the OpenSSL hackers are less competent than others is dubious. Can you support this claim? Or can you show that web services programmers can be expected to be more competent? > There is nothing specific to ASN.1 here. You are assuming that it was random chance that these bugs survived, undiscovered for so long, in the ASN.1 code, as opposed to elsewhere. This assumption may be valid once, but twice? Was ASN.1 really an innocent bystander, or did it do something to make an accident more likely? The question must be answered, it cannot be simply dismissed. > Note that implementing a cryptography algorithm does not make you a > security-aware programmer. Cryptography is one thing, safe programming is > another. True, but what makes this example interesting is the purpose of the application. The implications of unsafe programming are dire for this application. The programmers know this. In a high stakes environment, these hackers were unable to produce safe code, despite their need to do so. Their failure should at least be explained before proceeding with the same methods on an even larger project. Tyler -- The union of REST and capability-based security: http://www.waterken.com/dev/Web/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
