> 2. Score another 1 up for interpreted languages that handle array
> allocation cleanly. This is more or less a buffer overflow, in a wider
> sense.
Virtually the same bug can occur (and has occurred) in memory-safe
languages due to buffer reuse.
Go was mentioned elsewhere in this thread, so let's look at how it
handles I/O:
type Reader interface {
Read(p []byte) (n int, err error)
}
<http://golang.org/pkg/io/#Reader>
The return value n tells the caller that the indices p[0], p[1], …,
p[n-1] contain valid data, and n can be less than the length of p. So
if the caller, during parsing, reads beyond p[n-1], but not beyond
p[len(p)-1], the language runtime will not detect this and data which
depends on where and how the buffer has been used before will be
returned.
There is still a difference: Only data that was in the buffer before
can be returned. But depending on the buffer reuse mechanism, such
data may still include bits of cleartext from unrelated connections.
Buffer reuse is a commonly employed performance optimization in
garbage-collected languages because without it, the I/O speed is
constrained by the speed at which the garbage collector can collect
buffers used only once.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
