#829 'set mouse mouseformat' directly passing user defined format to 'snprintf()'

[Hiroki Motoyoshi]

In the current implementation of the command 'set mouse mouseformat USER-DEFINED-FORMAT', the format string provided by the user is passed directly to 'snprintf()' without any validation. While this typically does not cause issues when a well-formed format string is used, this approach is considered vulnerable and is not recommended (see Uncontrolled Format Strings).

Fortunately, gnuplot provides an internal function called 'f_sprintf()'. For this issue, since we only need to format two numeric values, x and y, it is preferable to use the internal 'f_sprintf()' function instead of the system's 'snprintf()'. The 'f_sprintf()' function is aware of the number of arguments and offers greater robustness against malformed format strings, as the formatting process is strictly controlled.

I have created a trial patch based on this approach.

[Ethan Merritt]

I worry about having mouse-tracking involve the evaluation stack. Since mouse tracking is asynchronous with the general program flow, I think there would be a possibility of stack corruption if both the main thread and the mouse-tracking thread were pushing and popping operations on the stack. I realize that if this is really a problem, it already exists in principle when you attach commands to a hot key using the bind command. But responding to a bound hotkey is a rare, single-shot, operation compared to continuous mouse tracking. I worry that the only reason we don't see corruption from hotkey operations is that the main program is usually quiescent while the user is interacting with the plot window, and hotkey operations cannot (I think) interrupt each other.

On the other hand, I do not buy the argument that deliberately malformed format strings are a "vulnerability" for an application like gnuplot. Normal operation of gnuplot already allows a user to read/write arbitrary files and issue system shell commands. If that user wants to trash their own files or crash the program, they don't need to do anything as complex as constructing a malformed format string. It would of course be a "vulnerability" If the user could trash someone else's files, but in that case the real security flaw would lie somewhere deeper in the operating system and would remain a vulnerability even if the gnuplot source code were changed.

[Ethan Merritt]

I have been trying to either confirm or disprove my concern that calling f_sprintf() from inside mouse handling might corrupt the evaluation stack. So far I have not been able to trigger any visible failure while testing. Furthermore an explicit test for stack depth added to the new mouse code never detects being called while the stack is active.

So at least tentatively I conclude that the patch is safe, or at least unlikely to trigger an error in practice.

As to the patch itself - If the program is going to call into its own formatting routines rather than using sprintf() directly, wouldn't it make more sense to call f_gprintf() rather than f_sprintf()? That way it could handle coordinates in time/date format as well as purely numeric output.