posted 2022-09-09
The Singular interface (as opposed to its library of Singular code) uses fixed paths under the world-writable /tmp for log files and as scratch space for the debugger. This can be exploited in well-known ways. In particular, an attacker can make Singular overwrite files belonging to the Singular user, or in rare cases, to execute code.
When Singular-4.3.0 and earlier are launched with the --log flag, the input is logged to a predictable path under /tmp unconditionally, as can be seen in Singular/tesths.cc:
int main( /* main entry to Singular */
int argc, /* number of parameter */
char** argv) /* parameter array */
{
...
if (feOptValue(FE_OPT_LOG))
{
int pid=getpid();
char buf[20];
sprintf(buf,"/tmp/sing_log.%d",pid);
File_Log=fopen(buf,"w");
}
...
}The Singular debugger sdb (Singular/sdb.cc), when editing code in-place, will also use a predictable path under /tmp:
void sdb_edit(procinfo *pi)
{
char * filename = omStrDup("/tmp/sd000000");
sprintf(filename+7,"%d",getpid());
FILE *fp=fopen(filename,"w");
...
}Both of these can be exploited in familiar ways to clobber files owned by the Singular user. The sdb vulnerability can also lead to code execution if the attacker is able to modify the code snippet as it is being loaded from the scratch file back into Singular.
The logfile issue was resolved in commit 72df188
by making the --log flag take a mandatory parameter
specifying the filename. Presumably the user will not specify a
world-writable path. The sdb issue was resolved in commit 5f28fbf0
by using mkstemp() to create the scratch file.