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); exit(EXIT_SUCCESS); } ==========end====================== Actual results: Segmentation fault Expected results: 123.45
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.
Should be fixed in glibc-2.9.90-22.
It seems that it still vulnerable to this: http://sources.redhat.com/bugzilla/show_bug.cgi?id=10600 Running 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.
Test was run on fedora 11.
Don't do that then. You are requesting more than 1343741821 characters to be produced.
(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.
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: http://sources.redhat.com/bugzilla/show_bug.cgi?id=10600
There is nothing more to fix here. Producing more than 1343741821 characters just needs a log of memory.
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" ;).
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 glibc-2.10.90-23.x86_64 glibc-2.10.90-23.i686 $ 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)); (gdb) 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.
printf("%.1073741824f\n", 0.0) no longer SEGVs with glibc-2.10.90-25, which includes following upstream git commit: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=199eb0de8d Thanks, Andreas!
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
There is no problem, at least with the current code.