[
Lists Home |
Date Index |
Thread Index
]
Tyler Close wrote:
>
> 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
I didn't say that. I said that someone wrote buggy code and someone else
didn't test that code carefully before using it in more-complex programs.
There is nothing specific to ASN.1 here. If people don't write code
carefully, the same errors may be repeated in all kinds of applications and
with any technology.
> 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.
I am sure they knew it, but their knowledge didn't prevent them from making
mistakes. Again, there is absolutely nothing specific to ASN.1. The
mistakes were things like overflowing a buffer, trying to allocate
disorderly amounts of memory, overflowing the stack, and so on.
And a probably bigger mistake was that the programs did not undergo
sufficiently extensive testing. Amazing, but true. This extensive testing
has eventually started in 2002 and has found the bugs. Had it been done at
the appropriate time, you wouldn't be hearing about vulnerabilities
associated with SNMP and OpenSSL today.
Why cannot one make such mistakes when using XML technology? Why cannot one
make such mistakes when using any technology at all, in any application
domain at all?
Alessandro
> 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/
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative
of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
