|
Secure Programming
RE: Are bad developer libraries the problem with M$ software? Nov 16 2002 01:00AM Michael Howard (mikehow microsoft com) (2 replies) RE: Are bad developer libraries the problem with M$ software? Nov 16 2002 07:03PM Frank Knobbe (fknobbe knobbeits com) (3 replies) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 07:36PM Casper Dik (Casper Dik Sun COM) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 11:10PM Andrew Griffiths (andrewg d2 net au) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 19 2002 03:25AM Frank Knobbe (fknobbe knobbeits com) (3 replies) Re: Are bad developer libraries the problem with M$ software? Mar 22 2003 09:56AM Casper Dik (Casper Dik Sun COM) Re: Are bad developer libraries the problem with M$ software? Nov 19 2002 10:57PM Andrew Dalgleish (secprog andrewdalgleish dyndns org) (2 replies) Re: Are bad developer libraries the problem with M$ software? Nov 22 2002 03:31PM Frank Knobbe (fknobbe knobbeits com) Re: Are bad developer libraries the problem with M$ software? Nov 22 2002 07:11AM Valdis Kletnieks vt edu Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 11:22PM Andrew Griffiths (andrewg d2 net au) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 06:54PM John Viega (viega securesoftware com) (2 replies) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 09:46PM Frank Knobbe (fknobbe knobbeits com) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 06:26PM Götz Babin-Ebell (babinebell trustcenter de) Re: Are bad developer libraries the problem with M$ software? Nov 16 2002 03:29PM Alex Lambert (alambert webmaster com) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 17 2002 01:46AM Glynn Clements (glynn clements virgin net) |
|
Privacy Statement |
> On Mon, 2002-11-18 at 12:54, John Viega wrote:
>
> > > #define safe_strcat(dst,src)
> > > strncat(dst,src,sizeof(dst))
> >
> > 1) sizeof(dst) is very often going to be sizeof(char *) which is 2, no matter
> > how much space is malloc'd.
Well, and from my manual page this is incorrect even if des is a
char[], since strncat *appends* the first "n" chars to dst, so
you would need to use (sizeof(dst) - strlen(dst)) with proper
checking for overflows. Well, and AFAIK if the "n" constraint
matches, the string is not zero terminated (so it's no string),
so you have to overwrite the last character with a \0 if the
application can work on incomplete data or you have to check the
return value. Well, and if someone tries something like:
printf("To long string at %s\n", dst)
is again a mess (non-terminated string output), so I suggest to
write somethink like:
/* check if someone replaced out char[] with a char* */
assert(sizeof(dest)>4);
dst[sizeof(dest)-1] = '\0';
at the end of the manipulation always (sometimes colleguages add
debug statements or such years later).
For the define (well, I don't like defines, since they generate
compile-time-versions often) I would suggest:
#define strcat(x,y)
# log("invalid function call: strcat"); assert(0);
#endif
or
#define strcat(x,y)
# generate compiletime error }}}}}}}}}}}}}}
#endif
IIRC gcc has/had a
#pragma poison strcat
But on the other hand, there are cases in that strcat is safe -
when the strings have constant or already checked contents...
> *blush*.... I guess I should have used safe_strncat instead... :)
Or just switch to C++ and use string :) With C, you could create
a module
---- c_string.h ---------
/* hope this is syntactically correct :) */
struct c_string_s;
typedef struct c_string_s *c_string;
c_string
c_string_new(void);
void
c_string_delete(c_string);
c_string
strcat(c_string dest, c_string src);
size_t
c_string_strlen(c_string str);
/* ... */
-------------------------
---- c_string.c ---------
typedef struct {
char *str;
size_t allocated_memory;
/* ... */
} c_string_s;
/* In the implementations, the functions know the size of the
* allocated memory. If the result becomes to large, they
* can try to reallocate memory transparently, like an C++ STL
* string does.
*/
static
realloc_and_copy(c_string str, size_t new_length);
size_t
c_string_strlen(c_string str);
c_string
c_string_strcat(c_string dest, c_string src)
{
assert(dest != NULL);
if (src == NULL) {
return dest;
}
size_t length = c_string_strlen(dest) + c_string_strlen(src);
if (dest->allocated_memory < length) {
realloc_and_copy(dest, length + 1);
}
strcat(dest->str, src->str);
return dest;
}
--------------------------
In this case, the c_string knows and can rely on the allocated
size. I think, for any define construction someone may find a
situation where it won't work.
oki,
Steffen
--
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.
[ reply ]