According to The Register, a serious vulnerability in SSL v3 will be disclosed tomorrow on October 15th. Some people are recommending disabling SSL v3 in various daemons until further notice.

A vulnerability in the design of SSL version 3.0. This vulnerability allows the plaintext of secure connections to be calculated by a network attacker.

SSL 3.0 is nearly 18 years old, but support for it remains widespread. Most importantly, nearly all browsers support it and, in order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions, including SSL 3.0. Because a network attacker can cause connection failures, they can trigger the use of SSL 3.0 and then exploit this issue.

Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today.

Detection (Linux)

The following script can be run against the server in question. The command will return ‘SSL 3.0 enabled’ if vulnerable and ‘SSL 3.0 disabled’ if not.

_______________

#!/bin/bash
ret=$(echo Q | timeout 5 openssl s_client -connect “${1-`hostname`}:${2-443}” -ssl3 2> /dev/null)
if echo “${ret}” | grep -q ‘Protocol.*SSLv3’; then
if echo “${ret}” | grep -q ‘Cipher.*0000’; then
echo “SSL 3.0 disabled”
else
echo “SSL 3.0 enabled”
fi
else
echo “SSL disabled or other error”
fi
_______________

NOTE: This script takes the hostname of the server to check as the first argument and an optional port as the second. By default it will check the local system, port 443.
Resolution

To avoid this vulnerability, Red Hat recommends disabling SSL and using only TLSv1.1 or TLSv1.2. Backwards compatibility can be achieved using TLSv1.0. Many products Red Hat supports have the ability to use SSLv2 or SSLv3 protocols, however it is strongly recommended against.

To mitigate this vulnerability as it affects httpd, set the SSLProtocol directive as follows in /etc/httpd/conf.d/ssl.conf:

Note: This directive must either be located at the topmost level of the configuration file, or inside the default virtual host configuration for an address.

Option 1: Disable SSLv2 and SSLv3 (Enable everything except SSLv2 and SSLv3)
SSLProtocol All -SSLv2 -SSLv3

Option 2: Disable everything except TLSv1.x

On RHEL 7 or RHEL 6.6 and later:
SSLProtocol -All +TLSv1 +TLSv1.1 +TLSv1.2

On other platforms:
SSLProtocol -All +TLSv1

Then restart httpd:

# service httpd restart

Resources:
For Microsoft
https://technet.microsoft.com/en-us/library/security/3009008.aspx

https://www.openssl.org/~bodo/ssl-poodle.pdf
http://forums.cpanel.net/f185/sslv3-vulnerability-432641.html

http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html
Tests
Test your web server for SSLv2
https://www.ssllabs.com/ssltest/index.html
What you are looking for is:
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No

For Nginx – there are other files to edit:

/usr/local/psa/admin/conf/templates/default/server/nginxVhosts.php
/usr/local/psa/admin/conf/templates/default/nginxDomainVirtualHost.php
/usr/local/psa/admin/conf/templates/default/domain/nginxDomainVirtualHost.php

Rebuild after any changes

# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

Other Resources:

CPanel/WHM
https://documentation.cpanel.net/display/CKB/How+to+Adjust+Cipher+Protocols

http://www.cpanelkb.net/fix-poodle-sslv3-vulnerability/
http://thecpaneladmin.com/disabling-support-for-sslv3-on-a-cpanel-server/
Plesk
http://kb.sp.parallels.com/en/123160

http://www.percona.com/blog/2014/10/15/how-to-close-poodle-sslv3-security-flaw-cve-2014-3566/
http://bobcares.com/blog/protecting-your-cpanel-whm-server-from-sslv3-poodle-vulnerability-guide-to-mitigate-cve-2014-3566-by-disabling-ssl-3-0-in-exim-apache-nginx-pure-ftp-proftpd-dovecot-and-courier-imap

Products Affected:

Check the version:

[root@server]# rpm -qa | grep bash
bash-completion-1.3-7.el6.noarch
bash-4.1.2-15.el6_4.x86_64

Diagnostic Steps:

Exploit 1 (CVE-2014-6271)

There are a few different ways to test if your system is vulnerable to shellshock. Try running the following command in a shell.

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

If you see “vulnerable” you need to update bash. Otherwise, you should be good to go.

Exploit 2 (CVE-2014-7169)

Even after upgrading bash you may still be vulnerable to this exploit. Try running the following code.

env X='() { (shellshocker.net)=>' bash -c "echo date"; cat echo ; rm -f echo

If the above command outputs the current date (it may also show errors), you are still vulnerable.

Exploit 3 (???)

Here is another variation of the exploit. Please leave a comment below if you know the CVE of this exploit.

env -i X=' () { }; echo hello' bash -c 'date'

If the above command outputs “hello”, you are vulnerable.

Exploit 4 (CVE-2014-7186)

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' ||
echo "CVE-2014-7186 vulnerable, redir_stack"

A vulnerable system will echo the text “CVE-2014-7186 vulnerable, redir_stack”.

Exploit 5 (CVE-2014-7187)

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash ||
echo "CVE-2014-7187 vulnerable, word_lineno"

A vulnerable system will echo the text “CVE-2014-7187 vulnerable, word_lineno”.

Run update:

[root@server ~]# yum update bash
Loaded plugins: downloadonly, fastestmirror, priorities
Loading mirror speeds from cached hostfile
epel/metalink                                            |  16 kB     00:00
 * base: mirror.hmc.edu
 * epel: mirrors.solfo.com
 * extras: centos.sonn.com
 * updates: linux.mirrors.es.net
base                                                     | 3.7 kB     00:00
extras                                                   | 3.3 kB     00:00
updates                                                  | 3.4 kB     00:00
updates/primary_db                                       | 5.3 MB     00:00
81 packages excluded due to repository priority protections
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package bash.x86_64 0:4.1.2-15.el6_4 will be updated
---> Package bash.x86_64 0:4.1.2-15.el6_5.1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package       Arch            Version                   Repository        Size
================================================================================
Updating:
 bash          x86_64          4.1.2-15.el6_5.1          updates          905 k

Transaction Summary
================================================================================
Upgrade       1 Package(s)

Total download size: 905 k
Is this ok [y/N]: y
Downloading Packages:
bash-4.1.2-15.el6_5.1.x86_64.rpm                         | 905 kB     00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : bash-4.1.2-15.el6_5.1.x86_64                                 1/2
  Cleanup    : bash-4.1.2-15.el6_4.x86_64                                                                                                                                                        2/2
  Verifying  : bash-4.1.2-15.el6_5.1.x86_64                                                                                                                                                      1/2
  Verifying  : bash-4.1.2-15.el6_4.x86_64                                                                                                                                                        2/2

Updated:
  bash.x86_64 0:4.1.2-15.el6_5.1

Complete!

[root@server ~]# rpm -qa | grep bash
bash-4.1.2-15.el6_5.1.x86_64
bash-completion-1.3-7.el6.noarch

Test after update:

[root@server ~]# env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

For Ubuntu Systems:

apt-get update; apt-get install --only-upgrade bash

For Arch Linux:

pacman -Sy bash

A reboot is not required after the update.

Resources:

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

http://www.reuters.com/article/2014/09/24/us-cybersecurity-bash-idUSKCN0HJ2FQ20140924

http://seclists.org/oss-sec/2014/q3/685

http://www.vox.com/2014/9/25/6843949/the-bash-bug-explained