Explains the security vulnerability process caused by bash Code injection.

Recently, a "destruction-level" vulnerability-Bash software security vulnerability has emerged. This vulnerability was discovered by St & eacute; phane Chazelas, a French GNU/Linux enthusiast. Subsequently, the US Computer Emergency Response Center (US-CERT), RedHat and a number of security companies issued a warning on Wednesday (September 24 Beijing time. For details about this security vulnerability, see the two disclosure vulnerabilities of US government computing security: CVE-2014-6271 and CVE-2014-7169.

This vulnerability is actually a classic injection attack, that is, it can inject a command into bash, from bash1.14 to 4.3. Let's take a look at the symptoms of this security issue.

Shellshock (CVE-2014-6271)

The following is a simple test:

$ Env VAR = '() {:;}; echo Bash is vulnerable! 'Bash-c "echo bash Test"

If you find that the above Command has such output in your bash, it indicates that your bash has a vulnerability:

Bash is vulnerable!
Bash Test

To put it simply, we inject a piece of code echo Bash is vulnerable into the environment variable. I will give you the principles in this article later.

Soon, the CVE-2014-6271's Official Patch came out-Bash-4.3 Official Patch 25.

AfterShock-CVE-2014-7169 (also called Incomplete fix to Shellshock)

However, someone immediately posted a post on Twitter, saying that this is an incomplete fix, and provided related attack methods.

 

That is, the following test code (note that sh is equivalent to bash in linux ):

1env X = '() {(a) => 'sh-c "echo date"; cat echo

When the code above runs, an error is reported, but what it requires is an error. After the error is reported, an echo file is generated in the current directory. The content of this file is a time text. The following figure shows how the preceding command is executed.

$ Env X = '() {(a) => 'sh-c "echo date"; cat echo
Sh: X: line 1: syntax error near unexpected token '='
Sh: X: line 1 :''
Sh: error importing function definition for 'X'
Sat Sep 27 22:06:29 CST 2014

This test script code is quite strange. Like "Tianshu", I will explain in detail the principle of this code later.

Principles and technical details

To clarify the principles and details, we need to start with the bash environment variables.

Bash environment variables

Everyone knows about environment variables. I don't need to popularize this. Environment variables are the variables in the shell running in the operating system. Many programs change their execution behavior through environment variables. In bash, the syntax for defining an environment variable is very simple (note: there cannot be spaces before and after the = sign ):

$ Var = "hello world"

Then you can use this variable, such as echo $ var or something. However, we need to know that this variable is only a "local variable" of the current shell and can only be accessed in the current shell process. The process fork of this shell process cannot be accessed.

You can perform the following tests:

$ Var = "hello coolshell"
$ Echo $ var
Hello coolshell
$ Bash
$ Echo $ var

In the above test, the third command executes a bash, that is, a bash sub-process, and you will find that var cannot be accessed.

In order for the shell sub-process to be accessible, we need to execute the following export:

$ Export var = "hello coolshell"

In this way, the environment variable will be visible in its child processes.

If you want to check which environment variables can be visible in the sub-process (that is, whether they are export), you can use the env command. However, the env command can also be used to define the environment variables of the export. As follows:

$ Env var = "hello haoel"

With these basic knowledge, we still need to know a basic knowledge-shell function.

Bash functions

Defining a function in bash is simple, as shown below:

$ Foo () {echo "hello coolshell ";}
$ Foo
Hello coolshell

With the above basic environment variable knowledge, you will certainly want to try whether this function can be called in the sub-process, of course, the answer is not.

$ Foo () {echo "hello coolshell ";}
$ Foo
Hello coolshell
$ Bash
$ Foo
Bash: foo: command not found

As you can see, it is the same as the environment variable. If you want to access it in a sub-process, it is still the same. export and export must have a parameter-f, it indicates an export function. For example:

$ Foo () {echo "hello coolshell ";}
$ Foo
Hello coolshell
$ Export-f foo
$ Bash
$ Foo
Hello coolshell

Well, I 've been talking about the basic knowledge for so long, so don't bother, you can easily understand what these two vulnerabilities are.

Okay. Now you have to go to the topic.

Bash bug

We can see from the above that bash variables and functions use the same mechanism. If you use the env command to look at the export output, you will see that the variables and functions we defined above are all in, as shown below (I omitted other environment variables ):

$ Env
Var = hello coolshell
Foo = (){
Echo "hello coolshell"
}

In the past, we used the same method-both functions and variables are variables. As a result, you don't need to look at the source code of bash. A smart hacker can guess whether bash determines whether an environment variable is a function or not, and whether its value starts. As a result, an evil mind emerged.

A hacker defines such an environment variable (Note: () and {there must be no less space ):

$ Export X = '() {echo "inside X" ;}; echo "outside X ";'

Env, you will see that X is already in:

$ Env
X = () {echo "inside X" ;}; echo "outside X ";

Then, when we generate a bash sub-process under the current bash shell process, the new sub-process will read the environment variables of all the exports of the parent process, and copied to your own process Space. Obviously, the above X variable function is followed by a command: echo "outside X ", will this be executed when the parent process replicates data to the child process? (For fork-related things, you can take a look at my previous questions about fork.)

The answer is yes.

$ Export X = '() {echo "inside X" ;}; echo "outside X ";'
$ Bash
Outside X

You see, a code injection is done in this way. This is the bash bug-the code of the function in vitro is executed by default.

We do not have to create another bash sub-process as above. We can use bash-c parameters to execute a bash sub-process command. Just like the test script for this security vulnerability:

Env VAR = '() {:;}; echo Bash is vulnerable! 'Bash-c "echo bash Test"

The colon in () {:;} is equivalent to/bin/true. Return true and exit. Bash-c is actually a subprocess of bash echo in spawn, which is used to trigger the echo command of the function in vitro. Therefore, a more friendly test script should be:

Env VAR = '() {:;}; echo Bash is vulnerable! 'Bash-c "echo if you see vulnerable, it indicates that your bash has security problems"

OK. You should understand what the vulnerability is.

What is the impact of the bash vulnerability?

Many people on the Internet said that the vulnerability was not big. They also said that this issue was only available for websites that run CGI scripts. Currently, no website has used CGI. I rely on it. This is really a brave person.

For example, if your website contains shell commands that call the operating system, such as execute exec in PHP. There are some such requirements, especially for programs that need to be used for system management in an important background for interaction with the operating system. Then a bash process is run.

We also know that the current HTTP server is basically a sub-process type, so there will inevitably be export some environment variables, the value of some environment variables comes from the user end. For example, the environment variables such as HTTP_USER_AGENT are only sent by the browser. In fact, you can write this variable as anything you want.

So I can set the HTTP_USER_AGENT environment variable to the test script above, but I will set echo Bash is vulnerable! This is replaced by other more brutal commands. Haha.

You can Google the existing systems affected by this vulnerability. Almost all articles about this vulnerability have been mentioned (for example, this article). I will not repeat it here.

Note: If you want to see if your website has such a problem, you can use this online Tool to Test: 'Shellshock' Bash Vulnerability CVE-2014-6271 Test Tool.

Now, you know this may be a big deal. Patch is not urgent yet. (Note: yum update bash upgrades bash to 4.1.2-15. el6_5.2 ,)

Explanation of AfterShock-CVE-2014-7169 test script

Many of you have not understood what this test script means. I will explain it here.

Env X = '() {(a) => 'sh-c "echo date"; cat echo

X = '() {(a) =>' needless to say, define an environment variable of X. However, this function is incomplete. Yes, it is intentional. In addition, you must note that 'is not used to escape single quotes. The value of X is () {(a) =>

(A) = the purpose of this item is to make the bash interpreter wrong (syntax error ).

After a syntax error occurs, only the ">" characters are left in the buffer zone.

Therefore, this magic bash will put the echo date command in the buffer and then execute it.

It is equivalent to executing the following command in shell:

$>
Echo date

If you understand bash, you will know that it is used for line feed on the command line, and thus it is equivalent to executing:

$> Echo date

Isn't that a redirection? The preceding command is equivalent:

$ Date> echo

Therefore, an echo file will appear in your current directory. The content of this file is the output of the date command.

The person who can find this method is really abnormal. It is completely an attack tailored for the source code of bash.