Get your server issues fixed by our experts for a price starting at just 25 USD/Hour. Click here to register and open a ticket with us now!

Author Topic: OS-OTHER Bash CGI environment variable injection attempt  (Read 2432 times)

0 Members and 1 Guest are viewing this topic.

nidhinjo

  • Guest
OS-OTHER Bash CGI environment variable injection attempt
« on: June 23, 2018, 10:33:44 pm »
This vulnerability CVE-2014-6271 could allow for arbitrary code execution. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.

CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user.

The vulnerability is related to the way in which shell functions are passed though environment variables. The vulnerability may allow an attacker to inject commands into a Bash shell, depending on how the shell is invoked. The Bash shell may be invoked by a number of processes including, but not limited to, telnet, SSH, DHCP, and scripts hosted on web servers.

Technical Explanation


The bash shell allows shell variables and functions to be exported to a child from its parent through the process environment. Function definitions are passed using environment variables that share the name of the function and start with () {.

The child bash process does not stop processing and executing code after processing the closing brace } which is passed in the function definition. An attacker could define a function variable such as: FUNCT=() { ignored; }; /bin/id to execute /bin/id when the environment is imported into the child process.
This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) IDs CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277 and CVE-2014-6278.

How does it will affect the system

This issue affects all products which use the Bash shell and parse values of environment variables. This issue is especially dangerous as there are many possible ways Bash can be called by an application. Quite often if an application executes another binary, Bash is invoked to accomplish this. Because of the pervasive use of the Bash shell, this issue is quite serious and should be treated as such. All versions prior to those listed as updates for this issue are vulnerable to some degree.

The patch for CVE-2014-7169 introduces changes to how Bash evaluates environment variables. Applications which directly create Bash functions as environment variables need to be made aware of these changes. Previously, a function had to be stored in an environment variable of the same name. For example, the function "compute" would be stored in an environment variable named "compute". With the patch for CVE-2014-7169 applied, it would need to use the name "BASH_FUNC_compute()". As a result, there are now two pairs of parentheses in the environment string, as in "BASH_FUNC_compute()=() { }".

Functions written in Bash itself do not need to be changed, even if they are exported with "export -f". Bash will transparently apply the appropriate naming when exporting and reverse the process when importing function definitions.
Services that create such environment variables will need to be restarted to work with the new version of Bash.

Diagnostic Steps


You can also manually test your version of Bash by running the following command:

Code: [Select]
$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
If the output of the above command contains a line containing only the word vulnerable you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function.

Note that different Bash versions will also print different warnings while executing the above command. The Bash versions without any fix produce the following output:

Code: [Select]
$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

The versions with only the original CVE-2014-6271 fix applied produce the following output:

Code: [Select]
$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

If your system is not vulnerable, you will see output similar to:

Code: [Select]
$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory

Prevention


1) If your system is vulnerable, you can fix these issues by updating to the most recent version of the Bash package by running the following command:
Raw

Code: [Select]
# yum update bash
2) Fixed in packages
bash-4.2.45-5.el7_0.4
bash-4.1.2-15.el6_5.2
bash-4.1.2-15.el6_5.1.sjis.2
bash-4.1.2-9.el6_2.2
bash-4.1.2-15.el6_4.2
bash-3.2-33.el5_11.4
bash-3.2-33.el5_11.1.sjis.2
bash-3.2-24.el5_6.2
bash-3.2-32.el5_9.3
bash-3.0-27.el4.4

============================================== :)  ;) ===============================================