l4re-core
l4re-core copied to clipboard
[BUG] heap buffer overflow in base64_encode base64.c:262
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