This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/10600] stdio/strfmon.c multiple vulnerabilities
- From: "thoger at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 23 Sep 2009 16:44:21 -0000
- Subject: [Bug libc/10600] stdio/strfmon.c multiple vulnerabilities
- References: <20090903203112.10600.cxib@securityreason.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From thoger at redhat dot com 2009-09-23 16:44 -------
(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.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |thoger at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=10600
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.