[
Lists Home |
Date Index |
Thread Index
]
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/
|
