[BUG] heap buffer overflow in base64_encode base64.c:262

[xidoo123]

Description

heap buffer overflow in base64_encode base64.c:262

Analyse

This function fails to consider edge cases.

A quick thought here is when in_size=1, temp would be a heap chunk with 2 bytes long. However, later 5 bytes (will the null-terminate) are copied from out to temp, causing heap buffer overflow in kernel.

L4_CV void base64_encode( const char *infile, unsigned int in_size, char **outfile)
{
  unsigned char in[3], out[4];
  int i, len = 0;
  unsigned int in_count=0, out_count=0;
  char *temp=malloc(in_size*2);//to be on the safe side;
  if (!temp)
    {
      *outfile = NULL;
      return;
    }

  while(in_count<in_size)
    {
      len = 0;
      for( i = 0; i < 3; i++ ) 
    {
      if(in_count<in_size) 
        {
          in[i] = (unsigned char) infile[in_count++];
          len++;
        }
      else
        {
          in[i] = 0;
        }
    }
      if( len ) 
    {
      base64_encodeblock( in, out, len );
      for( i = 0; i < 4; i++ ) 
        {
          temp[out_count++]=out[i];  <- oob access
        }
    }
    }
  temp[out_count]=0; //null-terminate string
  *outfile=temp;
}

Impact

Depending on how the heap allocator is implemented, and the arch of victim machine this kernel runs on, this will cause DoS, data corruption and potentially privilege escape.

Fix

The fix here could be allocating at least 4 bytes memory.

char *temp=malloc(in_size*2 + 4);    // <- allocate more

Actually for base64 encoding, a good memory size might be like this.

Credits

Xdchase

[icedieler]

Hi @xidoo123,

thanks for reporting the issue. We'll have a look and provide a fix if necessary.

Regarding the assessment of the impact this issues does not impact the kernel. This is a utility function that can be used by an userland application by linking against the l4util library.