14547 2012-09-05 20:59:00 +0000 strcoll integer / buffer overflow 2012-09-11 15:51:47 +0000 1 1 1 Unclassified glibc libc 2.16 All All NEW P2 normal --- 1 jsm28 unassigned bugdal drepper.fsp ppluzhnikov shaun.colley 57269 jsm28 2012-09-05 20:59:31 +0000 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; } 57270 jsm28 2012-09-05 21:12:50 +0000 It looks like the same issue is also present in strxfrm (not tested). 57283 jsm28 2012-09-06 16:54:00 +0000 *** Bug 14552 has been marked as a duplicate of this bug. *** 57309 bugdal 2012-09-08 03:38:25 +0000 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. 57357 shaun.colley 2012-09-11 09:53:33 +0000 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 57359 shaun.colley 2012-09-11 15:51:47 +0000 The unbounded alloca issue also appears to be present in strxfrm.