[Bug libc/10600] stdio/strfmon.c multiple vulnerabilities

["thoger at redhat dot com" <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.