[Bug libc/12852] New: glob(3) contains possibly wrapping arguments to malloc

[Bug libc/12852] New: glob(3) contains possibly wrapping arguments to malloc

[matz at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=12852

           Summary: glob(3) contains possibly wrapping arguments to malloc
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: matz@suse.de


This problem is related to:
http://securityreason.com/achievement_securityalert/89
http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2010-008.txt.asc
http://www.oracle.com/technetwork/topics/security/cpujan2011-194091.html
http://support.avaya.com/css/P8/documents/100127892
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4754
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4755
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4756
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0418

and is mildly security relevant.  The glob implementation (I checked git head)
contains some calls to malloc where the argument is calculated in a way that
integer overflow or wraparound might occur, in effect allocating less memory
than intended, and hence writing to unallocated or unrelated memory.  In
particular I believe these calls to be problematic:

          pglob->gl_pathv = (char **) malloc ((pglob->gl_offs + 1)
                                              * sizeof (char *));

  (gl_offs is size_t, the multiplication by 4/8 can introduce a wraparound,
   leading to the malloc to succeed but with less memory allocated than
   intended. this could be replaced with calloc as the resulting memory is
   cleared anyway)

          new_gl_pathv
            = (char **) realloc (pglob->gl_pathv,
                                 (newcount + 1 + 1) * sizeof (char *));

  (same problem as above, but even worse as newcount is declared as int,
   so on overflow anything might happen)

              new_gl_pathv = (char **) realloc (pglob->gl_pathv,
                                                (newcount + 2)
                                                * sizeof (char *));

  (same as above)

With properly constructed patterns using repeated application of braces
such wraparounds can easily be reproduced.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12852] glob(3) contains possibly wrapping arguments to malloc

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12852

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-07-21 02:56:00 UTC ---
I added a patch but this has nothing do do with security problems from remote
uses.  Only the caller can pass in incorrect values and this feature is hardly
ever used in the first place.  It's really only a protection against
programming mistakes.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12852] glob(3) contains possibly wrapping arguments to malloc

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12852

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security+

-- 
You are receiving this mail because:
You are on the CC list for the bug.