The Shellshock vulnerability is one of the earliest and most classic security flaws. Nicknamed “Shellshock,” this critical vulnerability was discovered in certain versions of Bash on operating systems such as Red Hat, CentOS, Ubuntu, Fedora, Amazon Linux, and OS X 10.10. Given Bash’s extensive use in mainstream operating systems, the vulnerability affects most Unix, Linux, and Mac OS X systems that rely on Bash. This puts data managed by these systems at significant risk of high-level threats.
“Shellshock” is a vulnerability in Bash (GNU Bourne Again Shell) that allows attackers to execute arbitrary commands through environment variables.
Conditions for exploitation: Bash versions ≤ 4.3 or the following output proves the existence of the vulnerability.
Here, I used vulhub’s vulnerability environment. After entering the container, I used the Bash 4.3 version.
Payload: env x='() { :;}; echo shellshocked’ bash –c “echo test”
Let’s break down this payload. 
Now, execute the complete payload. 
Next, observe the execution of the payload in a normal Bash environment. 
This confirms the existence of the vulnerability. Let’s review some basic Bash knowledge. Here’s the normal output of a string. 
Now, let’s try opening a Bash subprocess to see if we can retrieve the value of a variable. 
No output is returned. We cannot read the variable’s value because we opened a Bash subprocess, but the value of the variable still exists in the parent process. When a shell session is started, some variables are already available, and these variables are called environment variables. To access the $gname variable in a subprocess, we can use the export command to set it as an environment variable. 
Similarly, what happens if we set a Bash function and combine it with an environment variable? 
As expected, the x function executed in the Bash subprocess and read the /etc/passwd file.
How can we turn a string into a function and execute it? 
Thus, the conditions required to trigger and exploit the Shellshock vulnerability are as follows:
- The targeted Bash version has the vulnerability (version ≤ 4.3).
- The attacker can control environment variables.
- A new Bash process is opened to trigger the vulnerability and execute commands.
From the above analysis, it can be seen that the root cause of the vulnerability lies in the implementation of Bash’s ENV command. Therefore, the vulnerability itself cannot directly lead to remote code execution. To achieve remote code execution, a third-party service program must act as a medium, and the third-party program must meet many conditions to serve this role.
Principle of the Vulnerability
The environment variables used by Bash are invoked through function names. The vulnerability arises because environment variables defined with “(){” are parsed into functions by the ENV command. After parsing, Bash does not exit but continues to parse and execute shell commands. The core issue lies in the lack of strict boundary restrictions and proper validation of input parameters.
Here’s a commonly seen diagram online that explains the vulnerability.
Next, let’s use vulhub’s environment to verify the specific exploitation method of this vulnerability.
The contents of these two files are the same, but they use different Bash versions. In hackbar, we add a user-agent, insert our payload, and construct a function to read the passwd file.
() { foo; }; echo Content-Type: text/plain; echo; /bin/cat /etc/passwd
The same payload fails in a normal Bash version.
However, after reviewing the patch analysis online, the patch primarily filters the validity of parameters. The patch program performs boundary checks on the input command in the parse_and_execute function of /builtins/evalstring.c, eliminating the possibility of code injection. The patch uses two flag checks and one command type match to ensure accurate flag judgment. SEVAL_FUNCDEF and SEVAL_ONECMD flags are predefined in the patch as the basis for judgment.
Potential impacts of the vulnerability:
1. This vulnerability can bypass ForceCommand configurations in sshd, allowing arbitrary command execution.
2. If CGI scripts are written in Bash, Apache servers using mod_cgi or mod_cgid are affected.
3. DHCP clients that call shell scripts to configure the system may allow arbitrary command execution.
4. Various daemons and SUID/privileged programs that execute shell scripts may allow arbitrary commands to run through user-set or influenced environment variable values.
However, I personally feel that CGI is rarely used nowadays, and the exploitation scenarios and conditions are somewhat limited. Nevertheless, the impact of this vulnerability was significant when it was first disclosed, as it affected many versions. Reproducing vulnerabilities is not just about focusing on the vulnerability itself but also about the mindset of discovering vulnerabilities!