Matlab's scripts use /tmp/$$a and may clobber it, allowing an attacker to "wipe out" any file belonging to the Matlab user. Suppose the attacker guesses what PID will be used next and creates a symlink with
ln -s ~victim/.profile /tmp/PIDa
And then waits for the victim to run matlab: the victim's .profile gets overwritten with garbage. (If root ever uses Matlab then any file, e.g. /etc/passwd, could similarly be trashed.)
It might be argued that it is hard to guess what PID will be used next. It is easy enough to create a few thousand symlinks with likely PIDs; in fact the attacker could create a symlink for every possible PID (as these normally range from 0 to 32k or 64k).
The mex script may similarly clobber both /tmp/$$a and /tmp/$$b. Worse, it sources (executes) any existing /tmp/$$a script, allowing an attacker to execute any commands as the mex user. Proof-of-concept:
echo 'echo You lose: rm -rf $HOME >> $HOME/.profile' > /tmp/evil
perl -e 'for (1..32000) { symlink "/tmp/$_a", "/tmp/evil" }'
Then wait for any victim to use mex (if root ever uses mex then any actions may be taken).
Vendor response:
5 Dec 2002 MathWorks notified
10 Dec 2002 case ID is: 1034529
16 Dec 2002 engineers [will] try to validate
18 Dec 2002 working on a solution for the next release of MATLAB R14
18 Dec 2002 if you have a WORKING fix ... [recommend] comp.soft-sys.matlab
Workaround:
Paul suggests you use something similar to the following patches. (Standard textbook techniques: use a safe directory, and do not use files at all.)
