Ok, here are the details

the problem is that TORCS sometimes doesn't validate correctly data from acc files. for example in:

car5-trb1.acc

AC3Db
MATERIAL "ac3dmat1" rgb 1.00 1.00 1.00 amb 1.00 1.00 1.00 emis 0.20 0.20 0.20 spec 0.50 0.50 0.50 shi 50 trans 0
OBJECT world
kids 48
OBJECT poly
name "DIFFUSORFLA_s_23"

if an attacker writes an very long string in MATERIAL line for example,

MATERIAL "aaaaaaaaaaaaaaaaaaaaaaaaaaa......aaaaaaaaaaaaaaaaaaaa" rgb 1.00 1.00 1.00 amb 1.00 1.00 1.00 emis 0.20 0.20 0.20 spec 0.50 0.50 0.50 shi 50 trans 0

then it will happen:

in grloadacc.cpp

static int do_material ( char *s )
{
  char name [ 1024 ] ;
  sgVec4 rgb  ;
  sgVec4 amb  ;
  sgVec4 emis ;
  sgVec4 spec ;
  int   shi ;
  float trans ;

  if ( sscanf ( s,
  "%s rgb %f %f %f amb %f %f %f emis %f %f %f spec %f %f %f shi %d trans %f",
    name,
    &rgb [0], &rgb [1], &rgb [2],
    &amb [0], &amb [1], &amb [2],
    &emis[0], &emis[1], &emis[2],
    &spec[0], &spec[1], &spec[2],
    &shi,
    &trans ) != 15 )
  {
    ulSetError ( UL_WARNING, "grloadac:do_material: Can't parse this MATERIAL:%s", s ) ;
  }

the line

if ( sscanf ( s,....  

will fail and the function from plib ulSetError is gonna be called, with the long string "s". Then in:

ulError.cpp from plib

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 ) ;
  }
  else
  {
    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);
#endif
      exit (1) ;
    }
  }
}

this function is gonna overflow the buffer:

static char            _ulErrorBuffer [ 1024 ] = { '\0' } ;

which cause that pointer function

static ulErrorCallback _ulErrorCB = 0 ;

is overwritten and finally, that function pointer is called in:

if ( _ulErrorCB )
  {
    (*_ulErrorCB)( severity, _ulErrorBuffer ) ;
  }

An attacker can manipulate such string s, causing that torcs executes arbitrary code. It's important to note that the main problem is in plib, because it doesn't check the size of const char *fmt, for this reason the bug is trigered, but TORCS also should check acc inputs.

Well it's true that this bug is not about remote arbitrary code excecution but It should no be understimated. An attacker could convince a user to open a specially crafted acc file (a new car, track, ...), and it would be all he need to get total control over user's machine.

Regards, a any question is welcome.