On the 24th of June 2015, Adam Langley and David Benjamin (Google/BoringSSL) reported a vulnerability that allows attackers to cause specific checks on untrusted certificates to be bypassed. By bypassing checking of the CA (certificate authority) flag, attackers could use a valid leaf certificate to act as a CA and clients would “validate” an invalid certificate.

Today the OpenSSL project released advisories to install a patch that remediates these problems with the OpenSSL certificate verification process (affecting versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o). The flaw exists within the verification process, because if the first attempt to build a chain failed then OpenSSL would attempt to find an alternative certificate chain.

OpenSSL have advised that: “This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.”

Detection

To detect which version of OpenSSL you have running, use the following command:

$ openssl version -a

Remediation

The “BoringSSL” project developed patch was published today. 7 Elements advise upgrading as soon as possible:

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

Additionally, 7 Elements reminds that support for OpenSSL versions 1.0.0 and 0.9.8 will end at the end of this year.

The use of unsupported software is discouraged and usually symptomatic of a weak stance on solid Information Security practices. Industry recommendations dictate that regular patching policies are key in protecting infrastructure assets within organisations.

If you would like support in completing any assurance activity then please get in touch using:
contact-us@7elements.co.uk.

References:

https://www.openssl.org/news/vulnerabilities.html
https://www.openssl.org/news/secadv_20150709.txt
http://cxsecurity.com/issue/WLB-2015070040
https://grahamcluley.com/2015/07/openssl-vulnerability-revealed/

Unearthing Haemorrhages

To date much effort has been focused on remediating common sources of Heartbleed, without taking into account that the vulnerability affects more than just common ports (such as 443 for HTTPS). Many online testing tools limit the scope of tests for Heartbleed to a subset of ports, thereby providing limited assurance and are focused on externally facing assets. During recent engagements, we are still finding Heartbleed, often on internal management systems where the disclosure of sensitive information could aid a malicious insider. It is also important to understand that the vulnerability may not only lie within an Operating System but also in any application containing and utilising a vulnerable OpenSSL library. Therefore an organisation’s approach to patching must be holistic and take both of these areas into account.

For those requiring defensible assurance, any service implementing SSL on any port should be tested and if required, treated. Additionally, whether vulnerabilities are found or not it may be possible that the Heartbleed bug was already exploited prior to discovery or patching. There are techniques that can be employed to flag telltale larger-than-typical TLS heartbeat responses from a server and additionally, reveal exactly what information was compromised.

However, a single test cannot provide certainty that the vulnerability will not be reintroduced into the system via the installation of an unpatched vulnerable application or embedded system. Therefore, it is vital that your ongoing assurance activity continues to check for issues long after they have left the media spotlight.

If you would like support in completing any assurance activity then please get in touch using:
contact-us@7elements.co.uk.

Background

The security bug, CVE-2014-0160, known as Heartbleed was disclosed in April 2014. Heartbleed directly affects the Transport Layer Security (TLS) cryptographic protocol that uses affected OpenSSL cryptography libraries (versions 1.0.1 to 1.0.1f). The aim of TLS is to provide communications security and privacy over the Internet. Applications that utilise this protocol range from Virtual Private Networks to email and web services.

Heartbleed exploits vulnerable OpenSSL libraries to compromise secret keys used to encrypt traffic, allowing access to transmitted data including usernames and passwords.

Additional Remediation

Research from the University of Maryland has identified that while many system administrators quickly applied patches to correct the Heartbleed vulnerability, many failed to properly implement revocation of current certificates and ensure the re-issuing of new new certificates. The final step of revocation and re-issue is vital,  as the Heartbleed vulnerability could have been used to gain access to the private keys of a server.

Links

http://heartbleed.com/

http://www.umiacs.umd.edu/~tdumitra/papers/IMC-2014.pdf

How to Detect a Prior Heartbleed Exploit

http://www.riverbed.com/blogs/Retroactively-detecting-a-prior-Heartbleed-exploitation-from-stored-packets-using-a-BPF-expression.html

On October 15^th 2014, the security team at Drupal announced that all Drupal 7 web sites were vulnerable to SQL Injection attacks.

A German security firm, SektionEins, discovered the flaw, advising:

“A malicious user can inject arbitrary SQL queries. And thereby control the complete Drupal site. This leads to code execution as well… can be exploited by remote attackers without any kind of authentication…”

Drupal 7 and all following releases can be easily compromised (with the exception of the newly released 7.32 or 8 beta2). Drupal 6 is also vulnerable if it utilises the DBTNG module used for Drupal 7 PDO database compatibility. This highly critical vulnerability, CVE-2014-3704, allows anyone to execute PHP code on a vulnerable server. Remote attackers are able to delete everything, install backdoors into the website, change any data in the database including passwords and modify any data hosted on the server. The vulnerability hands over complete control of website content, and low skilled attackers are able to exploit this by deploying easily found attack scripts.

First Steps:

The first step is to check your version of Drupal, immediately. If you have 7.32 or 8 beta2 then you do not need to do anymore. If you do not have 7.32 or 8 beta2 then you should upgrade without delay.

Drupal upgraded, now what?

We will outline the bad news and then discuss some restorative and assuring good news.

The Bad News

When the security team at Drupal warned the world on Wednesday 15th October 2014 of the SQL injection vulnerability users were warned to assume their websites were compromised if not updated by October 15, 11pm UTC.

The reason for Drupal’s caution is that a late patch will potentially not affect vulnerabilities, such as backdoors, already introduced into the system. It is also possible that an attacker, once gaining control of the site in question, will have patched it themselves to retain control and stop other hackers gaining from the potential spoils of the vulnerability.

Drupal have advised, that sites not updated within the six hour timeframe, should be taken offline. All files and databases then have to be deleted and then the site must be restored from backups made before October 15th 2014. Finally, the website must be updated before bringing it back online as the backup will be vulnerable.

The Vulnerability

The bug was introduced in early 2011, allowing the execution of arbitrary code remotely with only one HTTP request and no knowledge of the site is required to conduct the attack.

Drupal handles all database queries by using prepared statements with placeholders conveniently indicating where in the SQL query the input from the user should be included.

SELECT * FROM {users} WHERE name IN (:name_0, :name_1)

Above, variables are bound to :name_0 and :name_1. As this is a prepared statement the attacker cannot inject values into it thereby controlling the SQL query. The placeholder number must be correct so Drupal expands :name to :name_0, :name_1 using a function, this function however is flawed. The flaw is that it incorrectly expands the array to :name_$key0, :name_$key1. SQL queries can now be manipulated as an attacker has control over $key0 and $key1 as seen below.

SELECT * FROM {users} WHERE name IN (:name_test) OR name = ‘Admin’ --, :name_test)

The above query results in an SQL injection giving full control of the database to the attacker. SektionEins have also published a blog demonstrating a proof of concept for an attack that takes one GET request with a cookie that will not be shown in any log.

Password Change Attack

We recreated a password attack in our lab and discovered that the only indication of the standard attack was the log below:

127.0.0.1 - - [03/Nov/2014:08:49:51 -0500] "POST /?q=node&destination=node HTTP/1.0" 200 8889 "-" "-"

This log was linked to changing the username and password of the administrator using the following script.

The Good News

The advice given by Drupal to restore the website back to backups made before October 15th 2014 is what could be considered wiping the slate clean instead of trying to identify if the slate is dirty first. Drupal’s advice may also not guarantee the site was not already compromised, due to the vulnerability existing since early 2011. A proportional response should be the first step to take. We will outline steps that can be taken that will help identify the potential impact of this vulnerability on a given site. As the attacks are so simple it is likely many are being perpetrated by ‘script kiddies’. Assuming this makes it unlikely that enough foresight or effort was dedicated to removing attack trails such as footprints in logs.

Steps to take
1. A forensic investigation of the logs can reveal suspicious activity and its timing.
2. The database can be investigated for users added and modified.
3. Files can be compared to files in backup to identify changes to existing files and discover any new files created.
4. Traffic leaving the network can be analysed to uncover potential attacker connections.

Ultimately, a risk based decision needs to be made between the likelihood of a successful attack having been perpetrated against your website and the impact and complexity of restoring the site to its state prior to October 15^th 2014. It may be pertinent to seek assurance before deciding to commit to a full rebuild of your website as it may not have been breached. This will offset the chance of the loss of incremental changes that were committed to the site after the October 15 backup cutoff date and the time the site will need to be offline and inaccessible.

If you would like support in completing an investigation please get in touch using:
contact-us@7elements.co.uk.

Links

Drupal “Public Service Announcement”
https://www.drupal.org/PSA-2014-003

Drupal FAQ
https://www.drupal.org/node/2357241

Drupal flowchart of treatment steps and options
http://drupal.geek.nz/blog/your-drupal-website-has-backdoor

SektionEins Blogpost
https://www.sektioneins.de/en/blog/14-10-15-drupal-sql-injection-vulnerability.html

Yesterday Bodo Möller of Google, published a blog detailing a design vulnerability of SSL 3.0 [RFC5246] which allows cyber attackers to calculate the plaintext content of secure connections. This means that supposedly encrypted traffic between clients and servers can be intercepted. Attackers may also then be able to steal cookies, potentially allowing control over a victims email, banking and social networking accounts.

SSL 3.0

Introduced in 1996, the majority of browsers support SSL 3.0. The intention was to allow encrypted communication, facilitated by client-server security handshakes that created encrypting and decrypting keys.

Google researchers have now exposed a flaw in SSL 3.0 which they have coined POODLE (Padding Oracle On Downgraded Legacy Encryption). Simply put, SSL 3.0 encryption is now obsolete.

The Exploit

For backward compatibility, many servers support the use of legacy protocols (SSL 3.0 among them). The exploit utilises this approach to downgrade encrypted connections that use the newer Transport Layer Security (TLS) protocol to that of SSL 3.0. Thereby ensuring that the victim is vulnerable to attack. Once SSL 3.0 is triggered, decryption of secure HTTP cookies is possible using a simple man-in-the-middle (MiTM) attack.

MiTM attacks require attackers to place themselves between their victims (client) and their service provider (server). This means that the most vulnerable areas for this attack are unprotected networks and WiFi hotspots. However, an attacker could also go to the effort of deploying customised malware onto the client machine to proxy requests and therefore conduct local MiTM attacks.

Delving Deeper

It is known that RC4 (used by SSL 3.0) has biases, these result in incremental leaking of information from multiple connections which hold the same information, for example, usernames and passwords. Problems with CBC encryption have now also been uncovered.

The problem stems from block cipher padding that is used by cipher-block chaining (CBC) encryption not being deterministic and additionally not being covered by the Message Authentication Code (MAC). This means that padding integrity is unverifiable upon decryption. Attackers can leverage this vulnerability by using fast blockwise chosen-plaintext attacks. See “Here Come The Ninjas” by Thai Duong and Juliano Rizzo for more details.

To launch the POODLE attack:

Follow the steps below:

1. Run a JavaScript agent on http://example.com to get the victim browser to send cookie-bearing HTTPS requests to https://example.com.

2. Intercept and modify the SSL records sent by browser. This must be done to ensure a non-negotiable chance of example.com acceptance of the modified record.

3. After acceptance, the attacker can now decrypt one byte of the cookies.

If each block C consists of 16 bytes, C[0]-c[15], and the size of the cookie is known, the SSL 3.0 CBC cipher suites’ normal MAC size is 20 bytes.

An encrypted POST request under the CBC layer is as follows:

POST /path Cookie: name=value…\r\n\r\nbody || 20-byte MAC || padding

An attacker can control the request path and body and by doing so, can induce requests which result in the following conditions:

1. Padding fills an entire block, encrypted into Cn.

2. The first, as-of-yet unknown byte of the Cookie, appears as the final byte in an earlier block, encrypted into Ci.

Cn is then replaced by Ci and then this modified SSL record is forwarded by the attacker to the server. The server should then reject this record, however the attack will then try again with another request. Once in 256 requests the server will accept the modified record allowing the attacker to conclude that:

DK(Ci)[15]⊕Cn1[15]=15,

and thus that

Pi[15]=15⊕Cn1[15]⊕Ci1[15].

The above reveals the cookies first previously unknown byte. By changing the sizes of the request path and body simultaneously, the attacker can proceed to the next byte. This is done by keeping the request size the same but moving the positions of the headers. This process can be repeated until the attacker has decrypted as much of the cookies as desired. Expected effort is 256 SSL 3.0 requests per byte.

Whilst the padding does hide the payload size, inducing requests:

 GET /, GET /A, GET /AA, …

Will allow an attacker to reveal the point at which the block boundary is crossed, this means that after at most, 16 requests, the padding size will be revealed and thereby the size of the cookies.

To see this method in more detail view “This Poodle Bites: Exploiting the SSL 3.0 Fallback” by Bodo Möller, Thai Duong and Krzysztof Kotowicz, here.

Testing for POODLE

There are two sites that you can use to test for POODLE vulnerability:

To test your browser:

http://www.poodlescan.com

To test a server:

https://www.poodletest.com

There are also tests which can be conducted with GNU, Wget and cURL.

GNU Wget

% wget --secure-protocol=SSLv3 -O /dev/null https://example.com/

If a connection is established then the url tested is vulnerable.

cURL

% curl -3 https://example.com/ > /dev/null

Will result in..

% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

100   163  100   176    0     0    454      0 --:--:-- --:--:-- --:--:--   654

If vulnerable the connection may be similar to the above. If not vulnerable the connection attempt will result in an error.

For more detail, see .@sknn’s tumblr here.

POODLE Mitigation

Google researchers Bodo Möller, Thai Duong and Krzysztof Kotowicz assert that the best mitigation of this bug is to disable client and server support of SSL 3.0 or SSL 3.0 RC4 stream/CBC-mode ciphers. However this may result in compatibility problems. Möller advises support for TLS_FALLBACK_SCSV (Transport Layer Security Signaling Cipher Suite Value). This mechanism stops the attacker from triggering the use of SSL 3.0 by addressing the problems arising from the retrying of failed connections. Furthermore, the mechanism additionally prevents future attacks by also addressing the possible triggering of TLS 1.2 to 1.1 and 1.0.

Google Chrome is reported to have supported TLS_FALLBACK_SCSV since February and have not identified any compatibility problems thus far. Testing of disabling the use of SSL 3.0 was begun yesterday by Google, they have warned that sites dependent on SSL 3.0 will need to be updated quickly as these sites will not be fully accessible by Chrome users.

End users should check their browsers, and disable SSL 3.0, if it is supported. There is already a Chromium patch and Mozilla will be disabling SSL 3.0 by default in Firefox 34, which will be available on 25^th of November. However to disable SSL 3.0 use in Firefox now, download the SSL Version Control add-on.

Links

https://www.openssl.org/~bodo/ssl-poodle.pdf

http://nerdoholic.org/uploads/dergln/beast_part2/ssl_jun21.pdf

http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

http://sknn.tumblr.com/post/100060787243/poodle-test-with-wget-secure-protocol-sslv3

Browser Links

https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/

https://chromium.googlesource.com/chromium/src/+/32352ad08ee673a4d43e8593ce988b224f6482d3

Two days ago Fredrik Strömberg reported that OpenVPN, under certain configurations, made servers externally vulnerable to the Shellshock bug. The configuration problem stems from a number of options that call custom commands at different tunnel session stages. Upon calling many of these commands, environmental variables are set, with clients controlling some of them.

The command “auth-user-pass-verify” is one option used for username and password authentication that takes commands from the client. If the script being called uses a vulnerable bash shell then, “the client simply delivers the exploit and payload by setting the username” (Fredrik Strömberg).

The main issue here is that the attack is deliveried “pre-auth” and successful compromise will result in authenticated access to the OpenVPN server. Technical details of the attack can be found here.

To help understand this attack vector, we have created the following video that shows a successful exploit against OpenVPN:

It appears that Red Hat assurances regarding updates released thus far to fix bash vulnerabilities have unleashed an Lernaean Hydra effect, spawning and spurring the discovery of several more bugs.

Exploit Mechanics and Attack Vectors

To recap, the bash bug, now around 22 years old dating back to version 1.13, allows attackers to interact with a host operating system by exploiting a vulnerable web server (Or any bash linked application/service/client). The attacker aims to inject data into system environmental variables. Normally these variables are used by the operating system as a resource for knowledge about where to find required files, configurations for its own function as well as the programs running on it. The bash vulnerability allows malformed data inside these seemingly benign environmental variable scripts. These scripts can contain commands which bash is tricked into interpreting.   In the case of a webserver this can lead to the attacker being able to run commands with the same administrator privileges as the webserver itself, leading to full control of the compromised system.

What does this mean in terms of exploitation possibilities? This vulnerability could open the door to attackers gaining remote access and control of a system to then exploit the system to spread malware, deface system hosted websites, create botnets to launch DDoS attacks, steal personal data, send spam and phishing emails and the perpetration crude but effective destructive wiping attacks. The first Shellshock botnet, “wopbot”, has been used to attack Akamai and US DoD networks.

Security Alerts Issued

The vulnerability is being taken seriously as the ICO, concerned about the disclosure of personal data, urges businesses to install the latest patches for this vulnerability as they become available. CERT-UK, the Computer Emergency Response Team established in March 2014 by the National Cyber Security Strategy, have also issued an alert. CERT-UK suggests that the threat of Shellshock, which affects Unix, Linux, MacOS and many embedded architecture devices, may be bigger than the password revealing, Heartbleed bug, which only affected OpenSSL.

The US National Vulnerability Databases has rated the severity of the bug as 10/10, with an easy exploitation complexity rating of ‘low’. US financial regulators have urged financial institutions to act quickly to identify and fix all of their vulnerable systems and software, including third party applications, to ensure “Shellshock” does not expose them to fraud.

Why is Bash Still Vulnerable?

Several developers have reported that the same vulnerabilities that existed after the first patch (CVE-2014-7169) still exist after the second patch (CVE-2014-6271). These developers are urging a complete rethink in the approach to future patches. Computing Scientist, David A. Wheeler asserts that until bash stops automatically parsing environment variables, it will continue to be vulnerable. An open source developer, Norihiro Tanaka, demonstrated that he was able to bypass the second patch and pass through executable commands by using the name “cat” for the environmental variable, a Unix utility of the same name exists that is used to concatenate files.

Detection

Due to the nature of the attack vectors associated with the Shellshock bug and its prolonged existence, there is a need for organisations to conduct an internal review of their systems and ensure the necessary assurance work is conducted to identify compromises to security and gain assurance.

Shellshock Timeline

Timeline of notable Shellshock bash patches and attacks

Patches Released

On Sept 25^th the Free Software Foundation released bash patches. These patches are reported to fix the original flaw CVE-2014-6271 and an additional flaw, discovered by Tavis Ormandy, which spawned from the incomplete CVE-2014-7169.

Several vendors, including Oracle, have begun releasing patches to fix their products that are liked to bash. Furthermore, Florian Weimar has released an unofficial patch that puts function exporting in a separate namespace. The fix isolates function-parsing code from attacker-controlled strings in several identified use cases.

Proposed Future Solution

So while bash is not yet completely fixed, there is a clear pathway currently under development that aims to fix problems with bash. The approach is twofold, firstly Florain Wiemar, a security expert, proposed the adding of a prefix to bash functions. Adding the prefix aims to prevent functions from having the same name as system variables. Secondly, Dr. Christos Zoulas proposes only allowing the importing of environmental variables via bash when explicitly requested. Explicit requests stop bash command parsing from inadvertently executing malicious code residing in surplus environmental variables.

Solution Implications

An unfortunate caveat of any workable solution is the dissolution of backward compatibility for bash. While Wheeler does not believe the majority of bash-dependent systems would suffer, many software systems that rely on bash may need their code tested and if needs be, modified. However, just as Wheeler has shut down several of his websites until he has confidence the problem has been fixed, the same may need to follow for older services to ensure that assurance via patching and testing can be completed to provide operational confidence.

For now though, it is important for organisations for patch vulnerable systems, establish effective protective network monitoring and to ensure their end users systems are also kept up to date to ensure they are part of the solution.

Bashing Linux Security – The Shellshock Exploit

On Wednesday the world awoke to a substantial vulnerability in the Bourne again shell, otherwise known as bash.  Bash is a UNIX like shell which was created in 1980.  It is now a far cry from the simple terminal based command interpreter it used to be, having grown arms and legs in terms of functionality and has become one of the most installed utilities in Linux systems worldwide.

Exploit Intro

The vulnerability was first discovered by Stephane Chazelas, listed as advisory CVE-2014-7169, this has graduated to CVE-2014-6271 as the first fix released by Red Hat was unsuccessful.  The problem stems from bash allowing arbitrary code execution.  Several services and applications are vulnerable to unauthenticated attackers being able to provide environment variables remotely.   These environment variables are important because they can directly influence software behaviour.

The bash shell is often used remotely by users, for example using ssh to administer a system or service, many programmers run the bash shell in the background and bash provides parsing for services such as Apache and has limited command execution support.

Impact

Attackers exploit this vulnerability by creating environment variables with specific values before summoning the bash shell.  Variables can possess any name and could contain malicious code.  This code is then executed when the bash shell is called.  This will raise many eyebrows as the many ways of calling bash via applications makes this issue perilous.  It is not uncommon for an application to execute binary code by invoking Bash.  The widespread use of bash makes this vulnerability serious and remediation must be fast and effective.

Ease of Exploit

We are aware of exploit code in the wild, which is trivial to use.

Major attack vectors reported so far are HTTP requests and CGI scripts.   AcceptEnv variables in OpenSSH are also open to attack, including TERM and SSH_ORIGINAL_COMMAND.  Environmental variables, named arbitrarily, can contain vicious payloads that seek to exploit the network.

Web applications in PHP, Python, C++ or Java may also be vulnerable if they happen to use libcalls, which are backed by calls to libraries-linked to bash. For example, popen() or system() are both linked to calls to bash.

Test your Bash

Test your version of bash for this vulnerability by running the following command:

$env x='() { :;}; echo I am vulnerable to ShellShock'  bash -c "echo This is a test for CVE-2014-7169"

If the command output as follows:

I am vulnerable to ShellShock
This is a test for CVE-2014-7169

Then your version of bash is vulnerable.

If your version of bash is not vulnerable then your output should be similar to:

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test for CVE-2014-7169

Mitigation

Unfortunately the patch released by the maintainer of bash will not fix the vulnerability.  Its attempts to sanitise code have been shown to be unsuccessful.

There are bash workarounds which may mitigate the vulnerability, however due to the limited testing of these solutions you may find that your fixes have unintended consequences.  However for those that can’t afford to wait, the fix involves upgrading to a new version of bash and imposing access limitations for vulnerable services.  Additionally, filtering the input to vulnerable services such as HTTP is advisable, a Python script that tests URL’s for vulnerabilities can be found on GitHub, contributed by Andres Riancho.

Alternatively, whilst it may not be a practical solution for many, you can replace bash with a different shell.

Update

26-09-2014

Patched versions of bash that fix CVE-2014-7169, have been released by Red Hat. As reports grow of Shellshock being actively exploited, it is strongly recommended that this update be applied as soon as possible.

The fixes apply to Red Hat Enterprise Linux 5, 6 and 7. However it is important to note that updates are applied after you have made changes to your applications that create bash functions as environment variables.

The patch that fixes Shellshock changes how bash evaluates environment variables. This means that any application which creates bash functions as environment variables will need to be updated in line with the patch changes.

To see if your bash is still vulnerable run this command:

env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

If your version of bash is still vulnerable the above command will result in the output “vulnerable”, this stems from the function name needing to be stored in an environment of the same name.

This means that if a function is named “compute” it would be stored in an environment variable named “compute”. After applying the update, the aforementioned function would be named “BASH_FUNC_compute()”. There are now two pairs of parentheses in the environment string, as in “BASH_FUNC_compute()=() {}”.

If after running the test above, you have found your system is vulnerable and are certain your associated applications are updated then update to the most recent version of bash by running:

# yum update bash

You will now need to restart your bash-linked applications to ensure that future environment variables are created using the new version of bash. A reboot of your system and services is not required as the vulnerability stems from initial imports of the kernel process environment. If the update is successfully installed then new processes will use the new code and Red Hat asserts that it will not be vulnerable.

If you believe your system may have been compromised by Shellshock then it is advisable to reboot your system after updating bash. Additionally security checks should be analysed to identify suspicious activity.

Links

https://rhn.redhat.com/errata/RHSA-2014-1306.html

https://access.redhat.com/articles/1200223