I was looking into why gentoo uses gcc-config instead of an "eselect-gcc" which
would be more consistant with the rest of gentoo. So I figured that I would
look at the gcc-config sources, after all, it essentially does similar work to
eselect-gcc, perhaps I could help :)
Anyway, I discovered misuse of several functions causing buffer overflows. My
examples are from wrapper-1.5.0.c:
line 328:
"strcpy(data.name, basename(argv[0]));" more hypothetical than practical,
but since you don't know the length of argv[0], it should be a strncpy.
lines 218-221:
"strncpy(data->bin, str, sizeof(data->bin) - 1);
data->bin[strlen(data->bin) - 1] = '/';
strncat(data->bin, data->name, sizeof(data->bin) - 1);
data->bin[MAXPATHLEN] = 0;"
here, the problem is misuse of the strncat function. The size parameter is
supposed to represent how much is LEFT in the buffer (total size - used part).
Not the total size. I will attach a program which demonstrates that it does in
fact cause an overflow. Fortunately, the only damage that is done is the
data->tmp variable gets trashed. However, this whole thing could be safely
replaced with something like this:
snprintf(data->bin, sizeof(data->bin), "%s/%s", str, data->name);
line 48:
strncpy does not gaurantee null termination for long strings
line 71-73:
"size_t len = strlen(path) + strlen(data->name) + 2;
snprintf(str, len, "%s/%s", path, data->name);"
The size param of snprintf should be the size of the buffer, not the size of
the source data! This code basically does no bounds checking at all, because
you set the len equal to the size of the source data.
These should be easy to clean up, but of course I am still interested in my end
gaol of making gcc-config more consistent with the eselect system. But that is
for another day :)
Thanks,
Evan Teran
Reproducible: Always
