Re: TORCS + PLIB Buffer overflow detected
Andres Gomez <[email protected]> Tue, 20 Dec 2011 12:17:19 -0500
| Newsgroups | gmane.games.torcs.devel |
|---|---|
| Message-ID | <CAB9ZNAzf+ypqyB+Gf5+CTAABcc01SE8sZrYXQ39nFOUGafxYag@mail.gmail.com> |
--===============1342884223140650984==
Content-Type: multipart/alternative; boundary=14dae93b5c8c93c22904b4893e60
--14dae93b5c8c93c22904b4893e60
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 ) !=3D 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 =3D=3D 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 ] =3D { '\0' } ;
which cause that pointer function
static ulErrorCallback _ulErrorCB =3D 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.
2011/12/20 Bernhard Wymann <[email protected]>
> Hi Andres
>
> I think it is ok to publish it in the list, because TORCS is not a
> networking/priviledged application, so there should (!) be nothing
> "exploitable" (if a user can run code and can run override/inject code in
> his own context it is a nice "playground", but not much more, it just get=
s
> interesting when this can happen from "outside"/other user, is this the
> case?). But it should be addressed for later network versions, where this
> could really hurt.
>
> Thank you for the info.
>
> Best regards
>
> Bernhard
>
> On Dec 20, 2011, at 16:04 , Andres Gomez wrote:
>
> > Hi,
> >
> > I have found an exploitable buffer overflow in torcs when it uses the
> library plib, I dont know whether I should disclose details in this maili=
ng
> list or to another private mail.
> >
> >
> > Regards,
> > Andr=E9s G=F3mez
> >
> >
> -------------------------------------------------------------------------=
-----
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Creat=
e
> > new or port existing apps to sell to consumers worldwide. Explore the
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/joi=
n
> >
> http://p.sf.net/sfu/intel-appdev_________________________________________=
______
> > Torcs-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/torcs-devel
>
>
--=20
Andr=E9s G=F3mez Ram=EDrez | Analista de Diagn=F3stico
Fluidsignal Group S.A. | Where Security Meets Business
http://www.fluidsignal.com/ | ISO 9001:2008 / ISO 27001:2005
Tel=E9fono: +57 (4) 4442637 | M=F3vil: +57 3012009712
--14dae93b5c8c93c22904b4893e60
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Ok, here are the details<br><br>the problem is that TORCS sometimes doesn&#=
39;t validate correctly data from acc files. for example in:<br><br>car5-tr=
b1.acc<br><br>AC3Db<br>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 <br>
OBJECT world<br>kids 48<br>OBJECT poly<br>name "DIFFUSORFLA_s_23"=
<br><br>if an attacker writes an very long string in MATERIAL line for exam=
ple,<br><br>MATERIAL "aaaaaaaaaaaaaaaaaaaaaaaaaaa......aaaaaaaaaaaaaaa=
aaaaa" 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 <br>
<br>then it will happen:<br><br>in grloadacc.cpp<br><br>static int do_mater=
ial ( char *s )<br>{<br>=A0 char name [ 1024 ] ;<br>=A0 sgVec4 rgb=A0 ;<br>=
=A0 sgVec4 amb=A0 ;<br>=A0 sgVec4 emis ;<br>=A0 sgVec4 spec ;<br>=A0 int=A0=
=A0 shi ;<br>=A0 float trans ;<br>
<br>=A0 if ( sscanf ( s,<br>=A0 "%s rgb %f %f %f amb %f %f %f emis %f =
%f %f spec %f %f %f shi %d trans %f",<br>=A0=A0=A0 name,<br>=A0=A0=A0 =
&rgb [0], &rgb [1], &rgb [2],<br>=A0=A0=A0 &amb [0], &a=
mb [1], &amb [2],<br>
=A0=A0=A0 &emis[0], &emis[1], &emis[2],<br>=A0=A0=A0 &spec[=
0], &spec[1], &spec[2],<br>=A0=A0=A0 &shi,<br>=A0=A0=A0 &tr=
ans ) !=3D 15 )<br>=A0 {<br>=A0=A0=A0 ulSetError ( UL_WARNING, "grload=
ac:do_material: Can't parse this MATERIAL:%s", s ) ;<br>
=A0 }<br><br>the line<br><br>if ( sscanf ( s,....=A0=A0 <br><br>will fail a=
nd the function from plib ulSetError is gonna be called, with the long str=
ing "s". Then in:<br><br>ulError.cpp from plib<br><br>void ulSetE=
rror ( enum ulSeverity severity, const char *fmt, ... )<br>
{<br>=A0 va_list argp;<br>=A0 va_start ( argp, fmt ) ;<br>=A0 vsprintf ( _u=
lErrorBuffer, fmt, argp ) ;<br>=A0 va_end ( argp ) ;<br>=A0<br>=A0 if ( _ul=
ErrorCB )<br>=A0 {<br>=A0=A0=A0 (*_ulErrorCB)( severity, _ulErrorBuffer ) ;=
<br>=A0 }<br>=A0 else<br>
=A0 {<br>=A0=A0=A0 fprintf ( stderr, "%s: %s\n",<br>=A0=A0=A0=A0=
=A0=A0 _ulSeverityText[ severity ], _ulErrorBuffer ) ;<br>=A0=A0=A0 if ( se=
verity =3D=3D UL_FATAL )<br>=A0=A0=A0 {<br>#ifdef WIN32<br>=A0=A0=A0=A0=A0 =
// A Windows user that does not start the program from the command line<br>
=A0=A0=A0=A0=A0 // will not see output to stderr<br>=A0=A0=A0=A0=A0 ::Messa=
geBox(0, _ulErrorBuffer, "fatal error!:", 0);<br>#endif<br>=A0=A0=
=A0=A0=A0 exit (1) ;<br>=A0=A0=A0 }<br>=A0 }<br>}<br><br>this function is g=
onna overflow the buffer:<br><br>
static char=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 _ulErrorBuffer [ 1024 ] =3D { =
'\0' } ;<br>
<br>which cause that pointer function <br><br>static ulErrorCallback _ulErr=
orCB =3D 0 ;<br><br>is overwritten and finally, that function pointer is ca=
lled in:<br><br>if ( _ulErrorCB )<br>
=A0 {<br>
=A0=A0=A0 (*_ulErrorCB)( severity, _ulErrorBuffer ) ;<br>
=A0 }<br><br>An attacker can manipulate such string s, causing that torcs e=
xecutes 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 thi=
s reason the bug is trigered, but TORCS also should check acc inputs.<br>
<br>Well it's true that this bug is not about remote arbitrary code exc=
ecution but It should no be understimated. An attacker could convince a use=
r to open a specially crafted acc file (a new car, track, ...), and it woul=
d be all he need to get total control over user's machine. <br>
<br>Regards, a any question is welcome.<br><br><div class=3D"gmail_quote">2=
011/12/20 Bernhard Wymann <span dir=3D"ltr"><<a href=3D"mailto:berniw@bl=
uewin.ch">[email protected]</a>></span><br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
Hi Andres<br>
<br>
I think it is ok to publish it in the list, because TORCS is not a networki=
ng/priviledged application, so there should (!) be nothing "exploitabl=
e" (if a user can run code and can run override/inject code in his own=
context it is a nice "playground", but not much more, it just ge=
ts interesting when this can happen from "outside"/other user, is=
this the case?). But it should be addressed for later network versions, wh=
ere this could really hurt.<br>
<br>
Thank you for the info.<br>
<br>
Best regards<br>
<br>
Bernhard<br>
<div><div class=3D"h5"><br>
On Dec 20, 2011, at 16:04 , Andres Gomez wrote:<br>
<br>
> Hi,<br>
><br>
> I have found an exploitable buffer overflow in torcs when it uses the =
library plib, I dont know whether I should disclose details in this mailing=
list or to another private mail.<br>
><br>
><br>
> Regards,<br>
> Andr=E9s G=F3mez<br>
><br>
</div></div>> ----------------------------------------------------------=
--------------------<br>
> Write once. Port to many.<br>
> Get the SDK and tools to simplify cross-platform app development. Crea=
te<br>
> new or port existing apps to sell to consumers worldwide. Explore the<=
br>
> Intel AppUpSM program developer opportunity. <a href=3D"http://appdeve=
loper.intel.com/join" target=3D"_blank">appdeveloper.intel.com/join</a><br>
> <a href=3D"http://p.sf.net/sfu/intel-appdev___________________________=
____________________" target=3D"_blank">http://p.sf.net/sfu/intel-appdev___=
____________________________________________</a><br>
> Torcs-devel mailing list<br>
> <a href=3D"mailto:[email protected]">Torcs-devel@lists=
.sourceforge.net</a><br>
> <a href=3D"https://lists.sourceforge.net/lists/listinfo/torcs-devel" t=
arget=3D"_blank">https://lists.sourceforge.net/lists/listinfo/torcs-devel</=
a><br>
<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Andr=E9s G=F3mez Ram=ED=
rez | Analista de Diagn=F3stico<br>Fluidsignal Group S.A. | Where Security =
Meets Business<br><a href=3D"http://www.fluidsignal.com/" target=3D"_blank"=
>http://www.fluidsignal.com/</a> | ISO 9001:2008 / ISO 27001:2005<br>
Tel=E9fono: +57 (4)=A04442637 | M=F3vil: +57 3012009712<br>
--14dae93b5c8c93c22904b4893e60--
--===============1342884223140650984==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
--===============1342884223140650984==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Torcs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/torcs-devel
--===============1342884223140650984==--