> char *buf1 = malloc(SIZE); > char *buf2 = malloc(SIZE); > [...] > p1 = argv[1], p2 = argv[2]; > strncpy(buf2, p2, SIZE); It's good kharma to check return values of resource-allocating routines like malloc(3) before you use those return values, to make sure the allocation succeeded. And if you were going do anything more exciting than free buf2 later, it'd be good form to make sure that argv[2] was shorter than SIZE, else buf2 is now not null-terminated. If you're lucky enough to have a strncpy that promises to completely null-out the tail of the buffer, you can check for this with buff2[SIZE-1] == 0, otherwise you need to either aim strlen at argv[2] (safe, since argv vector elements are guaranteed null-terminated by the kernel) or else walk buff2 (or argv[2]) up to SIZE looking for a null (aka strnlen(3), not standard as far as I know). > for (i = 0; i <= SIZE && p1[i] != '\0'; i++) > buf1[i] = p1[i]; Would look better if the test were "i < SIZE", this one lets you overrun the buffer by one byte. However, this class of problem would only be "interesting", i.e. leading to a possibly-expoitable security vulnerability, if the executable created by compiling this sample source were suid, or were otherwise invoked in a context where its args came from a different security domain than the one it's running in. -Bennett
This archive was generated by hypermail 2b30 : Tue May 13 2003 - 15:14:12 PDT