Bug 496386 - glibc strfmon vulnerability
Summary: glibc strfmon vulnerability
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 10
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Andreas Schwab
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
Blocks: CVE-2008-1391
TreeView+ depends on / blocked
Reported: 2009-04-18 14:15 UTC by Waasoo
Modified: 2009-11-23 00:49 UTC (History)
8 users (show)

Clone Of:
Last Closed: 2009-11-23 00:49:06 UTC

Attachments (Terms of Use)

Description Waasoo 2009-04-18 14:15:46 UTC
Description of problem:

I'm able to reproduce vulnerability reported by Maksymilian Arciemowicz (http://securityreason.com/achievement_securityalert/53) for *BSD libc using glibc on Fedora Core 10.

Version-Release number of selected component (if applicable):
glibc v 2.9 rel 3. 

Steps to Reproduce:
==========example source===========
#include <monetary.h>
#include <stdlib.h>

int main(int argc, char ** argv)
	char buff[50];
	char * w_buff;
	w_buff = buff;
	strfmon(w_buff, sizeof(buff), "%9999999999n", 123.34);

Actual results:
Segmentation fault

Expected results:

Comment 1 Ulrich Drepper 2009-04-18 19:57:45 UTC
There was a problem (fixed upstream).  But your expected result is wrong.  And it's really not a big issue since a) the format strings are hardly ever non-const and b) the written data is either the decimal representation of the number (in ASCII) or a space.

Comment 2 Jakub Jelinek 2009-04-27 20:11:53 UTC
Should be fixed in glibc-2.9.90-22.

Comment 3 Alexey Torkhov 2009-09-19 10:16:20 UTC
It seems that it still vulnerable to this:

php -r 'money_format("%.1343741821i",1);'
eats about 3G on my machine and doesn't want to stop - I'm cancelling the task.

Reopening the bug.

Comment 4 Alexey Torkhov 2009-09-19 10:19:44 UTC
Test was run on fedora 11.

Comment 5 Andreas Schwab 2009-09-22 12:00:24 UTC
Don't do that then. You are requesting more than 1343741821 characters to be produced.

Comment 6 Alexey Torkhov 2009-09-22 12:13:21 UTC
(In reply to comment #5)
> Don't do that then. You are requesting more than 1343741821 characters to be
> produced.  

Strange, but it works fine in current Rawhide. I think, that's a bug in glibc and reassigning to php is wrong - program written in C would have same behaviour.

Comment 8 Joe Orton 2009-09-28 13:18:13 UTC
It makes no sense to assign this bug to php *and* mark it CLOSED->RAWHIDE. 
Nothing has changed in php.  Either there is a glibc bug which has been fixed,
there is a glibc bug which has not been fixed (completely), or there is a php
bug which has not been fixed.

Re-opening and reassigning to glibc, per thoger's comment at:


Comment 9 Andreas Schwab 2009-09-28 16:11:52 UTC
There is nothing more to fix here.  Producing more than 1343741821 characters just needs a log of memory.

Comment 10 Tomas Hoger 2009-09-28 16:26:02 UTC
What does this do for you on rawhide / 32bit?

  printf("%.1073741821f\n", 0.0);

If my comments in upstream bug are incorrect, I'm happy to get corrected.  I've not tested rawhide, bug I did check F11 and I failed to see a fix in git to address problem I pointed out.

Anyway, lets stop calling this "strfmon" and "vulnerablitiy" ;).

Comment 12 Tomas Hoger 2009-09-28 17:56:27 UTC
I've been asked to provide more info about this, so here it comes.  It's already all in my comment in upstream bug (please do read it), but anyway:

$ rpm -q glibc

$ cat printf-int-overflow.c 
#include <stdio.h>

int main(void) {
	printf("%.1073741824f\n", 0.0);
	return 0;

$ gcc -Wall printf-int-overflow.c -m64 && ./a.out

$ gcc -Wall printf-int-overflow.c -m32 && ./a.out 
Segmentation fault

Running gdb, integer overflow I pointed out in the upstream bug is still there:

(gdb) i break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x003f388f in ___printf_fp at printf_fp.c:894
	breakpoint already hit 1 time

Breakpoint 1, ___printf_fp (fp=0x5264c0, info=0xffffd670, args=0xffffd6e4) at printf_fp.c:894
894	    size_t wbuffer_to_alloc = (2 + (size_t) chars_needed) * sizeof (wchar_t);
(gdb) n
895	    buffer_malloced = ! __libc_use_alloca (chars_needed * 2 * sizeof (wchar_t));
904	      wbuffer = (wchar_t *) alloca (wbuffer_to_alloc);
(gdb) print chars_needed
$1 = 1073741826
(gdb) print wbuffer_to_alloc
$2 = 16

Btw, I'm *NOT* calling this security, but I still see bug that may be worth fixing.  Not oh-the-sky-is-falling priority, if you think this is not worth fixing / should not be fixed, please close-wontfix.  Rawhide resolution is not correct.  And it's not strfmon bug either.

Comment 14 Tomas Hoger 2009-10-13 16:31:32 UTC
printf("%.1073741824f\n", 0.0) no longer SEGVs with glibc-2.10.90-25, which includes following upstream git commit:


Thanks, Andreas!

Comment 15 Bug Zapper 2009-11-18 12:50:03 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 16 Ulrich Drepper 2009-11-23 00:49:06 UTC
There is no problem, at least with the current code.

Note You need to log in before you can comment on or make changes to this bug.