Security Update: SSL version 3.0 "POODLE" Vulnerability

Thanks Jason!

Boy, busy year for vulnerabilities it seems.

We're investigating its impact on our customers as well. Definitely been a busy year for vulnerabilities…yikes……

Who comes up with these names? Poodle? Shellshock? Heartbleed?

@bpavlov
Would you rather we refer to it as "Padding Oracle On Downgraded Legacy Encryption" attack? :) That doesn't exactly roll off the tongue.

No it doesn't roll off the tongue. And I don't particularly have a better alternative. Sorry to take this off topic, but it was just something I noticed is all. In reading the article on openssl.org, there's even mention of the BEAST attack. It's almost like taking a queue from politicians and the names they come up with for some of their legislation. Anyways, I digress...

I think the names are simply created so there are easy to recall acronyms, so the issue can be discussed without needing to refer to some obtuse or overly verbose name, like "Padding Oracle On Downgraded Legacy Encryption vulnerability" Something like that isn't likely to be noticed at all by the general public, and possibly even some IT folks, but "ShellShock", "POODLE", etc. have better chances of being noticed and acted on.

It stands for "Padding Oracle On Downgraded Legacy Encryption"…

Also disappointingly does not involve actual poodles, which would be much more fun/cute.

Personally, I'd rather tell people that I'm suffering from 'shellshock' or 'heartbleed' vulnerabilities rather than POODLE !

My partner has a poodle so I know what it's like to suffer from poodle… (sorry for derailing this obviously important thread, haha)

Any update on fixing this issue on the JSS?

You can run this command from a terminal to check your servers:

openssl s_client -connect example.com:443 -ssl3

Replace example.com with your server name and in the case of the JSS, you will need to replace 443 with 8443. Will JAMF be providing instructions for disabling SSLv3 on tomcat?

Thanks,
Doug

Would you really have to worry about your own JSS having the ability to let clients connect via SSLv3? I think the problem is when you connect to an SSL website with your browser and the browser lets SSLv3 happen, the website could then exploit your browser. Since I don't suspect you want to ruin your own client workstations, you probably will not be exploiting them through your own web server right? Unless I mis-understand and there is a way that the client can exploit the server by getting the servers v3 SSL cert and opening a channel. If that is the case then I suppose if your JSS is on the external internet that could be a problem. Interesting for sure.

True, but we should be patching both ends, the clients and the server. As best I can tell, the attached would basically perform a man in the middle attack on the client, so technically, no, the server is not immediately in danger. However, I think it is responsible to disable SSLv3 on any servers that are currently running it. How long will it be before an attack is devised on the server side? From one of the sites referenced above: "As a server operator, it is possible to stop this attack by disabling SSLv3, or by disabling CBC-mode ciphers in SSLv3. However, the compatibility impact of this is unclear. Certainly, disabling SSLv3 completely is likely to break IE6. Some sites will be happy doing that, some will not."

It's more of an issue with man-in-the-middle type attacks. Basically an intermediate server, as it's forwarding along your packets to the destination server, modifies the original request to force TLS to fail. Both client and server fallback to SSL, which the intermediate server is able to decode.

So JAMF has patched this issue on the JSS with 9.61, but no patch as of yet for the NetSUS appliance, correct? I am preparing to remediate all of our NetSUSes manually, but I didn't want to do this if there was a patch available/forthcoming.

Incidentally, patching manually on the NetSUS appliances can be accomplished via the following commands, issued as root:

sed -i 's/-SSLv2/-SSLv2 -SSLv3/' /etc/apache2/mods-enabled/ssl.conf; /etc/init.d/apache2 restart

Once this config change is complete, the NetSUS no longer allows SSLv3 connections:

my_computer:~ username$ openssl s_client -connect mynetsus.company.com:443 -ssl3
CONNECTED(00000003)
48725:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52/src/ssl/s3_pkt.c:1125:SSL alert number 40
48725:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52/src/ssl/s3_pkt.c:546:

@andyinindy:

An updated version of the NetBoot/SUS Appliance OVA is currently in progress and will likely include bug fixes in addition to configuration changes for Apache to address the SSL version 3.0 POODLE vulnerability. The updated OVA will be available as soon as testing is complete, which is expected sometime within the next week or so.

Check the Third-Party Product on JAMF Nation and/or the open source NetSUS project on GitHub for the latest available Installer and OVA downloads:

• https://jamfnation.jamfsoftware.com/viewProduct.html?id=180
• https://github.com/jamf/NetSUS
• https://github.com/jamf/NetSUS/blob/master/README.md

It looks like the "webadminInstall.sh" script already includes changes similar to what was posted in a previous comment:

https://github.com/jamf/NetSUS/blob/master/webadmin/webadminInstall.sh

RedHat or CentOS:
sed -i 's/SSLProtocol all -SSLv2/SSLProtocol all -SSLv2 -SSLv3/' /etc/httpd/conf.d/ssl.conf

Ubuntu:
sed -i 's/SSLProtocol all -SSLv2/SSLProtocol all -SSLv2 -SSLv3/' /etc/apache2/mods-enabled/ssl.conf

Hello,
I have been having issues trying to mitigate SSL3 on Chrome and Firefox browsers. First Chrome: a colleague came up with this nifty script to check for Chrome running, it's ssl state, and if using ssl to countdown a close and restore Chrome using arguments to set tls1. However, when run locally it works fine on 10.8.5 and 10.9.5. When run through a policy it fails most of the time to run the countdown or relaunch/restore Chrome. It seems to close Chrome fine. Perhaps someone has a idea of what is happening? if it's a script syntax issue you see can you be specific in the alternative? I'm not much of a script writer! Apologies for the possibly incorrectly formatted post.

#!/bin/sh

#!/bin/bash
iCountDown=30
iCountInterval=5
iCountProcess=$(ps -e |grep -v grep| grep -c -i "Chrome")

if [ $iCountProcess -gt 0 ]; then
   iCountProcess=$(ps -e |grep -v grep |grep -c -i "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --ssl-version-min=tls1 --ssl-version-fallback=tls1")
   if [ $iCountProcess -eq 0 ]; then
      iPid=$(ps -A |grep -v grep| grep -m1 -i "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" | awk '{print $1}');

      while [ $iCountDown -gt 0 ];
      do
        sReturn=`osascript -e "tell app "System Events" to display dialog "You are running an unsecured session of Chrome and will be restored in $iCountDown seconds. Click OK to restore now." buttons {"OK"} default button 1 with title "Google Chrome Monitor" with icon 2 giving up after $iCountInterval"`
         if [[ $sReturn = "button returned:OK, gave up:false" ]]; then
            break
         fi
         iCountDown=$[$iCountDown-$iCountInterval]
      done;
      kill -9 $iPid;
      sleep 2;
      open -a "Google Chrome.app" --args --ssl-version-min=tls1 --ssl-version-fallback=tls1 --restore-last-session;
   fi
fi
[script]#!/bin/sh

For Firefox, I attempted to use composer to create a dmg for the ssl version control addiin using a New and Modified snapshot. https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/. Anyone have success with this. I know we can just wait a couple weeks for new versions of the browsers but Info-security Group will not wait that long! Thanks in advance.
-CL

@Lindsay you could try to manage the settings of firefox. Here is a link on how to manage the pref's and then lock them so users can't modify them. http://kb.mozillazine.org/Lock_Prefs This is how we manage our firefox, you should be able to lockdown ssl as well from the settings i'm seeing in the about:config page.

@GaToRAiD Thanks, I will check that out for the FireFox part- I'm sure it will do the trick!