# What qualifies as malicious code?

We've decided by community consensus that challenges asking for malicious code are off topic. But the question remains: At what point do we consider code to be malicious? Most of the time it's extremely obvious, but sometimes it's more subtle. For example, if code could be used maliciously, even if it isn't the intent of the challenge author, do we consider it malicious?

Some examples:

I realize it's difficult to make an overarching judgement for this, but it would be good to have some kind of guiding principle.

• Malicious code is anything that you wouldn't want to run. – Esolanging Fruit Jun 13 '17 at 8:04

Anything "malicious" I'd say would fall into one of the following categories:

• intending or intended to do harm or damage (e.g. sudo rm -rf / --no-preserve-root)
• doing anything against the user's will / deceiving the user (e.g. Skynet or Ultron)
• executing or spread against the user's knowledge or will (i.e. a virus)
• It seems that point is still unclear. – user2284570 Aug 3 '16 at 23:40
• @user2284570 no it's not. In the context of your question, it is asking for code "intending to do harm or damage". – Downgoat Aug 3 '16 at 23:58
• Crashing a program doesn’t harm or damage anything in itself. In the context of my question the parser is known to be insecure which means no web service will provide a way to use it with untrusted code. So for my question an answer can’t even be used for denial of service or remote code execution. Except If you consider that asking how to seal something unlocked is malicious (this won’t prevent other peoples from doing it) – user2284570 Aug 5 '16 at 15:22
• @user2284570 I think you're misunderstanding the context. You're question, if i understand correctly, is asking for code that can hijack a .pyc file to crash the python interpreter. There is no practical use for such a question that I can fathom except for malicious purposes. The problem with your question is not crash the interpreter, it's hijack a .pyc file. It's like asking "shortest code to drop database from SQL injection". Crashing the interpreter is just crashing the interpreter, such a question such as yours is basically developing an exploit of .pyc – Downgoat Aug 5 '16 at 19:28
• asking for code that can hijack a .pyc file to crash the python interpreter. No, you can’t hijack a pycorpyofile. cpython developers stated themselves things like this many time :Hi, corrupted .pyc files are known to be abel to crash Python. What is the point of your bug report? If you are able to execute untrusted .pyc, you can already execute arbitrary code, no? . This is because the.pycparser is insecure by design (there’s many known crash cases). Remember.pycfiles are just the result of .pyfiles after compilation. – user2284570 Aug 5 '16 at 20:52
• That’s why cpyhon developers don’t fix it, because it’s just nonsense. If it’s asking for an exploit for the parser, then simply asking to directly crash the interpreter can be considered of an exploit for a ᴘᴀᴀꜱ service that offer to run only python code.. However, if I would have asked how to crash marshable or cpickle then it would have been different (and in that case they might get fixed in the far future). But my question can be rephrased tocreate an invalid code object from a pyc file (code objects is the thing you pass tothe python equivalent of eval()). – user2284570 Aug 5 '16 at 21:05

Here is a (not exhaustive) list of guidelines I would use for determining if code is malicious:

• Does the user know what they are running? If they know they are going to run a keylogger, the blame is on them if anything bad happens. If they don't know it's a keylogger, then it's more on the malicious side of the line.
• Does the user have control? If the user can stop the program without any damage done (or none that can't easily be prevented or fixed), it's probably not malicious. If the program tries to prevent the user from taking control and terminating it, it's probably malicious.
• Can the user recover from it/safeguard against it? A user can recover from/safeguard against a program that wipes out the current directory (rm -rf .), but not so much against a program that wipes the entire disk (dd if=/dev/zero of=/dev/sda1 or sudo rm -rf --no-preserve-root).

I'll add more guidelines to this list as I think of them (or as they're suggested in comments).

• I'd say the other thing is is how easy it is to recover from. For example Make your language unusable is an awesome challenge. "Brick my hard drive" and "Delete my operating system" are not good challenges. – DJMcMayhem Apr 4 '16 at 1:15
• @Mego : It seems that point is still unclear. – user2284570 Aug 3 '16 at 23:40

## Programs that only crash itself or its compiler/interpreter are on-topic

Our terms of service forbid damaging or detrimentally interfering with the system, so a challenge that asks for this cannot be on-topic. However, if a program interferes solely with its own execution, it cannot cause harm or have any unexpected consequences.

I therefore propose that this kind of challenge is on-topic, provided that it includes (a variant of) the following disclaimer or links to this post.

