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 19 2002 09:31AM
Steffen Dettmer (steffen dett de) (1 replies)
* Frank Knobbe wrote on Mon, Nov 18, 2002 at 15:46 -0600:
> 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 ]
Re: Are bad developer libraries the problem with M$ software? Nov 22 2002 03:35PM
Tim van Erven (tripudium chello nl)
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
Copyright 2010, SecurityFocus