Posted on 10-15-2014 10:24 AM
Last Updated: Fri Oct 24 14:00 CDT 2014
A significant vulnerability in the design of SSL version 3.0, commonly referred to as a POODLE attack (Padding Oracle On Downgraded Legacy Encryption), was announced on October 14, 2014.
Additional Details
Below are some links to external resources containing additional details on this vulnerability:
External Resources (Updated)
Below are some links to external resources with more information on how to detect and possibly remediate this vulnerability:
JAMF Software Products and Services
What JAMF Software is doing to fix this (Updated)
Casper Suite version 9.61 will include fixes to address the SSL version 3.0 POODLE vulnerability. The following is a brief summary of the changes:
As always, the Casper Suite Release Notes will include full details on what was fixed in version 9.61:
http://www.jamfsoftware.com/resources/resources-casper-suite/release-notes/
Check your email for the official product release announcement. Product downloads will be available through your JAMF Nation Account:
https://my.jamfsoftware.com/products.html
Best practices for upgrading the JSS are available in the "Preparing to Upgrade the JSS" Knowledge Base article on JAMF Nation:
https://jamfnation.jamfsoftware.com/article.html?id=136
What you might need to do to fix this
JAMF Software recommends following vendor recommendations for updating any affected systems, services, and applications. In addition, the following JAMF Nation Knowledge Base article provides a procedure for mitigating the SSL v3.0 POODLE vulnerability in case you are not able to upgrade to JSS version 9.61 right away:
https://jamfnation.jamfsoftware.com/article.html?id=382
Feel free to reach out to your Support representative through https://support.jamfsoftware.com/ with any questions, or bookmark this discussion post and check back for any available updates.
Thanks,
Jason Van Zanten
Product Specialist, Information Security
JAMF Software
Posted on 10-15-2014 10:31 AM
Thanks Jason!
Boy, busy year for vulnerabilities it seems.
Posted on 10-15-2014 10:34 AM
We're investigating its impact on our customers as well. Definitely been a busy year for vulnerabilities…yikes……
Posted on 10-15-2014 10:36 AM
Who comes up with these names? Poodle? Shellshock? Heartbleed?
Posted on 10-15-2014 10:45 AM
@bpavlov
Would you rather we refer to it as "Padding Oracle On Downgraded Legacy Encryption" attack? :) That doesn't exactly roll off the tongue.
Posted on 10-15-2014 11:01 AM
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...
Posted on 10-15-2014 11:08 AM
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.
Posted on 10-15-2014 11:10 AM
It stands for "Padding Oracle On Downgraded Legacy Encryption"…
Posted on 10-15-2014 11:16 AM
Also disappointingly does not involve actual poodles, which would be much more fun/cute.
Posted on 10-15-2014 12:23 PM
Personally, I'd rather tell people that I'm suffering from 'shellshock' or 'heartbleed' vulnerabilities rather than POODLE !
Posted on 10-15-2014 02:35 PM
My partner has a poodle so I know what it's like to suffer from poodle… (sorry for derailing this obviously important thread, haha)
Posted on 10-16-2014 09:06 AM
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
Posted on 10-16-2014 09:21 AM
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.
Posted on 10-16-2014 12:01 PM
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."
Posted on 10-17-2014 09:08 AM
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.
Posted on 10-29-2014 03:14 PM
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.
Posted on 10-29-2014 05:13 PM
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:
Posted on 10-29-2014 08:53 PM
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:
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
Posted on 10-31-2014 01:19 PM
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
Posted on 10-31-2014 01:27 PM
@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.
Posted on 10-31-2014 01:45 PM
@GaToRAiD Thanks, I will check that out for the FireFox part- I'm sure it will do the trick!