New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Insecure /tmp usage due to predictable paths #1137
Comments
|
should be fixed with 72df188 |
|
For the logs I think this is sufficient, but for the rest, the problem is much larger than just shell characters being injected. Here's a real example that takes advantage of the predictable files used by the sdb debugger.
There are more clever (and more automated) variants of this. The fundamental problem is that when using a predictable filename under |
|
I see you fixed the sdb issue in 5f28fbf, thanks =) I think that leaves only the more difficult problem of obtaining temporary file and directory names within singular code. For example, in is attempting to create the file safely -- at least without a collision -- but will not fail if someone has pre-created all 2147483647 possible files and made them writable. Similarly, when you need to run several commands in a row as in the shell will blindly proceed even if someone else has e.g. created a malicious dvi file beforehand, causing you to process his file after "latex" fails to write its output. In the first case, you would like to obtain the temporary filename atomically, and fail if it cannot be done. In the second case, you'd like to run the latex pipeline all within one temporary directory, having obtained that temporary directory securely. For those reasons I think it would be a good idea to wrap the C functions |
I just noticed commit ed2fd9b which led me to
git grep /tmpin the codebase. There are several places where a fixed (or at least predictable) path under/tmpis used for temporary storage. This creates a general class of vulnerability that can usually be exploited by other users on the same machine.For example, since
/tmpis world-writable, anyone on the machine can create/tmp/sing_log.1through/tmp/sing_log.65535, making themselves the owner of those files. Later, singular will open and write to them as some other user, namely whoever is running singular. In an extreme case, if singular is running as root, and if the bad guy has created/tmp/sing_log.Nas links pointing to important system files, then logging can erase (overwrite) those files.I haven't tried to exploit them all, but in a few other cases, temporary files are used to store data or commands that are fed to other programs, which makes some level of code execution likely.
The
mkstemp()function is a safe replacement within C, but would have to be exposed to the user somehow to avoid the same problem in singular code.The text was updated successfully, but these errors were encountered: