From d919156714c0bd3ae29f32fad65e29a043938d15 Mon Sep 17 00:00:00 2001 From: Augustin Date: Sun, 30 Nov 2025 23:00:14 -0500 Subject: [PATCH 1/3] Add files via upload --- Birladeanu_CVE-2014-6271.md | 136 ++++++++++++++++++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 Birladeanu_CVE-2014-6271.md diff --git a/Birladeanu_CVE-2014-6271.md b/Birladeanu_CVE-2014-6271.md new file mode 100644 index 0000000..5023c84 --- /dev/null +++ b/Birladeanu_CVE-2014-6271.md @@ -0,0 +1,136 @@ +# Shellshock Command Injection In Bash Shell + +## Introduction + +Consider a scenario where a user is on their device and an attacker is able to gain access and completely take control of your device. That is what would happen in the case of the original Shellshock CVE-2014-6271 vulnerability. When an attacker is able to remotely inject commands into the Operating System of any device that ran GNU Bash 4.3 or earlier, those in charge of securing your data and providing services have failed their goals and released sensitive user information. Exploiting the vulnerability allowed remote hackers to steal data, run commands to download malicious software/scripts, and completely control every aspect of an OS without the user knowing that their device no longer belongs to them. The source code that allowed this is one of the most dangerous weaknesses according to the Common Weakness Enumeration listing. GNU Bash is Bourne Again Shell which is very common in terms of command shells in Unix-like OS's (MacOS, Linux, Ubuntu, Android, iOS). In this case study, we will discuss how the vulnerability was exploited, the code design which allowed this, and how it could potentially have been prevented. + +## Software + +**Name:** GNU Bash (Bourne Again Shell) + +**Language:** C + +**URLs:** https://www.gnu.org/software/bash/ + https://ftp.gnu.org/gnu/ + +## Weakness + +**CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')** + +When Operating Systems allow untrusted commands to be inserted into the system shells, they let unneutralized commands to run. Letting untrusted data influence commands directly leads to command injection. Without proper and extensive input validation or escaping, this is a weakness because it continues to accept input that is not just plain text, but commands that will change the function of the program and/or underlying Operating System. + +To put it plainly, when a program takes user input and allows that input to insert shell commands, it allows any attack to insert commands and control the program and change pieces of the Operating System. Input checking is one of the largest weaknesses when we look at the most common attacks. + +To show an example of how this would occurr, the following is a generic version of the weakness: +``` +username = get_user_input() +command = "ls -l /home/" + username +system(command) +``` +This example is a rather simple, but realistic take on how the command injection works. Firstly, the command takes user input. If the user inputs the username then places a semicolon and a command after it, the Bash will interpret the semicolon as a line stop and the remaining part of the input will be seen as a command. This is very similar to SQL Injections in the sense that making the system think that the input line has ended then running the next command is allowed. A specific example of input to show the weakness would be if the user entered `example; rm -r /`. This would delete the user directory and all its files. As discussed later, this is far from the worst outcome. + +Command Injection becomes worse when the system fails to tell when data comes from trusted or untrusted sources. Discussed in the CWE-78 entry, neutralization done correctly involves avoiding shell execution, using strongly parameterized commands, using an allowlist to filter through the input, or escaping metacharacters. + +## Vulnerability + +**CVE-2014-6271** + +To provide relevent context, Bash (Bourne Again Shell) is a command-line interpreter and scripting language that is common on Unix-like Operating Systems. It interprets and takes in user entered commands and executes relevant scripts that contain sequences of commands. Bash has the feature "environment variables" which allows commands to allow function passage between programs. + +When Bash begins running, it looks at all environmental variables to find if one has the heading `() {`. This indicates that the environmental variable is a function which should be imported so child shells can call it. + +The specific vulnerability in the Bash code can be found in the 4.3 release, file "variables.c". + +``` +vulnerable file: variables.c https://ftp.gnu.org/gnu/bash/ + +350 /* If exported function, define it now. Don't import functions from +351 the environment in privileged mode. */ +352 if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4)) +353 { +354 string_length = strlen (string); +355 temp_string = (char *)xmalloc (3 + string_length + char_index); +356 +357 strcpy (temp_string, name); +358 temp_string[char_index] = ' '; +359 strcpy (temp_string + char_index + 1, string); +360 +361 if (posixly_correct == 0 || legal_identifier (name)) +362 parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST); +``` + +Going down the code snippet, Line 352 checks for any environment variable that starts with `() {` and treats it like a function to be exported for another program. This is a severe vulnerability as any input with those characters is trusted. When Bash does not know the difference between trusted and untrusted input, security is lost. Next in the snippet, Lines 357-9 create a new string and stores it using its value and name. Next, Line 362 calls function `parse_and_execute()` on the string that was just created. In an example where malicious code is entered, it will be built as a string and sent to the `parse_and_execute()` where it will be ran automatically. Bash does not typically allow users to create their own environment variables, but when a web server handles a request, it takes data from the user's request. After this it will turn it to environment variables which, as discussed previously will run if entered correctly. An attacker can alter web server requests and remotely infect all who indirectly ran the functions as soon as Bash was loaded. + +## Exploit + +**CAPEC-88: OS Command Injection** + +To exploit the vulnerability, it was common to send an HTTP request with the malicious format as explained in the Vulnerability section. After the request with malicious code was initialized into an environment variable, Bash would call the function on the string and the commands injected after a semicolon. An example of this could be if the USER_Agent variable was replaced with code that led the program to the password filepath and print the password. These commands that are injected are run with the same priveleges as the web server, meaning that they could read and write on the system. + +The exploitation of the vulnerability is rated as very low skill to complete while the damage potential is very highly critical for both security and confidentiality. A few characters in an input was all it took to exploit it. This is a reason as to why this vulnerability was so dangerous. It was easy to do, and allowed for customation of damage. The attacker could do nearly anything they wanted. They could alter one small input then have access to remote shells to execute any command. Create a backdoor, delete all files, view hidden files, send compromising messages; these are just a few of the capabilities of typing the few character to allow for any command wanted. + +## Fix + +Shortly after the discovery of the vulnerability, a patch was released that was meant to fix the problem. It did prevent Bash from executing commands after a function definition, but it only changed slightly. It still allowed for command injection to be processed and executed as the way it functioned still searched for the symbol heading `() {`. CVE-2014-6271 was not fixed for its first patch. Six months after the initial patch, bash43-027 fixed the root issue which was resolved by implementing a different environment variable naming convention and adding additional security measures for defining functions and limiting commands. + +```diff +file: variables.c (bash43-027 patch) + +350 /* If exported function, define it now. Don't import functions from +351 the environment in privileged mode. */ +-352 if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4)) ++352 if (privmode == 0 && read_but_dont_execute == 0 && ++353 STREQN (BASHFUNC_PREFIX, name, BASHFUNC_PREFLEN) && ++354 STREQN (BASHFUNC_SUFFIX, name + char_index - BASHFUNC_SUFFLEN, BASHFUNC_SUFFLEN) && ++355 STREQN ("() {", string, 4)) + 356 { + 357 string_length = strlen (string); +-358 temp_string = (char *)xmalloc (3 + string_length + char_index); ++358 size_t namelen = char_index - BASHFUNC_PREFLEN - BASHFUNC_SUFFLEN; ++359 temp_string = (char *)xmalloc (namelen + string_length + 2); + 360 +-361 strcpy (temp_string, name); +-362 temp_string[char_index] = ' '; +-363 strcpy (temp_string + char_index + 1, string); ++361 memcpy (temp_string, name + BASHFUNC_PREFLEN, namelen); ++362 temp_string[namelen] = ' '; ++363 strcpy (temp_string + namelen + 1, string); + 364 +-365 if (posixly_correct == 0 || legal_identifier (name)) +-366 parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST); ++365 parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD); +``` + +In the patch code above, Lines 353-355 implement that new naming system of labing them with `BASH_FUNC` and `%% ` to surround the command. An attacker could input malicious code, but since the system has changed to only allow some function conventions, the ones used to access the web server are not longer valid under this new system. The standard environment variables used such as `PATH` are no longer run or parsed by the file. They would find a fail on Line 353. The next change on Lines 358-363 involved extracting the variable name from the prefix and postfix given before creating the function. The last changes on Line 365 add further security such as now only accepting function definitions (and not commands) and only one command. This meant that if an attacker exploited Bash, the damage they could do was reduced severely. + +## Prevention + +Many methods would systematically aid in preventing similar vulnerabilities and exploits from happening. Using common programming design practices that focus on security, the likelyhood of a repeated instance would be much less likely to happen. + +Firstly, the greatest mistake in the original code was how it treated and allowed environment variable data as executable functions. Initially, the function `parse_and_execute()` (Line 362) took no precaution to verify that the command came from a trusted source. Bash should keep a very clean seperation between input data and code. Executable code should be kept in a communication channel of its own and not where data is kept. Data should never be run as code. + +Next, environment variables and other shared resources, should be defined using unique prefixes and postfixes. As seen in the fix, these naming conventions (BASH_FUNC_ ___ %%) that differed from those used typically on web servers were not able to be customized by an attacker which resulted in attempts being useless. Running arbitrary commands with no safety net or predefined system is a terrible idea and will always result in vulnerabilities. Unique IDs are used for variables on all different software systems, that is for a good reason. Attackers will not be able to know or use them if they are unique each time and do not allow for them to match it to other defined functions. + +Next, program systems should not automatically processs untrusted input or functions on startup by default. It was a huge risk to automatically take in and execute external input as soon as it started. As helpful as automation is, for security reasons, automatically passing on startup is going to keep software unsecure. This feature was on by default and anyone who had not intentionally set it to off would have be at risk. This goes against common practices. If something is risky, it should not be on by default. + +## Conclusion + +CVE-2014-6271 for GNU Bash showed how important input handling, filtering, and escaping could easily compromise security of a system that holds much of the world up. Letting environment variables to be used as executables let attackers inject as many malicious commands as they wanted and gain complete access over Operating Systems. A simple mistake in the program design failed to seperate trusted and untrusted code simply due to the `() {;` characters. + +The vulnerability was fixed by adding unique naming conventions and limiting how the `parse_and_execute()` function worked. This was a simple, yet important lesson. Each user should be given least priviledges required over a system, and input from untrusted users should never be run. Deterring from automatically executing code at startup, seperating commands and input, and limitting default settings that put users at risk are all lessons that must be learned from and practiced in future software. + +## References + +- Shellshock anlysis: https://dwheeler.com/essays/shellshock.html +- CVE Listing: https://www.cve.org/CVERecord?id=CVE-2014-6271 +- CWE Listing: https://cwe.mitre.org/data/definitions/78.html +- Exploitation walkthrough: https://ine.com/blog/shockin-shells-shellshock-cve-2014-6271 +- CAPEC Listing: https://capec.mitre.org/data/definitions/88.html +- CISA Listing: https://www.cisa.gov/news-events/alerts/2014/09/25/gnu-bourne-again-shell-bash-shellshock-vulnerability-cve-2014-6271-cve-2014-7169-cve-2014-7186-cve +- GNU Bash: https://ftp.gnu.org/gnu/bash/ +- GNU Bash Patch: https://ftp.gnu.org/gnu/bash/bash-4.3-patches/ +- Bash Wikipedia: https://en.wikipedia.org/wiki/Bash_(Unix_shell)#Bug_reporting +- Shellshock Wikipedia: https://en.wikipedia.org/wiki/Shellshock_(software_bug) + +## Contributions +- Augustin Birladeanu \ No newline at end of file From 16d7f4c9007b6ce48e732a94c22ca981fc539242 Mon Sep 17 00:00:00 2001 From: Augustin Date: Fri, 12 Dec 2025 09:58:49 -0500 Subject: [PATCH 2/3] CVE 2014-6271 --- Birladeanu_CVE-2014-6271.md | 39 ++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/Birladeanu_CVE-2014-6271.md b/Birladeanu_CVE-2014-6271.md index 5023c84..0f53394 100644 --- a/Birladeanu_CVE-2014-6271.md +++ b/Birladeanu_CVE-2014-6271.md @@ -2,7 +2,7 @@ ## Introduction -Consider a scenario where a user is on their device and an attacker is able to gain access and completely take control of your device. That is what would happen in the case of the original Shellshock CVE-2014-6271 vulnerability. When an attacker is able to remotely inject commands into the Operating System of any device that ran GNU Bash 4.3 or earlier, those in charge of securing your data and providing services have failed their goals and released sensitive user information. Exploiting the vulnerability allowed remote hackers to steal data, run commands to download malicious software/scripts, and completely control every aspect of an OS without the user knowing that their device no longer belongs to them. The source code that allowed this is one of the most dangerous weaknesses according to the Common Weakness Enumeration listing. GNU Bash is Bourne Again Shell which is very common in terms of command shells in Unix-like OS's (MacOS, Linux, Ubuntu, Android, iOS). In this case study, we will discuss how the vulnerability was exploited, the code design which allowed this, and how it could potentially have been prevented. +Consider a scenario where a user is on their device and an attacker is able to gain access and completely take control of your device. That is what would happen in the case of the original Shellshock CVE-2014-6271 vulnerability. When an attacker is able to remotely inject commands into the Operating System of any device that ran GNU Bash 4.3 or earlier, those in charge of securing your data and providing services have failed their goals and released sensitive user information. Exploiting the vulnerability allowed remote hackers to steal data, run commands to download malicious software/scripts, and completely control every aspect of an OS without the user knowing that their device no longer belongs to them. The source code that allowed this is one of the most dangerous weaknesses according to the Common Weakness Enumeration listing. GNU Bash is Bourne Again Shell which is very common in terms of command shells in Unix-like OS's (MacOS, Linux, Ubuntu, Android, iOS). In this case study, we will discuss how the vulnerability was exploited, the code design which allowed this, and how it could potentially have been prevented. ## Software @@ -19,7 +19,7 @@ Consider a scenario where a user is on their device and an attacker is able to g When Operating Systems allow untrusted commands to be inserted into the system shells, they let unneutralized commands to run. Letting untrusted data influence commands directly leads to command injection. Without proper and extensive input validation or escaping, this is a weakness because it continues to accept input that is not just plain text, but commands that will change the function of the program and/or underlying Operating System. -To put it plainly, when a program takes user input and allows that input to insert shell commands, it allows any attack to insert commands and control the program and change pieces of the Operating System. Input checking is one of the largest weaknesses when we look at the most common attacks. +To put it plainly, when a program takes user input and allows that input to insert shell commands, it allows any attack to insert commands and control the program and change pieces of the Operating System. Input checking is one of the largest weaknesses when we look at the most common attacks. To show an example of how this would occurr, the following is a generic version of the weakness: ``` @@ -27,19 +27,18 @@ username = get_user_input() command = "ls -l /home/" + username system(command) ``` -This example is a rather simple, but realistic take on how the command injection works. Firstly, the command takes user input. If the user inputs the username then places a semicolon and a command after it, the Bash will interpret the semicolon as a line stop and the remaining part of the input will be seen as a command. This is very similar to SQL Injections in the sense that making the system think that the input line has ended then running the next command is allowed. A specific example of input to show the weakness would be if the user entered `example; rm -r /`. This would delete the user directory and all its files. As discussed later, this is far from the worst outcome. - -Command Injection becomes worse when the system fails to tell when data comes from trusted or untrusted sources. Discussed in the CWE-78 entry, neutralization done correctly involves avoiding shell execution, using strongly parameterized commands, using an allowlist to filter through the input, or escaping metacharacters. +This example is a rather simple but realistic take on how the command injection works. Firstly, the command takes user input. If the user inputs the username then places a semicolon and a command after it, the Bash will interpret the semicolon as a line stop and the remaining part of the input will be seen as a command. This is very similar to SQL Injections in the sense that making the system think that the input line has ended then running the next command is allowed. A specific example of input to show the weakness would be if the user entered example; `rm -r /`. This would delete the user directory and all its files. As discussed later, this is far from the worst outcome. +Command Injection becomes worse when the system fails to tell when data comes from trusted or untrusted sources. Discussed in the CWE-78 entry, neutralization done correctly involves avoiding shell execution, using strongly parameterized commands, using an allowlist to filter through the input, or escaping metacharacters. ## Vulnerability **CVE-2014-6271** -To provide relevent context, Bash (Bourne Again Shell) is a command-line interpreter and scripting language that is common on Unix-like Operating Systems. It interprets and takes in user entered commands and executes relevant scripts that contain sequences of commands. Bash has the feature "environment variables" which allows commands to allow function passage between programs. +To provide relevant context, Bash (Bourne Again Shell) is a command-line interpreter and scripting language that is common on Unix-like Operating Systems. It interprets and takes in user entered commands and executes relevant scripts that contain sequences of commands. Bash has the feature "environment variables" which allows commands to allow function passage between programs. -When Bash begins running, it looks at all environmental variables to find if one has the heading `() {`. This indicates that the environmental variable is a function which should be imported so child shells can call it. +When Bash begins running, it looks at all environmental variables to find if one has the heading `() {`. This indicates that the environmental variable is a function which should be imported so child shells can call it. -The specific vulnerability in the Bash code can be found in the 4.3 release, file "variables.c". +The specific vulnerability in the Bash code can be found in the 4.3 release, file "variables.c". ``` vulnerable file: variables.c https://ftp.gnu.org/gnu/bash/ @@ -59,19 +58,19 @@ vulnerable file: variables.c https://ftp.gnu.org/gnu/bash/ 362 parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST); ``` -Going down the code snippet, Line 352 checks for any environment variable that starts with `() {` and treats it like a function to be exported for another program. This is a severe vulnerability as any input with those characters is trusted. When Bash does not know the difference between trusted and untrusted input, security is lost. Next in the snippet, Lines 357-9 create a new string and stores it using its value and name. Next, Line 362 calls function `parse_and_execute()` on the string that was just created. In an example where malicious code is entered, it will be built as a string and sent to the `parse_and_execute()` where it will be ran automatically. Bash does not typically allow users to create their own environment variables, but when a web server handles a request, it takes data from the user's request. After this it will turn it to environment variables which, as discussed previously will run if entered correctly. An attacker can alter web server requests and remotely infect all who indirectly ran the functions as soon as Bash was loaded. +Going down the code snippet, Line 352 checks for any environment variable that starts with `() {` and treats it like a function to be exported for another program. This is a severe vulnerability as any input with those characters is trusted. When Bash does not know the difference between trusted and untrusted input, security is lost. Next in the snippet, Lines 357-9 create a new string and stores it using its value and name. Next, Line 362 calls function parse_and_execute() on the string that was just created. In an example where malicious code is entered, it will be built as a string and sent to the parse_and_execute() where it will be ran automatically. Bash does not typically allow users to create their own environment variables, but when a web server handles a request, it takes data from the user's request. After this it will turn it to environment variables which, as discussed previously will run if entered correctly. An attacker can alter web server requests and remotely infect all who indirectly ran the functions as soon as Bash was loaded. ## Exploit **CAPEC-88: OS Command Injection** -To exploit the vulnerability, it was common to send an HTTP request with the malicious format as explained in the Vulnerability section. After the request with malicious code was initialized into an environment variable, Bash would call the function on the string and the commands injected after a semicolon. An example of this could be if the USER_Agent variable was replaced with code that led the program to the password filepath and print the password. These commands that are injected are run with the same priveleges as the web server, meaning that they could read and write on the system. +To exploit the vulnerability, it was common to send an HTTP request with the malicious format as explained in the Vulnerability section. After the request with malicious code was initialized into an environment variable, Bash would call the function on the string and the commands injected after a semicolon. An example of this could be if the USER_Agent variable was replaced with code that led the program to the password filepath and print the password. These commands that are injected are run with the same privileges as the web server, meaning that they could read and write on the system. -The exploitation of the vulnerability is rated as very low skill to complete while the damage potential is very highly critical for both security and confidentiality. A few characters in an input was all it took to exploit it. This is a reason as to why this vulnerability was so dangerous. It was easy to do, and allowed for customation of damage. The attacker could do nearly anything they wanted. They could alter one small input then have access to remote shells to execute any command. Create a backdoor, delete all files, view hidden files, send compromising messages; these are just a few of the capabilities of typing the few character to allow for any command wanted. +The exploitation of the vulnerability is rated as very low skill to complete while the damage potential is very highly critical for both security and confidentiality. A few characters in an input was all it took to exploit it. This is a reason as to why this vulnerability was so dangerous. It was easy to do, and allowed for customization of damage. The attacker could do nearly anything they wanted. They could alter one small input then have access to remote shells to execute any command. Create a backdoor, delete all files, view hidden files, send compromising messages; these are just a few of the capabilities of typing the few character to allow for any command wanted. ## Fix -Shortly after the discovery of the vulnerability, a patch was released that was meant to fix the problem. It did prevent Bash from executing commands after a function definition, but it only changed slightly. It still allowed for command injection to be processed and executed as the way it functioned still searched for the symbol heading `() {`. CVE-2014-6271 was not fixed for its first patch. Six months after the initial patch, bash43-027 fixed the root issue which was resolved by implementing a different environment variable naming convention and adding additional security measures for defining functions and limiting commands. +Shortly after the discovery of the vulnerability, a patch was released that was meant to fix the problem. It did prevent Bash from executing commands after a function definition, but it only changed slightly. It still allowed for command injection to be processed and executed as the way it functioned still searched for the symbol heading `() {`. CVE-2014-6271 was not fixed for its first patch. Six months after the initial patch, bash43-027 fixed the root issue which was resolved by implementing a different environment variable naming convention and adding additional security measures for defining functions and limiting commands. ```diff file: variables.c (bash43-027 patch) @@ -101,27 +100,27 @@ file: variables.c (bash43-027 patch) +365 parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD); ``` -In the patch code above, Lines 353-355 implement that new naming system of labing them with `BASH_FUNC` and `%% ` to surround the command. An attacker could input malicious code, but since the system has changed to only allow some function conventions, the ones used to access the web server are not longer valid under this new system. The standard environment variables used such as `PATH` are no longer run or parsed by the file. They would find a fail on Line 353. The next change on Lines 358-363 involved extracting the variable name from the prefix and postfix given before creating the function. The last changes on Line 365 add further security such as now only accepting function definitions (and not commands) and only one command. This meant that if an attacker exploited Bash, the damage they could do was reduced severely. +In the patch code above, Lines 353-355 implement that new naming system of labelling them with `BASH_FUNC` and `%%` to surround the command. An attacker could input malicious code, but since the system has changed to only allow some function conventions, the ones used to access the web server are not longer valid under this new system. The standard environment variables used such as `PATH` are no longer run or parsed by the file. They would find a fail on Line 353. The next change on Lines 358-363 involved extracting the variable name from the prefix and postfix given before creating the function. The last changes on Line 365 add further security such as now only accepting function definitions (and not commands) and only one command. This meant that if an attacker exploited Bash, the damage they could do was reduced severely. ## Prevention -Many methods would systematically aid in preventing similar vulnerabilities and exploits from happening. Using common programming design practices that focus on security, the likelyhood of a repeated instance would be much less likely to happen. +Many methods would systematically aid in preventing similar vulnerabilities and exploits from happening. Using common programming design practices that focus on security, the likelihood of a repeated instance would be much less likely to happen. -Firstly, the greatest mistake in the original code was how it treated and allowed environment variable data as executable functions. Initially, the function `parse_and_execute()` (Line 362) took no precaution to verify that the command came from a trusted source. Bash should keep a very clean seperation between input data and code. Executable code should be kept in a communication channel of its own and not where data is kept. Data should never be run as code. +Firstly, the greatest mistake in the original code was how it treated and allowed environment variable data as executable functions. Initially, the function `parse_and_execute()` (Line 362) took no precaution to verify that the command came from a trusted source. Bash should keep a very clean separation between input data and code. Executable code should be kept in a communication channel of its own and not where data is kept. Data should never be run as code. -Next, environment variables and other shared resources, should be defined using unique prefixes and postfixes. As seen in the fix, these naming conventions (BASH_FUNC_ ___ %%) that differed from those used typically on web servers were not able to be customized by an attacker which resulted in attempts being useless. Running arbitrary commands with no safety net or predefined system is a terrible idea and will always result in vulnerabilities. Unique IDs are used for variables on all different software systems, that is for a good reason. Attackers will not be able to know or use them if they are unique each time and do not allow for them to match it to other defined functions. +Next, environment variables and other shared resources, should be defined using unique prefixes and postfixes. As seen in the fix, these naming conventions `(BASH_FUNC_ ___ %%)` that differed from those used typically on web servers were not able to be customized by an attacker which resulted in attempts being useless. Running arbitrary commands with no safety net or predefined system is a terrible idea and will often result in vulnerabilities. Unique IDs are used for variables on all different software systems, that is for a good reason. Attackers will not be able to know or use them if they are unique each time and do not allow for them to match it to other defined functions. -Next, program systems should not automatically processs untrusted input or functions on startup by default. It was a huge risk to automatically take in and execute external input as soon as it started. As helpful as automation is, for security reasons, automatically passing on startup is going to keep software unsecure. This feature was on by default and anyone who had not intentionally set it to off would have be at risk. This goes against common practices. If something is risky, it should not be on by default. +Next, program systems should not automatically process input or functions on startup by default. In Bash's case, the designers assumed that the environment variables came from trusted sources with legitimate users running commands interactively. However, once Bash began being used in networked contexts, that assumption failed. The risk came from treating all input as trusted when, in reality, much of it was not. ## Conclusion -CVE-2014-6271 for GNU Bash showed how important input handling, filtering, and escaping could easily compromise security of a system that holds much of the world up. Letting environment variables to be used as executables let attackers inject as many malicious commands as they wanted and gain complete access over Operating Systems. A simple mistake in the program design failed to seperate trusted and untrusted code simply due to the `() {;` characters. +CVE-2014-6271 for GNU Bash showed how important input handling, filtering, and escaping could easily compromise security of a system that holds much of the world up. Letting environment variables to be used as executables let attackers inject as many malicious commands as they wanted and gain complete access over Operating Systems. A simple mistake in the program design failed to separate trusted and untrusted code simply due to the `() {;` characters. -The vulnerability was fixed by adding unique naming conventions and limiting how the `parse_and_execute()` function worked. This was a simple, yet important lesson. Each user should be given least priviledges required over a system, and input from untrusted users should never be run. Deterring from automatically executing code at startup, seperating commands and input, and limitting default settings that put users at risk are all lessons that must be learned from and practiced in future software. +The vulnerability was fixed by adding unique naming conventions and limiting how the `parse_and_execute()` function worked. This was a simple, yet important lesson. Each user should be given least privileges required over a system, and input from untrusted users should never be run. Deterring from automatically executing code at startup, separating commands and input, and limiting default settings that put users at risk are all lessons that must be learned from and practiced in future software. ## References -- Shellshock anlysis: https://dwheeler.com/essays/shellshock.html +- Shellshock analysis: https://dwheeler.com/essays/shellshock.html - CVE Listing: https://www.cve.org/CVERecord?id=CVE-2014-6271 - CWE Listing: https://cwe.mitre.org/data/definitions/78.html - Exploitation walkthrough: https://ine.com/blog/shockin-shells-shellshock-cve-2014-6271 From fbd1df8f7c39b2cc7d3c356a76221f5f808edb92 Mon Sep 17 00:00:00 2001 From: Augustin Date: Fri, 12 Dec 2025 22:20:07 -0500 Subject: [PATCH 3/3] Birladeanu_CVE-2014-6271 --- Birladeanu_CVE-2014-6271.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Birladeanu_CVE-2014-6271.md b/Birladeanu_CVE-2014-6271.md index 0f53394..a58bcc4 100644 --- a/Birladeanu_CVE-2014-6271.md +++ b/Birladeanu_CVE-2014-6271.md @@ -1,10 +1,10 @@ -# Shellshock Command Injection In Bash Shell +# SHELLSHOCK COMMAND INJECTION IN BASH SHELL -## Introduction +### Introduction Consider a scenario where a user is on their device and an attacker is able to gain access and completely take control of your device. That is what would happen in the case of the original Shellshock CVE-2014-6271 vulnerability. When an attacker is able to remotely inject commands into the Operating System of any device that ran GNU Bash 4.3 or earlier, those in charge of securing your data and providing services have failed their goals and released sensitive user information. Exploiting the vulnerability allowed remote hackers to steal data, run commands to download malicious software/scripts, and completely control every aspect of an OS without the user knowing that their device no longer belongs to them. The source code that allowed this is one of the most dangerous weaknesses according to the Common Weakness Enumeration listing. GNU Bash is Bourne Again Shell which is very common in terms of command shells in Unix-like OS's (MacOS, Linux, Ubuntu, Android, iOS). In this case study, we will discuss how the vulnerability was exploited, the code design which allowed this, and how it could potentially have been prevented. -## Software +### Software **Name:** GNU Bash (Bourne Again Shell) @@ -13,7 +13,7 @@ Consider a scenario where a user is on their device and an attacker is able to g **URLs:** https://www.gnu.org/software/bash/ https://ftp.gnu.org/gnu/ -## Weakness +### Weakness **CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')** @@ -30,7 +30,7 @@ system(command) This example is a rather simple but realistic take on how the command injection works. Firstly, the command takes user input. If the user inputs the username then places a semicolon and a command after it, the Bash will interpret the semicolon as a line stop and the remaining part of the input will be seen as a command. This is very similar to SQL Injections in the sense that making the system think that the input line has ended then running the next command is allowed. A specific example of input to show the weakness would be if the user entered example; `rm -r /`. This would delete the user directory and all its files. As discussed later, this is far from the worst outcome. Command Injection becomes worse when the system fails to tell when data comes from trusted or untrusted sources. Discussed in the CWE-78 entry, neutralization done correctly involves avoiding shell execution, using strongly parameterized commands, using an allowlist to filter through the input, or escaping metacharacters. -## Vulnerability +### Vulnerability **CVE-2014-6271** @@ -60,7 +60,7 @@ vulnerable file: variables.c https://ftp.gnu.org/gnu/bash/ Going down the code snippet, Line 352 checks for any environment variable that starts with `() {` and treats it like a function to be exported for another program. This is a severe vulnerability as any input with those characters is trusted. When Bash does not know the difference between trusted and untrusted input, security is lost. Next in the snippet, Lines 357-9 create a new string and stores it using its value and name. Next, Line 362 calls function parse_and_execute() on the string that was just created. In an example where malicious code is entered, it will be built as a string and sent to the parse_and_execute() where it will be ran automatically. Bash does not typically allow users to create their own environment variables, but when a web server handles a request, it takes data from the user's request. After this it will turn it to environment variables which, as discussed previously will run if entered correctly. An attacker can alter web server requests and remotely infect all who indirectly ran the functions as soon as Bash was loaded. -## Exploit +### Exploit **CAPEC-88: OS Command Injection** @@ -68,12 +68,12 @@ To exploit the vulnerability, it was common to send an HTTP request with the mal The exploitation of the vulnerability is rated as very low skill to complete while the damage potential is very highly critical for both security and confidentiality. A few characters in an input was all it took to exploit it. This is a reason as to why this vulnerability was so dangerous. It was easy to do, and allowed for customization of damage. The attacker could do nearly anything they wanted. They could alter one small input then have access to remote shells to execute any command. Create a backdoor, delete all files, view hidden files, send compromising messages; these are just a few of the capabilities of typing the few character to allow for any command wanted. -## Fix +### Fix Shortly after the discovery of the vulnerability, a patch was released that was meant to fix the problem. It did prevent Bash from executing commands after a function definition, but it only changed slightly. It still allowed for command injection to be processed and executed as the way it functioned still searched for the symbol heading `() {`. CVE-2014-6271 was not fixed for its first patch. Six months after the initial patch, bash43-027 fixed the root issue which was resolved by implementing a different environment variable naming convention and adding additional security measures for defining functions and limiting commands. ```diff -file: variables.c (bash43-027 patch) +fixed file: variables.c (bash43-027 patch) 350 /* If exported function, define it now. Don't import functions from 351 the environment in privileged mode. */