While fixing up a bug Alan found in the familying code due to the use of a 
user-supplied string as a sprintf format string, it occured to me that
we never finished up the work Werner started on checking our string
handling more generally. There are various bugs that can occur using
standard C string-handling routines.

1) Calling printf / sprintf with a user-supplied format string. The
common example here is calling printf(buf) rather than printf("%s",buf).
If buf contains a % then the former can result in illegal memory
access with potential resultant crashes / security implications.

2) sprintf, strcat and strcpy do no kind of checking for buffer
overruns. Malicious user-supplied strings can result in security
problems / crashes. There are various solutions.

a) Use snprintf instead of sprintf which does limit the number of
characters written. snprintf only appeared in C99 and so is not
available on all platforms. On some (e.g. Visual C++) it is only
available as _snprintf. Currently plplot has macros to work round this.
If there is no implementation available the snprintf will just call
sprintf, without any bounds checking. snprintf will always ensure a
null-terminated string.

b) Use formatting characters to limit the size of strings written by
sprintf, e.g. sprintf(outbuf,"%.100s",buf) will only print a maximum of
100 characters.

c) Use strncpy instead of strcpy, which limits the number of bytes
written. Note that this does not guarantee that the string is
null-terminated, so you must all do this.

d) Use strncat instead of strncat, which limits the number of bytes
concatenated. Note that this is the number of bytes added. If this is
not the whole of the source string then an additional null character is
added, and so the number of bytes to write must be no more than
(length of the destination buffer) - (length of current string in dest
buffer) - 1.

e) Ensure that the strings to be written cannot overrun the length of
the buffer provided for them. This might be because you are adding fixed
length strings, memory is allocated dynamically using malloc first or
because strlen has been called to check the length of the strings.

In summary, never write to a string unless you are sure the result will
fit, or there is some check in place to prevent overrun.

I have fixed up the main plplot src/ directory and some of the drivers
for 1) and 2). I have not fixed up some old drivers which are disabled 
by default (ntk, pstex, next) and I have not fixed xwinttf.

I will try and put together some notes for the plplot wiki on string
handling style to avoid security issues. More generally a programmers
style guide might be useful anyway.

Andrew

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to