Dear Ladies and Gentlemen
I use GnuPlot version 5.4 patch level 8. The Sentinel One software is also installed on our university's computers. This brings the following warning "A vulnerability classified as critical has been found in Gnuplot 5.4. Affected is the function com_line of the file command.c."
Maybe someone would have a clue as to what is causing this warning.
Many many thanks
From the point of view of security analysis, gnuplot is a "shell". That means any command a user can give to the computer directly can also be issued by gnuplot if the user requests it. For a simple example, the user might type a command (or do a drag-and-drop mouse movement) that tells the computer "copy file A to another file folder B". This would create a new file A in folder B. Similarly if you tell gnuplot
set output 'B/A'; plot x
it will create a new file A in folder B.But what if the user does not have permission to write into folder B? The computer will (or anyway is supposed to) reject the command and not create the new file. If a security monitoring program is watching this and sees that the user tried to write somewhere not allowed, it may issue a warning. I am guessing that in your case the Sentinel One noticed something like this and reported whatever program was running at the time the disallowed command was made, which happened to be gnuplot. So maybe a mis-typed file name, or an attempt to write an output file in someone else's disk area?
Anyhow this does not look like a program bug; just an over-zealous security check that emits scary-looking warning messages.
A Google search for the keywords "volunarability com_line command.c" will find the page "https://nvd.nist.gov/vuln/detail/CVE-2020-25412". The vulnerability listed on this page is related to [bugs:#2303].
Is the SentinelOne's warning related to this?
If so, it is likely to have been fixed in later versions.
Related
Bugs:
#2303{shrug]. Bug #2303 was fixed already in 5.4.1 so it should not be relevant to this report. That one was a real bug that could be triggered by mis-typing a font name. But it did not involve anything in the subroutine command.c:com_line().
The thing is, that subroutine probably appears in a stack trace from many or even most gnuplot errors, not because of anything local to that subroutine, which is short, but just because it is an early step on the path from reading in a single line of input and sending it to be parsed and executed.
So even if this report from Sentinel One is "real" in the sense that it is a fixable error in gnuplot rather than just a user typo, there is not enough information given to locate where in the code it might actually lie.