vulndev-1.c challenge (was Re: Administrivia: List Announcement)

[Bennett Todd <bet () rahul net>]

>         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

Attachment: _bin
Description: