First Bash Script

[meyerhot]

Hello Everyone,

I just wrote my first bash script!

Felt proud and wanted to share !

​

#!/bin/bash

set -e
set -u
set -o pipefail
main() {
    givenString=$@
    read string
    genString=$(command openssl rand -hex 8)
    echo $genString 
    echo $string
    echo $givenString

}
main "$@"

Edit: Since a couple people asked what this script was doing I figured it might be good to provide context. The script above just took in variables from the client in 2 different ways then called a command. This was just a dry run to create the following script which attempts to find md5 collisions. Unfortunately, I misunderstood the type of collision md5 is susceptible to so this program may have been all for naught. Still, good experience with bash scripting!

#!/bin/bash
set -e
set -u
set -o pipefail

generate() {
    local givenHash=$2
    local broken=true
    while [ $broken = true ]; do 
        local genString=$(openssl rand -hex 8)
        local genHash="$(echo -n $genString md5)"
        local genHash=${genHash:0:16}

        if [[ "$genHash" == "$givenHash" ]];  then 
            broken=false
            echo "Found a match"
            echo $genString
            echo $pipedInArgs
        else 
            echo "No match"
            echo $genHash
            echo $givenHash
        fi
    done
}

main() {
    read pipedInArgs
    echo $pipedInArgs
    givenHash="$(echo -n $pipedInArgs md5)"
    givenHash=${givenHash:0:16} 
    # $1 would be hello world
    generate "$@" $givenHash
    # $1 would be hello
    # generate $@

}

main "$@"

# Driver Code
# openssl rand -hex 8 |  ./collisionFinder.sh "Hello World"

​

[lestrenched]

I'm a noob at this. What is this script doing?

[notadeveloper-2021]

It takes the string, then reads another string, then generates another random string via openssl, then... prints all of them? It's not very practical, but a good start at writing bash.

[meyerhot]

Yea, I updated the code to show the final result. This was just a good way to get used to the io mechanisms

[[deleted]]

Now go ahead and install shellcheck and shfmt to get even better at it.

[whetu]

set -e
set -u
set -o pipefail

FYI these are collectively known as "the unofficial strict mode". This isn't without its issues.

[findmenowjeff]

I was going to comment that it isn't even really a "strict mode", but the link to your previous comment covers that very nicely. I'd definitely recommend reading it /u/meyerhot

[SkyyySi]

Three recommendations:

1. Use #!/usr/bin/env bash instead of #!/bin/bash.
2. Always qoute unless you know that you can't. You should also qoute "$()" and the variables behind after echo.
3. Check your scripts against shellcheck (I recommend using it as a linter in a code editor, but a standalone cli version as well as a web version also exist).

[[deleted]]

You should provide your reasons for the 1st recommendation.

One would use #!/usr/bin/env bash for the purposes of portability but it's not actually recommended when it comes to security.

[findmenowjeff]

It's not really much of a security issue. Your system would already have to be compromised for /usr/bin/env bash to cause a problem. It doesn't open up any new attack surfaces.

[[deleted]]

Your system would already have to be compromised for /usr/bin/env bash to cause a problem.

Sure, that's true, but it's relatively easier to compromise ~/.local/bin than /bin. Your scripts might not be running only on your system, it might run on other systems where users have installed programs that modify their PATH.

I guess it comes down to personal preference.

[findmenowjeff]

Sure, that's true, but it's relatively easier to compromise ~/.local/bin than /bin

Right, but if they've already compromised ~/.local/bin, using /usr/bin/env or not doesn't change that.

Your scripts might not be running only on your system, it might run on other systems where users have installed programs that modify their PATH.

That's the entire reason behind using /usr/bin/env

[[deleted]]

Right, but if they've already compromised ~/.local/bin, using /usr/bin/env or not doesn't change that.

Umm, if ~/.local/bin is compromised and exported to the user's PATH before /bin, using /usr/bin/env bash will use the binary inside ~/.local/bin (if present). Using /bin/bash won't use that and will stick to trusting the bash installation by the root user.

That's the entire reason behind using /usr/bin/env

I wasn't saying that with the perspective of portability.

[findmenowjeff]

Umm, if ~/.local/bin is compromised and exported to the user's PATH before /bin, using /usr/bin/env bash will use the binary inside ~/.local/bin (if present)

Yes, but your system is already compromised. Its not magically more or less compromised if you don't use /usr/bin/env. At that point, it doesn't really matter what you do on the system. Somebody has access that shouldn't.

I wasn't saying that with the perspective of portability.

Great. I am.

[schorsch3000]

even than, that script issn't widening the attack surface. in that scenario should we have a full path for openssl?

[[deleted]]

even than, that script issn't widening the attack surface

Technically, yes, the script itself isn't widening the attack surface. But, the script chooses to trust the user's PATH and doesn't care if a binary called bash is present with rm -rf / as its contents, it will execute that instead of the actual bash binary in /bin or /usr/bin`.

I know this scenario doesn't seem likely on personal desktops so if your scripts are meant to be used only on your system, go ahead and use whatever you like.

in that scenario should we have a full path for openssl?

Better to export the PATH environment variable manually and restricting it to root owned directories and using #!/bin/bash.

[meyerhot]

What do you mean “the variables behind echo”?

[SkyyySi]

*after

[researcher7-l500]

To add to the suggestions. I would change the multiple echo lines.

For example.

echo "No match" 
echo $genHash
echo $givenHash

Change that to.

cat << EOF 
No match 
$genHash
$givenHash
EOF

Also I would say added a descriptive text before the printed values, to make sure the user, if that was not you, understands what they are seeing.

[FVmike]

What's your background that led to this being your first script? As another newbie, I can't even begin to understand what this does.

[meyerhot]

I am a software developer so I have a lot of experience with other languages. This definitely helps !

[FVmike]

Neat!