glibc 2.12 vfprintf function Multiple Vulnerabilities

2014.06.20
Credit: Multiple
Risk: High
Local: Yes
Remote: Yes

> Hi, > > there are further vulnerabilities in glibc's formatted printing > functionality. > > 1) It was discovered that the formatted printing functionality in > glibc did not properly honor the size of a structure when > calculating the amount of memory to allocate. A remote attacker > could provide a specially crafted sequence of format specifiers, > leading to an undersized buffer allocation and subsequent stack > corruption, resulting in a crash or, potentially, FORTIFY_SOURCE > format string protection mechanism bypass, when processed. > > References: http://sourceware.org/bugzilla/show_bug.cgi?id=12445 > http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=84a4211850e3d23a9d3a4f3b294752a3b30bc0ff > > https://bugzilla.redhat.com/show_bug.cgi?id=833703 Please use CVE-2012-3404 for this issue. diff --git a/stdio-common/vfprintf.c b/stdio-common/vfprintf.c index fc370e8..cfa4c30 100644 (file) --- a/stdio-common/vfprintf.c +++ b/stdio-common/vfprintf.c @@ -1,4 +1,4 @@ -/* Copyright (C) 1991-2008, 2009, 2010 Free Software Foundation, Inc. +/* Copyright (C) 1991-2008, 2009, 2010, 2011 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -1682,7 +1682,8 @@ do_positional: { /* Extend the array of format specifiers. */ struct printf_spec *old = specs; - specs = extend_alloca (specs, nspecs_max, 2 * nspecs_max); + specs = extend_alloca (specs, nspecs_max, + 2 * nspecs_max * sizeof (*specs)); /* Copy the old array's elements to the new space. */ memmove (specs, old, nspecs * sizeof (struct printf_spec)); > 2) It was discovered that the formatted printing functionality in > glibc used extend_alloca() incorrectly. "nspecs_max" is incorrectly > passed to extend_alloca, which modifies the value in "nspecs_max" > when allocating the memory. A remote attacker could provide a > specially crafted sequence of format specifiers, leading to a > desynchronization within the buffer size handling, resulting in the > use of uninitialized memory or, potentially, FORTIFY_SOURCE format > string protection mechanism bypass, when processed. > > References: http://sourceware.org/bugzilla/show_bug.cgi?id=13446 > http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a4647e727a2a52e1259474c13f4b13288938bed4 > > https://bugzilla.redhat.com/show_bug.cgi?id=833704 > > It seems like 1) and 2) were introduced by the following commit: > http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1d498daa95384e5c9ad5bcb35e7a996e5869ac39 Please use CVE-2012-3405 for this issue. diff --git a/stdio-common/vfprintf.c b/stdio-common/vfprintf.c index 753a5ac..952886b 100644 (file) --- a/stdio-common/vfprintf.c +++ b/stdio-common/vfprintf.c @@ -1640,9 +1640,9 @@ do_positional: /* Array with information about the needed arguments. This has to be dynamically extensible. */ size_t nspecs = 0; - size_t nspecs_max = 32; /* A more or less arbitrary start value. */ - struct printf_spec *specs - = alloca (nspecs_max * sizeof (struct printf_spec)); + /* A more or less arbitrary start value. */ + size_t nspecs_size = 32 * sizeof (struct printf_spec); + struct printf_spec *specs = alloca (nspecs_size); /* The number of arguments the format string requests. This will determine the size of the array needed to store the argument @@ -1679,15 +1679,14 @@ do_positional: for (f = lead_str_end; *f != L_('\0'); f = specs[nspecs++].next_fmt) { - if (nspecs >= nspecs_max) + if (nspecs * sizeof (*specs) >= nspecs_size) { /* Extend the array of format specifiers. */ struct printf_spec *old = specs; - specs = extend_alloca (specs, nspecs_max, - 2 * nspecs_max * sizeof (*specs)); + specs = extend_alloca (specs, nspecs_size, 2 * nspecs_size); /* Copy the old array's elements to the new space. */ - memmove (specs, old, nspecs * sizeof (struct printf_spec)); + memmove (specs, old, nspecs * sizeof (*specs)); } /* Parse the format specifier. */ > 3) It was discovered that the formatted printing functionality in > glibc did not properly restrict the use of alloca(). A remote > attacker could provide a specially crafted sequence of format > specifiers, leading to a crash or, potentially, FORTIFY_SOURCE > format string protection mechanism bypass, when processed. > > References: https://bugzilla.redhat.com/show_bug.cgi?id=826943 > > Red Hat patch backports/testcases for RHEL6 that include a patch > for this: > https://bugzilla.redhat.com/attachment.cgi?id=594722&action=diff > > Red Hat patch backport/testcase for RHEL5 (older glibc versions) > https://bugzilla.redhat.com/attachment.cgi?id=594727&action=diff Please use CVE-2012-3406 for this issue.

References:

http://www.openwall.com/lists/oss-security/2012/07/11/17
http://sourceware.org/bugzilla/show_bug.cgi?id=12445
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=84a4211850e3d23a9d3a4f3b294752a3b30bc0ff
http://sourceware.org/bugzilla/show_bug.cgi?id=13446
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a4647e727a2a52e1259474c13f4b13288938bed4
https://bugzilla.redhat.com/show_bug.cgi?id=826943
https://bugzilla.redhat.com/attachment.cgi?id=594722&action=diff


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top