13
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ Malicious code is anything that you wouldn't want to run. \$\endgroup\$
    – Esolanging Fruit
    Jun 13, 2017 at 8:04

4 Answers 4

Reset to default
7
\$\begingroup\$

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)
  • violating the user's privacy without permission (e.g. reading password)
  • executing or spread against the user's knowledge or will (i.e. a virus)
\$\endgroup\$
6
  • \$\begingroup\$ It seems that point is still unclear. \$\endgroup\$
    – user2284570
    Aug 3, 2016 at 23:40
  • 1
    \$\begingroup\$ @user2284570 no it's not. In the context of your question, it is asking for code "intending to do harm or damage". \$\endgroup\$
    – Downgoat
    Aug 3, 2016 at 23:58
  • \$\begingroup\$ 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) \$\endgroup\$
    – user2284570
    Aug 5, 2016 at 15:22
  • \$\begingroup\$ @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 \$\endgroup\$
    – Downgoat
    Aug 5, 2016 at 19:28
  • \$\begingroup\$ 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. \$\endgroup\$
    – user2284570
    Aug 5, 2016 at 20:52
  • \$\begingroup\$ 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()). \$\endgroup\$
    – user2284570
    Aug 5, 2016 at 21:05
7
\$\begingroup\$

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.

\$\endgroup\$
10
  • \$\begingroup\$ Community wiki so everybody can add to the list. \$\endgroup\$
    – Dennis
    Aug 5, 2016 at 16:44
  • 3
    \$\begingroup\$ 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. \$\endgroup\$
    – feersum
    Aug 5, 2016 at 16:45
  • \$\begingroup\$ What if I crashed the online interpreter? \$\endgroup\$
    – Leaky Nun
    Aug 5, 2016 at 16:46
  • 1
    \$\begingroup\$ @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. \$\endgroup\$
    – Dennis
    Aug 5, 2016 at 16:47
  • 1
    \$\begingroup\$ @LeakyNun As long as it interferes only with that process and does not interrupt the service in any way, that's fine. \$\endgroup\$
    – Dennis
    Aug 5, 2016 at 16:49
  • \$\begingroup\$ @Dennis In my online interpreter whatever causes it to run forever would make the server down \$\endgroup\$
    – Leaky Nun
    Aug 5, 2016 at 16:49
  • 1
    \$\begingroup\$ @LeakyNun Then it's not acceptable. Also, running forever and crashing are mutually exclusive. \$\endgroup\$
    – Dennis
    Aug 5, 2016 at 16:50
  • \$\begingroup\$ @LeakyNun : but in my case, leaving the parser accessible from the web is like leaving your car unlocked. \$\endgroup\$
    – user2284570
    Aug 5, 2016 at 16:56
  • \$\begingroup\$ @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. \$\endgroup\$
    – AdmBorkBork
    Aug 5, 2016 at 17:55
  • 1
    \$\begingroup\$ @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.) \$\endgroup\$
    – Poke
    Aug 5, 2016 at 19:32
6
\$\begingroup\$

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).

\$\endgroup\$
2
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – DJMcMayhem
    Apr 4, 2016 at 1:15
  • \$\begingroup\$ @Mego : It seems that point is still unclear. \$\endgroup\$
    – user2284570
    Aug 3, 2016 at 23:40
-2
\$\begingroup\$

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.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – Dennis
    Aug 5, 2016 at 15:50
  • \$\begingroup\$ 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). \$\endgroup\$
    – trichoplax is on Codidact now
    Aug 5, 2016 at 18:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .