Jamf Nation Community

jason_vanzanten · ‎10-15-2014

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:

Google Online Security Blog - http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
Security Advisory paper - https://www.openssl.org/~bodo/ssl-poodle.pdf
"Poodlebleed" website - http://poodlebleed.com/
Adam Langley's ImperialViolet blog - https://www.imperialviolet.org/2014/10/14/poodle.html
CVE:
- http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566

External Resources (Updated)

Below are some links to external resources with more information on how to detect and possibly remediate this vulnerability:

Apple - http://support.apple.com/kb/HT1222
- Support for SSL version 3.0 is still available but CBC cipher suites are now disabled when TLS connection attempts fail.
- Updates are available through Software Update or directly from Apple Support - http://support.apple.com/downloads/
  - OS X Yosemite 10.10 - https://support.apple.com/kb/HT6535
  - Security Update 2014-05 (OS X Mavericks 10.9.5 & OS X Mountain Lion 10.8.5) - https://support.apple.com/kb/HT6531 (Also includes contents of "OS X bash Update 1.0" for Bash Shellshock vulnerability)
  - iOS 8.1 - http://support.apple.com/kb/HT6541
  - Apple TV 7.0.1 - http://support.apple.com/kb/HT6542
- Server.app - available through the Mac App Store
  - v4.0 (OS X Yosemite 10.10) - https://support.apple.com/kb/HT6536
  - v3.2.2 (OS X Mavericks 10.9.5) - https://support.apple.com/kb/HT6527
  - v2.2.5 (OS X Mountain Lion 10.8.5) - https://support.apple.com/kb/HT6529
- Apple Push Notification services (APNs) - https://developer.apple.com/news/?id=10222014a
  - SSL 3.0 will be disabled on October 29, 2014
  - Development environment is available for testing now
Ubuntu - http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-...
Red Hat - https://access.redhat.com/articles/1232123
Microsoft - https://technet.microsoft.com/en-us/library/security/3009008.aspx
Amazon Web Services security advisory - http://aws.amazon.com/security/security-bulletins/CVE-2014-3566-advisory/
OpenSSL Security Advisory - https://www.openssl.org/news/secadv_20141015.txt
SSL Labs client test - https://dev.ssllabs.com/ssltest/viewMyClient.html
"Poodletest" website - http://poodletest.com/

JAMF Software Products and Services

JAMF Software Server (JSS) version 9.6 or earlier specifies the use of TLS connections in the Apache Tomcat server configuration file (server.xml) but does not explicitly disable any other protocols, including SSL version 3.0.
The jamf binary and client applications use the default SSL provided by the host operating system.
JAMF Distribution Server (JDS) jamfds binary version 9.6 or earlier explicitly specifies the use of SSL version 3.0 for connections with the JSS and other JDS instances for replicating packages, but client connections use the SSL protocol(s) configured for Apache.
JSS Conduit version 2.3 or earlier requires Java 7 on the system running the Conduit with any associated Plug-ins, including the JSS-to-JSS, SCCM Conduit Plug-in, Altiris Conduit Plug-in, and SIS Importer.
JAMF Nation, JAMF Push Proxy, and JAMF Authorization Service have all been reconfigured to disable the use of SSL version 3.0.
JAMF Cloud JSS Hosting service requires configuration changes that will be made during the next maintenance window, and JAMF Software will reach out to individual customers who may be affected.
NetBoot/SUS Appliance OVA version 3.0.1 or earlier has not been fully tested, but it is likely that the web admin portion uses SSL version 3.0 as provided by Apache.

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:

JAMF Software Server (JSS) version 9.61 default server.xml file now only supports Transport Layer Security (TLS) and disables support for SSL version 3.0. The existing server.xml file will be modified to only support TLS when upgrading the JSS on OS X and Linux, but manual changes will be required when upgrading the JSS on Windows (see Casper Suite Release Notes for more details).
JAMF Distribution Server (JDS) jamfds binary version 9.61 now uses Transport Layer Security (TLS) instead of SSL version 3.0.
JSS Conduit version 2.31 now uses Transport Layer Security (TLS) instead of SSL version 3.0, regardless of Java version on the system running the JSSConduit.jar.

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

mm2270 · ‎10-15-2014

Thanks Jason!

Boy, busy year for vulnerabilities it seems.

emily · ‎10-15-2014

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

bpavlov · ‎10-15-2014

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

mm2270 · ‎10-15-2014

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

bpavlov · ‎10-15-2014

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...

mm2270 · ‎10-15-2014

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.

emily · ‎10-15-2014

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

emily · ‎10-15-2014

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

dpertschi · ‎10-15-2014

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

emily · ‎10-15-2014

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

dpenny · ‎10-16-2014

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

nessts · ‎10-16-2014

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.

dpenny · ‎10-16-2014

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."

Josh_S · ‎10-17-2014

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.

andyinindy · ‎10-29-2014

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.

andyinindy · ‎10-29-2014

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:

jason_vanzanten · ‎10-29-2014

@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:

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

Xopher · ‎10-31-2014

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

GaToRAiD · ‎10-31-2014

@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.

Xopher · ‎10-31-2014

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

Jamf Nation Community

Security Update: SSL version 3.0 "POODLE" Vulnerability