Your submission may not violate our Terms of Service, Section 3: Subscriber Content. In particular, it may not interfere with other processes, potentially cause loss or theft of data or information, or damage hardware. This includes but is not limited to:

• Terminating any process except the program itself or the interpreter/compiler that is executing it.

• Changing or deleting any files other than the submission's source code/executable or files that have been created by the program itself.

• Creating backdoors or otherwise leaving the system in a vulnerable state.

• Disabling any form of failsafe protection.

• Using excessive amounts of memory.

• Creating an excessive amount of subprocesses.

• Filling up the hard drive.

• Having any side effects that are not clearly stated in the post.

• Community wiki so everybody can add to the list. – Dennis Aug 5 '16 at 16:44
• If using an excessive amount of memory is malicious, then a huge portion of code golf answers that use brute force are malicious. I did create a denial of service on myself once by foolishly running a Python golf answer that used up all the memory and made the OS stop responding to user input. – feersum Aug 5 '16 at 16:45
• What if I crashed the online interpreter? – Leaky Nun Aug 5 '16 at 16:46
• @feersum To me, there's a difference between simply requiring a lot of memory to perform a task and using memory for the sake of using memory. If the intention is to crash something, it should be done by means that cannot affect other processes. – Dennis Aug 5 '16 at 16:47
• @LeakyNun As long as it interferes only with that process and does not interrupt the service in any way, that's fine. – Dennis Aug 5 '16 at 16:49
• @Dennis In my online interpreter whatever causes it to run forever would make the server down – Leaky Nun Aug 5 '16 at 16:49
• @LeakyNun Then it's not acceptable. Also, running forever and crashing are mutually exclusive. – Dennis Aug 5 '16 at 16:50
• @LeakyNun : but in my case, leaving the parser accessible from the web is like leaving your car unlocked. – user2284570 Aug 5 '16 at 16:56
• @Dennis After having read through your post here, I can see the line being drawn between "stuff that detrimentally impacts itself" vs "stuff that detrimentally impacts something else." Re-evaluating my position, I think this one here is more tenable than my all-or-nothing approach. +1 from me. – AdmBorkBork Aug 5 '16 at 17:55
• @LeakyNun I'd imagine that an online interpreter would have to sandbox the code it's running to some extent to prevent the scenarios you're mentioning. (max runtime, etc.) – Poke Aug 5 '16 at 19:32

# Subtopic: Crashing a program

I think a distinction should be emphasised between programs that crash different things.

• A program that crashes itself only harms the program itself, and only temporarily.
• Crashing a compiler is unlikely to affect any other program unless other programs happen to be being compiled in parallel (I'm assuming this is rare?).
• Crashing an interpreter may affect other programs currently running in the same interpreter. The user may not even realise they are running, or that they are in the same language, so may not think to stop them first.
• Crashing the operating system may lose unsaved work in unrelated programs, which the user running the code may not expect if the challenge only asks for crashing the program itself, or the interpreter or compiler.

It already seems unclear where in this spectrum to draw the line between acceptable and dangerous. On top of that, how often will a solution intended to crash itself/its interpreter end up also inadvertently crashing the operating system? It's hard to estimate this, but with a large number of answerers all trying to find little known bugs, which are also likely to be little understood, it seems fairly likely that one will be submitted that does more damage than intended (perhaps only crashing some operating systems, so the poster doesn't realise their code is dangerous).

For this reason I recommend a stricter policy:

# A challenge asking for a program that crashes itself/its compiler/its interpreter is still off topic

In addition to voting up or down, please comment with any relevant points.

• I think there's a difference between a program and itself, its compiler, or its interpreter. A program that crashes an unrelated process should qualify as malicious in my opinion. Also, considering that your answer mostly seems to be arguing in favor of allowing them, I think it would be less confusing to vote on that option. – Dennis Aug 5 '16 at 15:50
• I hadn't intended to argue in favour. My aim was to point out that although there is a theoretical reason that a program that "only" crashes itself/its compiler/its interpreter is less malicious that one that crashes the operating system, in practice asking for such programs is likely to result in at least some that do more harm than intended. I'll edit to try to make that clearer and to include your finer distinction including compiler/interpreter. I'll keep the conclusion the same to avoid invalidating existing votes (and because I'm leaning more towards that conclusion myself now). – trichoplax Aug 5 '16 at 18:55