Shell script Security

Shell script Security
"#!" Is displayed in the Shell script. /Bin/sh-"usage," #! "/Bin/sh" indicates the Shell type interpreted by the command line. The common type is the sub-type (dialect) Bash Shell of the Bourne Shell, "-" or "-" indicates the termination of the option. The content after this flag will be interpreted by Shell as a parameter. This method was previously used to avoid spoofing attacks based on the setuid Shell script, but this attack method is no longer feasible (the current Linux system does not support the setuid permission of the Shell script ).

But the problem persists. Shell scripts, as command line interpreters, are often ignored by developers, because attacks on scripts often mean that attackers can execute their own scripts, script attacks are not very significant. However, the security configuration of * nix system and the role of Shell scripts in application development and application processing make the security of Shell scripts equally meaningful, after all, there are boundaries for convenient interaction and security problems for border convenience. These boundaries include:

Process network requests as CGI scripts on the Web server;

Read the file content on the system and perform related operations;

Receives client or server requests to complete Web queries (such as curl );

Even if there is no interaction boundary at the network layer, there may be excessive permissions between users of different systems at the local layer of the host. The following describes the security issues that need to be paid attention to when writing Shell scripts.
I. Environment Variable attacks environment variable attacks are the most common way to manipulate script behavior. By modifying environment variables, attackers can change the execution process or result of a script dependent on the environment variable value. The most frequently modified environment variable is PATH. The PATH set of the variable value determines the PATH and PATH query sequence of the command after you enter a separate command that does not contain the complete PATH.
Under normal circumstances, commands are ordered in paths such as/usr/local/sbin,/usr/local/bin,/bin,/sbin,/usr/bin,/usr/sbin, etc. search and execute, for example, the following script target. sh:

#!/bin/sh ls -a

Assume that the attacker creates a Shell file named ls in the same PATH of the preceding script and uses the following command to modify the PATH value of the environment variable:

export PATH=.:$PATH

The Shell script named ls created in the current path:

#!/bin/sh echo "I'm not ls command"

Because the current directory is the first path for command search, When you execute target. sh or even enter the ls command, the "I'm not ls command" IS DISPLAYED rather than the expected result.
To avoid this type of attack, make sure that the PATH value of the environment variable is correct before executing the Shell script, or directly use the absolute PATH command to perform the operation.
II. General Writable Path file attacks 1. Temporary File attacks assume that you store some private information in the temporary directory/tmp as temporary files. The following script secret. sh is used:

#!/bin/sh SECRET="My boyfriend is a gay" echo "$SECRET" > /tmp/mysecret

Because the default permission of the/tmp path is drwxrwxrwt, other users in the same system can read the mysecret file in the/tmp directory without authorization, or monitor the creation of/tmp/mysecret files by creating scripts or binary execution files, and read the files after detecting the existence of the files.
There are two ways to avoid such events:

Use umask to set the initial permissions for file creation (the default value of umask is 0022). Cancel the read, write, and execute permissions for the same group and other users, such as umask 0066 ".

Use the mktemp command to create a temporary file. This command specifies to set the default file permission in the "umask 0066" mode.

However, these two methods still cannot avoid the following attack scenarios.

Input File attack

The input file attack is similar to the temporary file attack, as shown in the following script secret. sh:

#!/bin/sh echo "My password is drowsspa" > /tmp/mypassPASSWORD="$(cat /tmp/mypass)" echo "$PASSWORD" | nc 192.168.1.103 3333

This script reads the contents of the temporary file mypass from the/tmp directory and sends it to port 3333 of 192.168.1.103.

Attackers can execute the following command before creating the/tmp/mypass file:

Link/etc/mypass/tmp/mypass

Or run the following command after the/tmp/mypass file is created:

Unlink/tmp/mypass

Link/etc/mypass/tmp/mypass

When the user is executing secret. after the sh script, the attacker (other users) replaced the target file in the/tmp path and established a file connection, therefore, attackers can access/etc/mypass to view the content in/tmp/mypass.

The modification method is similar to the temporary file attack. One is to create a temporary directory to hide the object name of the target temporary file, and the other is to re-specify the initial permissions of the object.

Use mktemp to create a temporary path and create a temporary file under the temporary path so that other users cannot view the temporary file name and delete or replace the file.

Use umask to specify the initial File Permission when creating a temporary file.

Iii. injection attacks

Injection attacks are the most common in Shell script attacks. They are similar to injection attacks in Web attacks. This attack occurs when the script reads the variable values entered by the user and stores them in the script variables. As shown in the following injection. sh script example:

#!/bin/sh if [ x$1 = xpass ]; then  echo $1  eval $2 fi echo ls $1 > myscript.shchmod a+x myscript.sh./myscript.sh

The preceding script has three security issues:

1. Parameter 1 has the injection vulnerability. Attackers can bypass the if condition judgment through construction parameters, such as "foo = xfoo-o x", where "-o" is similar to the logical operation "or ", in this way, statements in the condition body can be executed by bypassing the condition judgment.

2. Parameter 2 has the Data Execution Vulnerability. The attacker passes the command to be operated as parameter 2, causing the command to be executed.

3. The content of parameter 1 is executed as a parameter of the ls command and the execution result is written to the script for execution. The command Truncation Vulnerability exists. For example, ". | rm-f filename ".

The corresponding modification method is as follows:

1. Double quotation marks are used for parameters and strings on both sides of the equal sign in condition judgment, as follows:

If ["$1" = "pass"]; then

2. Never use "eval variable.

3. Modify the echo statement as follows:

Echo ls "\" \ $1 \ ""> myscript. sh

This method is in injection. when the sh script is executed, it does not expand $1, but redirects the output to myscript according to the "$1" parameter. in the sh script, the premise is that 1 has been set in the environment variable before the myscript. sh expands and executes the variable (the environment variable cannot start with a number, so it cannot be set to environment variable 1 ).

Besides network Leakage

In addition, there is also a class of Shell script security issues, that is. profile ,. the environment variable settings and alias settings in the bashrc file are secure. For the Bash Shell interpreter, you can add the "-p" option to enable the privileged mode when declaring the interpreter in the script file, p is "privileged ". For example:

#!/bin/sh -p

When the privileged mode is enabled, the Shell script interpreter ignores the interpretation of environment variables and. profile ,. for the content of the bashrc file, run the Shell script in debug tracing mode with "bash-x" to see the difference between privileged mode and non-privileged mode.

The so-called one thousand attack, self-loss eight hundred, the problem of enabling the privileged mode is that after a valid user starts the Shell, the valid user will not be reset to the real user, otherwise the valid user will be automatically reset to the real user.