Shellshock analysis CVE-2014-6271

Shellshock analysis CVE-2014-6271

Some time ago, the shell-breaking vulnerabilities made various companies very busy. The vulnerabilities have been around for a while, and the analysis of the Internet has also been transferred. When they stop, it's time for me to collect data to digest the vulnerability.

Vulnerability Overview

GNU Bash 4.3 and earlier versions have security vulnerabilities when evaluating some constructed environment variables. Adding additional strings to the function definitions in the environment variable values triggers this vulnerability, attackers can exploit this vulnerability to change or bypass environmental restrictions to execute Shell commands. Some services and applications allow unauthenticated remote attackers to provide environment variables to exploit this vulnerability. This vulnerability is caused by the creation of environment variables with constructed values before Bash Shell is called. These variables can contain code and will be executed immediately after the Shell is called.

The severity of the Shell Cracking vulnerability is defined as 10 (highest). In April this year, the OpenSSL heartbleed vulnerability was only 5!

Why is this vulnerability so popular?

1. The vulnerability has a wide range of impact and has been present for a long time.

Bash, a Unix shell. The first official version was released in 1989. It was originally intended to be used on the GNU operating system, but can run on most Unix-like operating systems, both Linux and Mac OS X v10.4 use it as the default shell. It is also ported to Cygwin and MinGW on Microsoft Windows, or a DJGPP project that can be used on a MS-DOS. It is also transplanted on Novell NetWare and Android.

Therefore, this vulnerability exists in mainstream Linux and MacOSX operating systems. This vulnerability affects various applications that interact with bash, such as HTTP, FTP, and DHCP.

The problematic bash code has existed for more than 20 years.

Vulnerability Principle

To understand this vulnerability, you must first know what the bash environment variable is. The following is a reference to the article about the left ear mouse.

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:

$ Exportvar = "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:

$ Envvar = "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: commandnot 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

Bash vulnerability test code

Run the following code in Bash Shell:

Env x = '() {:;}; echo vulnerable' bash-c "echo this is a test"
If the output is:
Vulnerable

This is a test

Indicates a vulnerability exists. After a patch is installed, the following error is returned:

Bash: Warning: x: ignoring function definition attempt

Bash: 'X' Function Definition import Error

This is a test

Principle Analysis

Variables can be defined in Shell, and a variable named x is defined in POC. The content is a string:
() {:;}; Echo vulnerable
According to the vulnerability information, the vulnerability occurs when Shell executes the command after the function body when processing the function definition. But here the value of x is a string. How does it convert to a function.

In reality, this is related to Bash implementation. In Bash, a function is defined in the format:
Function function_name (){
Body;
}
When Bash initializes environment variables and the syntax parser finds parentheses and braces, it is considered as a function definition:
[Lu4nx @ lx-pc ~] $ Say_hello = '() {echo hello world ;}'
[Lu4nx @ lx-pc ~] $ Export say_hello
[Lu4nx @ lx-pc ~] $ Bash-c 'say _ hello'
Hello world
In the new Bash process, say_hello is a function in the new environment. Its evolution process is as follows:

1. When the new bash is started, the environment variable say_hello is scanned with parentheses and braces, which are determined to be a function definition.

2. bash uses say_hello as the function name and its value as the function body.

The typeset command can list all variables and function definitions in the current environment. Let's use typeset to see how this string becomes a function. Continue with the say_hello function defined above:
[Lu4nx @ lx-pc ~] $ Bash-c 'typeset' | fgrep-A 10 say_hello
Say_hello ()
{
Echo hello world
}
A Bash process is started and typeset is executed. typeset returns all definitions in the current environment (New Environment). It is clear that say_hello is converted into a function.

Gitlab-shell is affected by Bash CVE-2014-6271 Vulnerability

Linux security vulnerability exposure Bash is more serious than heartbleed

The solution is to upgrade Bash. Please refer to this article.

Bash remote parsing command execution vulnerability Test Method

Bash vulnerability latest patch installation tutorial [Download]

Shellshock

For more details, please continue to read the highlights on the next page:

1 2 Next Page