Hi,
I made some changes to the CBS in order to be able to use save string
functions. In the moment you can crash a plplot example quite easily by
enforcing a buffer overrun. E.g. in plargs.c we have the following code:
if (!fl) {
sprintf(msg, "Option '%s' not recognized.\n\nRecognized options
for this driver are:\n", drvp->option);
plwarn(msg);
plHelpDrvOpts(acc_opt);
plexit("");
}
Since the array msg has only 80 bytes, we can easily crash any of our
examples, e.g.:
examples\c\x01c.exe -drvopt
thisisnotsuchalongoptionbutlongenoughmaybetocrashtheprogramwhoknows=666
That is known as buffer overrun and this can be used to corrupt the
stack in a way that bad code will be executed. Anyway, the solution to
this problem is to use save string functions, like snprintf and the
like. But that's not so easy, since these functions are C99 standard and
might not be known at all (although all modern compilers should know
them). And as usual since Microsoft decided to implement this function
before they became standard, they used a different naming convention
(_snprintf, _snscanf) and we need to take care of these "special" naming
guidelines as well. What I did now is checking if snprintf is available
during the cmake configuring stage in plplot.cmake. If snprintf is not
found we are looking for _snprintf. If either of these functions is
found I assume that snscanf exist as well to speed up the configure
stage. Then in plplotP.h I rename functions (_snprintf to snprintf) if
necessary or declare dummy functions which are defined in plctrl.c,
which just call the unsafe functions ignoring the size of the buffer.
This should be tested on all available platforms and compilers and then
we would need to replace all unsafe function calls which might take some
time. So far I replaced some calls in plargs.c and it should be
therefore not possible to crash the examples like shown above.
One other problem is, what to do, if the buffer is full, i.e. not the
whole string could be written to the buffer. Should a warning be issued?
Just ignore it? That's also problematic since the return value might not
be the same for different compilers just complicating everything even more.
Best Regards,
Werner
--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
email: [EMAIL PROTECTED]
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
+43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
