strncpy(buf2, p2, SIZE);
This is not off-by-one. Strncpy doesn't zero the "string" if it's
greater than SIZE. The flaw here is the possibility to read the off
bound memory. If your printf("%s", buf2), you must see garbage after
that, until it finds a zero. But it do not cross it's malloced
boundaries.
> for (i = 0; i <= SIZE && p1[i] != '\0'; i++)
This is off-by-one heap overflow.
> Condition should be < SIZE. <= SIZE leads to the same vuln as above.
This
> is also a shabby way to copy a string on architectures with a bigger
word
> size than 8bits. The number of ops can be reduced by copying through a
> 32bit register and then using 8bits for the remaining < 4 bytes.
I don't think this is a shabby way to copy a string. An hipotetical char
= 16 bits, not even your malloc is misused, like your for is incoherent.
Yes, the correct loop would be i < SIZE. Ops can be reduced if your
compiler could optmize it. If you force an arch based optmization (like
the one you proposed), it is totally arch dependent.
Anyway, you may think copy will always have an inner loop (because the
end of string condition). Unless your processor has some kind of store
byte until byte = 0. Someone could talk about finding out how many chars
to copy, before the real copy, to solve the read/write pipeline delays.
That's all.
Gustavo Scotti
Tamandua Laboratories - Axur Information Security
http://tamandua.axur.org
This archive was generated by hypermail 2b30 : Tue May 13 2003 - 15:22:48 PDT