Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 207926
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Toolchain Maintainers <toolchain@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Evan Teran <eteran@alum.rit.edu>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
test.c example of overflow text/plain Evan Teran 2008-01-28 16:52 0000 1.46 KB Details
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 207926 depends on: Show dependency tree
Bug 207926 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2008-01-28 16:51 0000
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

------- Comment #1 From Evan Teran 2008-01-28 16:52:21 0000 -------
Created an attachment (id=142028) [details]
example of overflow

------- Comment #2 From SpanKY 2008-03-16 01:20:25 0000 -------
eselect-gcc is a duplicate of gcc-config at the moment, not the other way
around

string handling has been cleaned up in gcc-config-1.4.1:
http://sources.gentoo.org/sys-devel/gcc-config/files/wrapper-1.5.1.c?rev=1.1

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug