[Bug malloc/29710] New: Multiple integer overflows on 'memusage.c'

[Bug malloc/29710] New: Multiple integer overflows on 'memusage.c'

[dimosxakis0 at gmail dot com]

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

            Bug ID: 29710
           Summary: Multiple integer overflows on 'memusage.c'
           Product: glibc
           Version: 2.36
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: dimosxakis0 at gmail dot com
  Target Milestone: ---

Multiple integer overflows exist on the malloc/calloc wrapper implementations
on 'memusage.c'.

void *
calloc (size_t n, size_t len)
{
  struct header *result;
  size_t size = n * len; // (1)
  ...
  /* Do the real work.  */
  result = (struct header *) (*mallocp)(size + sizeof (struct header)); // (2)
  ...
  return memset (result + 1, '\0', size);
}

At (1) there is no check for integer overflow. At (2) size is also padded with
a header size that might cause an additional integer overflow if (1) is fixed.
Eventually the computed size will be passed to the real malloc which will
return a small chunk instead of failing with NULL.

Similarly in the malloc wrapper there is another integer overflow:

void *
malloc (size_t len)
{
  ...
  /* Do the real work.  */
  result = (struct header *) (*mallocp)(len + sizeof (struct header)); // (3)
  ...
  /* Return the pointer to the user buffer.  */
  return (void *) (result + 1);
}

At (3) len is padded with the size of the header which may cause an integer
overflow returning a small chunk instead of failing with NULL.

Fortunately libmemusage.so as far as I know is only used from the linux
memusage command. Which is rarely used from anyone in practice. 

The only scenario that possibly this can introduce security risk to a system,
is if attacker controllable input is passed to a program that is being profiled
with 'memusage' command. If the attacker controls any malloc/calloc size fields
then he could cause a heap overflow and possibly compromise the system. This is
unluckily due to the rare usage of memusage.

An PoC example that can be used to verify this behavior is given below:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(int argc, char** argv) {
    char* overflow_chunk = malloc(0xffffffffffffffff);
    char* overflowed_chunk = malloc(0x18);
    if(overflow_chunk != NULL) {
        // If we reached this far this is bad. Possible corruption ahead of us.
        memset(overflow_chunk, 'A', 40);
    } else {
        puts("malloc() failed as it should in this case.");
    }
    // Should cause an abort due to chunk size corruption in case of an integer
overflow.
    free(overflowed_chunk);
    free(overflow_chunk);
    return 0;
}

Running the above program with:

$ gcc test.c -o a.out
$ memusage ./a.out

We should get an abortion error like this:
double free or corruption (out)

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