Re: [Lit.] Buffer overruns
From: Trevor L. Jackson, III (tlj3_at_comcast.net)
Date: 01/29/05
- Next message: Trevor L. Jackson, III: "Re: [Lit.] Buffer overruns"
- Previous message: Tim Peters: "Re: Surrogate factoring, out of the box"
- In reply to: David Wagner: "Re: [Lit.] Buffer overruns"
- Next in thread: infobahn: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 29 Jan 2005 16:49:24 -0500
David Wagner wrote:
> Trevor L. Jackson, III wrote:
>
>>David Wagner wrote:
>>
>>> #define PRIME ...
>>> int hash(char *s) {
>>> int h = 0;
>>> while (*s)
>>> h = ((h<<8) + *s++) % PRIME;
>>> return h;
>>> }
>>> struct tblentry hashtable[PRIME];
>>> foo() {
>>> char *str = read_string_from_network();
>>> int i = hash(str);
>>> hashtable[i] = ...;
>>> }
>>
>>Good example, but it applies to the design process rather than the
>>implementation (coding) process. This hole would be created in any
>>language -- insufficient consideration of the range of hash(). And it
>>would be caught by simple, mindless bounds checking.
>
>
> Nope, not in any language: it wouldn't be exploitable (except
> perhaps to cause DoS) if this were written in Java, or indeed
> in any memory-safe language.
>
> Yes, it would be caught by truly mindless bounds checking.
> But human programmers tend not to be truly mindless; they tend
> to omit unnecessary checks (or, checks they believe to be unnecessary).
> So human programmers might not reliably catch this bug. On the
> other hand, automatic bounds checking *would* reliably catch this
> bug -- compilers tend not to make those kinds of mistakes.
>
> By the way, another interesting thing about this bug is that
> it is platform-dependent. On some platforms (those with 'char'
> = 'unsigned char'), this code is safe. Even if you test the code
> very thoroughly, if you are testing on those platforms the bug will
> not manifest itself; then if you later port this code to another
> platform with 'char' = 'signed char' (and don't bother testing it
> as extensively on the new platform), you might then become vulnerable.
Hmmm. I think the code above is much worse than you do. The
quantization of the shifts at 8 can be interpreted to mean that the only
the sign bit of the characters matters. But that assumption is false.
On a machine with 6-, 7-, 9-, 10-, 16-, or 32-bit characters, all of
which still exist and are in operation, any bit could end up in the sign
bit of h. I suspect that's why Gwyn expressed his dislike for
left-shifting an int. Never do that.
And I think you are wrong about the language independence issue. The
_defect_ could occur in any language. The consequences of that defect
would be less damaging in a memory-safe language than they would be in C.
Some of your reaction may be based on the process by which C is
introduced to new programmers. A developer with a a few years of
experience but none in C could have trouble years after switching to C
because he (they? is that thread dead yet? any National Socialists
mentioned?) did not take the trouble to really learn the language.
For example, the above error would not happen to a C programmer who has
tangled with <ctype.h>. The signed/unsigned issue come into stark
relief the first time you have to consider portable use of char. Once
that trauma fades one is left with the fundamental understanding of how
dangerous sign bits can be, and once the danger is understood the
recurrence rate is quite low.
OTOH a programmer who starts at the level of assembly language already
has an awareness of those kinds of considerations becase he has to
manage the link/carry bit in addition to the sign bit. So the above
code would be unnatural for a person coming from an A.L. background.
Moral: it's the people not the language.
/tj3
- Next message: Trevor L. Jackson, III: "Re: [Lit.] Buffer overruns"
- Previous message: Tim Peters: "Re: Surrogate factoring, out of the box"
- In reply to: David Wagner: "Re: [Lit.] Buffer overruns"
- Next in thread: infobahn: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
