This is a complex question. There are lots of different layers of security in a Ubuntu system, from complex frameworks like AppArmor to humble kernel variables like mmap_min_addr. You can add some kernel features like memory randomization in the mix. You can find a list of them along with a quick explanations on the Ubuntu Wiki.

Another important factor is that the updates are both fast and easy - so most computers will be updated to the last security fixes.

As far as I know, an attacker that has gained local access to your computer has three ways to scale the kernel privileges:

1. Crack the password. But this is going to be really difficult, the password is stored encrypted, using algorithms with no known flaw. It will take ages to crack it.

2. Bug in the kernel. But all the security features of the kernel will get in the way.

3. Trick the user to give away the password, i.e. social engineering. Just show a fake password dialogue or use some other trick. This is the easiest way to do it.

The third point is the weakest vulnerability right now.

Background info

SSL is designed to secure the transport level on the internet. For 'the web' aka HTTP you'll know this as HTTPS, but it's also used for other application protocols. SSLv2 was the first widely used transport security protocol but was found insecure not long after. Successors SSLv3 and TLSv1 are widely supported now. TLSv1.1 and TLSv1.2 are newer and gaining a lot of support too. Most if not all web browsers released from 2014 have support for it.

The recent discovery by Google engineers points out that SSLv3 should not be used any longer (like SSLv2 is deprecated a long time ago). The clients that won't be able to connect to your site/service are probably very very limited. CloudFlare announced that less than 0.09% of their visitors still rely on SSLv3.

Simple solution: disable SSLv3.

Does Ubuntu provide any update?

Yes, via usn-2385-1 with the addition of the SCSV feature, but it does not mitigate the issue completely as it does not disable SSLv3 and the patch will only work if both sides of the connection have been patched. You'll receive it through your regular security updates in your package manager.

