# List of dangerous functions

I no longer believe it is a good idea to work with a list of dangerous functions. I have tried to edit the question is such a way that it respects my earlier perspective, but also so that it does not give users the impression that certain things are safe whereas they are not.

Introduction

Running Mathematica code from an untrusted source is very dangerous. Luckily, Mathematica warns you about dynamic content, so that it is probably safe to open any notebook, as long as you don't run it.

I feel it would be very nice to have a list of functions that can harm a system. Using this, we may be able to make a function that checks if a notebook is safe.

A function to find dangerous functions

A naive function to see if dangerous expressions are present in a NotebookObject, could be the following.

Through[{Unprotect, ClearAll}[dangerousFunctionsQ]]

dangerousFunctionsQ[nb_] := !
FreeQ[ToExpression[Unevaluated[#], StandardForm,
HoldComplete] & /@ (NotebookRead@Cells[nb])[[All, 1]],
Alternatives @@ listOfDangerousFunctions];

Protect[dangerousFunctionsQ];


Where listOfDangerousFunctions is given. Unfortunately, this code does not guarantee safety, even we know the full list of dangerous functions.

Furthermore, getting the NotebookObject is a bit tricky. We could simply open the notebook and use Notebooks, but opening the notebook doesn't sound too safe. Also making an automated approach based on this is inelegant. Note however, that using the obvious alternative, which is to use Import (with one argument) on the notebook file turns out not to be safe.

The question is: Which built-in functions are dangerous (especially just by themselves)?

Related

In a CDF can I suppress or avoid “This file contains potentially unsafe dynamic content…”

-
Important indeed! I have often been scared by the potential dangers of Mathematica files of unknown origins. –  Sjoerd C. de Vries Jul 28 '13 at 16:04
@SjoerdC.deVries and everyone else: If you think some technique is really dangerous or that it will cause more people to try to abuse than that it will help others to prevent abuse, please do not add such techniques. Also let me know if you feel I have added to much already, though I think nothing here is really advanced. –  Jacob Akkerboom Jul 28 '13 at 16:11
Pretty sure I recall seeing the dangerous functions in one of the *.tr files. –  Mike Honeychurch Jul 28 '13 at 22:09

Honestly, Mathematica is so flexible and has so many undocumented functions tucked away in nooks that I think it would be better to create a white-list of safe functions than to try to list all potentially dangerous ones.

Better still would be to simply run Mathematica on a virtual machine or in an instance of Sandboxie where no damage is permanent (excepting privacy issues if network access is not blocked).

-
@JacobAkkerboom Range/Table/Array/ConstantArray--can exhaust all of the machine's memory unless wrapped in MemoryConstrained. $RecursionLimit--if set to infinity, one can crash Mathematica at will. Dot--matrix multiplication can easily consume all available CPU resources and effect a DoS attack. Mr. Wizard is IMO quite correct that whitelisting is the only workable approach, and indeed this is exactly what WRI does for CDFs and for the browser plugin. – Oleksandr R. Jul 28 '13 at 20:53 @OleksandrR. Good points. Thanks for adding to the lists :). It is also important to know that Wolfram uses whitelists, potentially that would mean even obscure functions could be not safe. But the kind of attacks you point out are in my opinion nowhere near as threatening as taking over ones computer (discretely or otherwise). I feel approaches like: a) Either you can trust somebody or you can't at all, or b) a function can either be used harmfully or not at all, are not the most constructive. Today I executed some code by Nasser. I do not trust him blindly but skimming through his code – Jacob Akkerboom Jul 28 '13 at 21:10 feels like its enough of a safeguard, right? – Jacob Akkerboom Jul 28 '13 at 21:10 I have accepted your answer. I am a bit disappointed about this design choice, but I these investigations have been very useful. Maybe a whitelist can be made by doing something like DeleteCases[Names[Alternatives@@safeContexts~~"'*"], dangerousSymbols]. Maybe that could be quite nice :). – Jacob Akkerboom Jul 29 '13 at 0:07 @Jacob Sorry I didn't have a more pleasing answer for you, but thanks for the Accept nevertheless. – Mr.Wizard Jul 29 '13 at 12:06 The dangerous symbols are contained in MiscExpressions.tr - Great! This should the location on all OSes: FileNameJoin[{$InstallationDirectory, "SystemFiles", "FrontEnd", "TextResources", "MiscExpressions.tr"}] –  Jacob Akkerboom Jul 28 '13 at 22:45
I have to wonder if that list is really complete. I bet someone with special knowledge could cause trouble with Raw for example. –  Mr.Wizard Jul 28 '13 at 22:52
@Mr.Wizard also for your own functions existence of DownValues can cause a security warning. Have related before that last year for me a tick function caused a warning but changing to a pure tick function was fine. –  Mike Honeychurch Jul 28 '13 at 23:11
Possibly also missing: 'System'ConvertersDump'ImportTest'. It would seem that is the function that does most of the work of Import. After importing a file, you can remove attribute ReadProtected from Import and see that it just refers to this function. You can also code of ImportTest, but this is really hard to read. –  Jacob Akkerboom Jul 28 '13 at 23:19
Through[{ClearAttributes[#, ReadProtected] &, Information}@ "ImportExport'FileUtilities'DeleteFileOrDir"]; (sorry for the bad delimiters). I feel I have to agree with @Mr.Wizards answer now :O –  Jacob Akkerboom Jul 28 '13 at 23:26

Throughout this answer, direct and indirect are used to mean directness in the sense of dependence of a function on other functions to do harm. A directly dangerous function is then a function that needs no other functions to do harm. I state dangerous combinations in cases only a combination of such functions is dangerous. Directness is the factor in the structure of this answer.

I think a good way to find dangerous functions is the documentation entry about notebook security. Especially the table below is a nice place to start

## Directly dangerous and really nasty

{Get, Put, DeleteFile, RenameFile, Run, RunThrough,


1) Dangerous combinations

OpenAppend/OpenWrite + any write function LoadJavaClass + any function to use functions from a java class.

2) Functions that are dangerous if other powerful programs are available

{Install, Import, NotebookGet}


Notes: Export and Put can overwrite files. RenameFile cannot overwrite files, but it can move a file and then replace it with another, which seems very dangerous to me. Possibly SetOptions should be included. Another candidate is SetSystemOptions. Mathematica evaluates the result of Import, which makes Import dangerous. Possibly Install always has access to powerful code and is dangerous in any context. Read and ReadList can be used to execute commands, as can OpenRead. Missing here are: NetLink functions. SendMail can send files as attachments.

## Indirectly dangerous

Below are indirectly dangerous functions, but they are especially dangerous in the sense that a function that checks for dangerous functions may be fooled by these

Functions that convert strings to code

{Uncompress, ToExpression, Symbol}


Notes: Symbol can be used to generate the symbols/functions we want to ban.

Expression fetching functions

By "expression fetching functions", functions are meant that import Mathematica expressions, from which dangerous functions can be extracted. This is a danger even if the Mathematica expressions themselves are harmless.

{Import}


Box converting functions

{MakeExpression, ToExpression}


## Others

Functions that can be undesirable and that do not depend on other functions (much less of an issue)

{CopyFile, SetFileDate, SetDirectory (*kind of silly*)}


## Remarks

If enough functions get listed, I will assemble them into lists of useful combinations so that you do not have to copy and paste and then join these yourselves.

Feel free to add functions to this answer, I am sure the lists are not complete yet.

-
Add Read and ReadList to the list, as they can be used to execute external commands (see this). –  Sjoerd C. de Vries Jul 28 '13 at 16:00
@SjoerdC.deVries I have tried to consider those to be special case of abuse by converting Boxes to expressions. If there is abuse possible without using MakeExpression or ToExpression feel free to add them. I suppose we should at least mention them :) –  Jacob Akkerboom Jul 28 '13 at 16:13
I'm on vacation and using my iPad. So anything other than small edits is a real pain. –  Sjoerd C. de Vries Jul 28 '13 at 16:18
Not dangerous, except perhaps to your privacy: SendMail –  Sjoerd C. de Vries Jul 28 '13 at 16:45