Summary: | stdio/strfmon.c multiple vulnerabilities (CVE-2008-1391) | ||
---|---|---|---|
Product: | glibc | Reporter: | cxib <cxib> |
Component: | libc | Assignee: | Ulrich Drepper <drepper.fsp> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | fweimer, glibc-bugs, kees, thoger |
Priority: | P2 | Flags: | fweimer:
security+
|
Version: | 2.10 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
cxib
2009-09-03 20:31:12 UTC
(In reply to comment #0) > Affected Software (tested 27.08.2009): > - Fedora 11 > - Slackware 12.2 > - Ubuntu 9.04 > - others linux distributions Look like you should be listing architectures here too, as they do seem to matter here. > --- > And what exactly does an BSD implementation has to do with glibc? > --- That sounds like a reference to: http://sourceware.org/bugzilla/show_bug.cgi?id=9707 Further on, I'll be quoting this advisory: http://securityreason.com/achievement_securityalert/67 > Let's see libc/stdlib/strfmon_l.c (glibc rev-1.5.2.4) ... > if (width > LONG_MAX / 10 > || (width == LONG_MAX && val > LONG_MAX % 10)) > { > __set_errno (E2BIG); > return -1; > } ... > if (width >= maxsize - (dest - s)) > { > __set_errno (E2BIG); > return -1; > } .. > Perfect. The above code protects us. For the posterity and completeness of references, integer overflow check was added via following commit: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=153aa31b93be22e01b236375fb02a9f9b9a0195f This sounds like a reason why your original vector %99999999999999999999n does not work any more. > But what is below, is a mistake already This seems to refer to missing integer overflows checks in the code converting left_prec / right_prec from string to number, as similar approach is used there as for converting width: http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/strfmon_l.c#l242 http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/strfmon_l.c#l259 But wait, how does that explain a crash on "%.1073741821i"? 1073741821 is less than 2^31, so it won't overflow (signed) integer on either 32 bit or 64 bit architectures, right? > info.width = left_prec + (right_prec ? (right_prec + 1) : 0); This should not overflow either, as left_prec is 0 here. So the problem seems to be elsewhere... So let's ignore srtfmon for a while and try something more simple: printf("%.1073741821f\n", 0.0); Testing this on F11 glibc-2.10.1, this crashes when compiled with -m32, but does not with -m64. Little more looking leads to: http://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/printf_fp.c#l890 This is where integer overflow occurs (when computing wbuffer_to_alloc). It should also explain where do ~1gig memory usage come from with your "%.1343741821i" test. Ulrich, I bet your knowledge of this code is a lot better than reporter's and mine combined, so you can come up with proper fix. I just hope this additional info does help. Is it enough for NEW -> ASSIGNED state change. Only 32-bit had a problem and it's fixed. *** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla. |