So, still YOU have to take action yourself to disable SSLv3 (it's configurable). Future versions of clients/browsers will disable SSLv3 most likely. E.g. Firefox 34 will do so.

Disabling SSLv3 completely by default in Ubuntu on implementation level will probably break some stuff out there also for non-HTTPS SSL usage which is not so much vulnerable, so I assume maintainers won't do that and only this SCSV patch will be applied.

Why does the SCSV update in OpenSSL via usn-2385-1 does not mitigate the issue?

Really, stop asking such questions and just skip a few paragraphs and disable SSLv3. But hey, if you're not convinced, here you go:

POODLE shows that SSLv3 with CBC ciphers is broken, implementing SCSV does not change that. SCSV only makes sure you don't downgrade from some TLS protocol to any lower TLS/SSL protocol as needed with the Man-in-the-Middle attack required for the usual cases.

If you have to access some server which does not offer TLS at all, but only SSLv3, then your browser doesn't really have a choice and has to talk to the server using SSLv3, which is then vulnerable without any downgrade attack.

If you have to access some server which offers TLSv1+ and SSLv3 too (which is discouraged) and you want to be sure your connection will not be downgraded to SSLv3 by an attacker, then both the server and the client need this SCSV patch.

For completely mitigating the issue the disablement of SSLv3 your end is enough and you can be sure you won't be downgraded. And you won't be able to talk to to SSLv3-only servers.

Okay, so how do I disable SSLv3?

See below in the application specific sections: Firefox, Chrome, Apache, Nginx and Postfix are covered for now.

Are only servers or also clients affected?

The vulnerability exists if both the server and client accepts SSLv3 (even if both are capable of TLSv1/TLSv1.1/TLS1.2 due to a downgrade attack).

As a server admin you should disable SSLv3 now for the security of your users.

As a user, you should disable SSLv3 in your browser now to secure yourself when visiting websites which still support SSLv3.

Is this OpenSSL/GnuTLS/browser specific?

No. It's a protocol (design) bug, not an implementation bug. This means you can't really patch it (unless you're changing the design of the old SSLv3).

And yes, there's a new OpenSSL security release, but read below (But I really really need SSLv3 support... for reason X,Y,Z!) on why you'd better focus on disabling SSLv3 altogether.

Can I kill SSLv3 on the network (firewall) level?

Well, yes, probably. I put this in a separate blog post for further thoughts and work. We may have some magic iptables rule you can use!

My blog post: How to take down SSLv3 in your network using iptables for POODLE?

Is it relevant for HTTPS only or also for IMAP/SMTP/OpenVPN and other protocols with SSL support?

The current attack vector, as shown by the researchers, works with controlling the plaintext sent to the server using Javascript being run on the victim's machine. This vector does not apply to non-HTTPS scenarios without using a browser.

Also, normally an SSL client doesn't allow the session to be downgraded to SSLv3 (having TLSv1+ seen in the handshake capabilities), but browsers want to be very backward compatible and they do. The combination with controlling plaintext and the specific way a HTTP header is built up makes it exploitable.

Conclusion: disable SSLv3 for HTTPS now, disable SSLv3 for other services in your next service window.

What's the impact? Do I need to revoke and regenerate my server certificate? (As with Heartbleed)

No, you don't need to rotate your certificates for this. The vulnerability exposes plaintext recovery from the session data, it does not provide access to any secrets (neither the session key or certificate key).

An attacker is most likely only capable of stealing the plaintext headers like session cookies in order to perform session hijacking. An additional constraint is the need for a full (active) MitM attack.

Is there anything else I can do to improve my SSL configuration in general?

As a user, besides disabling SSLv3 in your browser, not really. Well, just always install the latest security updates.

For servers, follow Mozilla's TLS server guide. And test with Qualys' SSL Labs test. It's really not that hard to get an A+ rating on your site. Just update your packages and implement the recommendations from the guide of Mozilla.

But I really really need SSLv3 support... for reason X,Y,Z! Now what?

Well, there's a patch that circumvents the downgrade attack of TLSv1 capable clients, called the SSLv3 Fallback Protection. It will improve the security of TLSv1+ too, by the way (downgrade attack is harder/impossible). It's offered as a backport from a more recent OpenSSL version in the Ubuntu Security advisory usn-2385-1.

Big catch: Both clients and servers need this patch in order to work. So, in my opinion while you're updating both clients and servers you should just upgrade to TLSv1+ anyway.

However, please, please, just retire SSLv3 in your network for now. Put effort in upgrading security standards and just ditch SSLv3.

I heard about SCSV support to eliminate the protocol downgrade attack. Do I need it?

Only if you really need SSLv3 for some odd reason, but it improves security in TLSv1+ too, so yes, I'd recommend you to install it. Ubuntu provides an update for this feature in usn-2385-1. You'll receive it through your regular security updates in your package manager.

Testing vulnerability for privately hosted sites (e.g. intranet/offline).

Your servers are vulnerable simply if they support SSLv3. Several options here:

• With OpenSSL s_client:

  openssl s_client -connect <server>:<port> -ssl3
  

  If the connection succeeds, sslv3 is enabled. If it fails, it is disabled. When it fails you should see something like:

  error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
  

• Using nmap:

  nmap --script ssl-enum-ciphers -p 443 myhostname.tld
  

  It should output 'SSLv3: No supported ciphers found'. Adjust for your hostname/port.

• Using cipherscan. Clone/download the binary and execute it:

  ./cipherscan myhostname.tld
  

  It should not list anything with SSLv3 under the 'protocols' column.

---

Firefox browser

Open about:config, find security.tls.version.min and set the value to 1. Then restart your browser to drop any open SSL connections.

Firefox from version 34 onwards will disable SSLv3 by default and thus require no action (source). However, at the moment of writing, 33 is just released and 34 is set for November 25.

---

Google Chrome (Linux)

Edit the /usr/share/applications/google-chrome.desktop file, e.g.

sudo nano /usr/share/applications/google-chrome.desktop

Edit all lines starting with Exec= to include --ssl-version-min=tls1.

E.g. a line like

Exec=/usr/bin/google-chrome-stable %U

becomes

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Then make sure to fully close the browser (Chrome apps may be keeping your browser active in the background!).

Note: You may need to repeat this every google-chrome package update, overwriting this .desktop launcher file. A Google Chrome or Chromium browser with SSLv3 disabled by default is not yet announced at the time of writing.

---

Apache HTTPD Server

If you are running an Apache web server that currently allows SSLv3, you will need to edit the Apache configuration. On Debian and Ubuntu systems the file is /etc/apache2/mods-available/ssl.conf. On CentOS and Fedora the file is /etc/httpd/conf.d/ssl.conf. You will need to add the following line to your Apache configuration with other SSL directives.

SSLProtocol All -SSLv2 -SSLv3

This will allow all protocols except SSLv2 and SSLv3.

While you're at it, you may want to consider improving the ciphersuite configuration for your webserver as explained on Mozilla's TLS server guide. Add for example:

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"

Then check if the new configuration is correct (no typos etc.):

sudo apache2ctl configtest

And restart the server, e.g.

sudo service apache2 restart

On CentOS and Fedora:

systemctl restart httpd

More info: Apache documentation

Now test it: If your site is publicly available, test it using Qualys’ SSL Labs tool.

---

Nginx server

If you're running Nginx, just include the following line in your configuration among the other SSL directives:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

While you're at it, you may want to consider improving the ciphersuite configuration for your webserver as explained on Mozilla's TLS server guide. Add for example:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;

And restart the server, e.g.

sudo service nginx restart

Reference: Nginx documentation

Now test it: If your site is publicly, available, test it using Qualys' SSL Labs tool.

---

Lighttpd webserver

Lighttpd versions >1.4.28 support a configuration option to disable SSLv2 and v3. Lighttpd releases before 1.4.28 allow you to disable SSLv2 ONLY. Please note that Ubuntu 12.04 LTS and earlier install at best lighttpd v1.4.28 and therefore a simple fix is not available for those distributions. Therefore this fix should only be used for Ubuntu versions greater than 12.04.

For Ubuntu version 12.04 or Debian 6, an updated lighttpd package is available from the openSUSE repository: http://download.opensuse.org/repositories/server:/http/Debian_6.0

The package is intended for Debian 6 (squeeze) but works also on 12.04 (precise)

Edit your /etc/lighttpd/lighttpd.conf to add the following lines after the ssl.engine = "enable" directive

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Then you should restart the lighttpd service with a sudo service lighttpd restart and perform an ssl3 handshake test as described in earlier sections to make sure that the change was implemented successfully.

Taken from http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL.

---

Postfix SMTP

For 'opportunistic SSL' (encryption policy not enforced and plain is acceptable too), you don't need to change anything. Even SSLv2 is better than plain, so if you need to secure your server you should be using 'mandatory SSL' mode anyway.

For 'mandatory SSL' mode being configured already, just add/change the smtpd_tls_mandatory_protocols setting for inbound connections and smtp_tls_mandatory_protocols for outbound connections:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

Optionally, if you want to disable SSLv3 for opportunistic encryption as well (even though it's unnecessary as explained above), do so thusly:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

and restart Postfix:

sudo service postfix restart

---

Sendmail

(Unverified edit by anonymous user, I'm not comfortable with Sendmail, please verify.)

These options are configured in the LOCAL_CONFIG section of your sendmail.mc

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

---

Dovecot

In Dovecot v2.1+, add the following to your /etc/dovecot/local.conf (or a new file in /etc/dovecot/conf.d):

ssl_protocols = !SSLv2 !SSLv3

and restart Dovecot:

sudo service dovecot restart

For older versions you will have to patch the source code.

---

Courier-imap (imapd-ssl)

Courier-imap allows SSLv3 by default on Ubuntu 12.04 and others. You should disable it and use STARTTLS instead to force TLS. Edit your /etc/courier/imapd-ssl configuration file to reflect the following changes

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

---

HAProxy Server

SSL is supported in HAProxy >= 1.5.

Edit the /etc/haproxy.cfg file and find your bind line. Append no-sslv3. For example:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

Reference: HAProxy Documentation

---

OpenVPN

Appears to be unaffected (source).

OpenVPN uses TLSv1.0, or (with >=2.3.3) optionally TLSv1.2 and is thus not impacted by POODLE.

---

Puppet

Puppet uses SSL over HTTPS but it isn't used by 'browser' clients, just Puppet agents which aren't vulnerable to the attack vector shown. However, it's best practice to just disable SSLv3.

My recommendation is to use the stephenrjohnson/puppetmodule Puppet module to set up your Puppet master in which I killed SSLv3 some time ago.