Ike.ninja

WordPress 3.8.3 is now available to fix a small but unfortunate bug in the WordPress 3.8.2 security release.

The “Quick Draft” tool on the dashboard screen was broken in the 3.8.2 update. If you tried to use it, your draft would disappear and it wouldn’t save. While we doubt anyone was writing a novella using this tool, any loss of content is unacceptable to us.

We recognize how much trust you place in us to safeguard your content, and we take this responsibility very seriously. We’re sorry we let you down.

We’ve all lost words we’ve written before, like an email thanks to a cat on the keyboard or a term paper to a blue screen of death. Over the last few WordPress releases, we’ve made a number of improvements to features like autosaves and revisions. With revisions, an old edit can always be restored. We’re trying our hardest to save your content somewhere even if your power goes out or your browser crashes. We even monitor your internet connection and prevent you from hitting that “Publish” button at the exact moment the coffee shop Wi-Fi has a hiccup.

It’s possible that the quick draft you lost last week is still in the database, and just hidden from view. As an added complication, these “discarded drafts” normally get deleted after seven days, and it’s already been six days since the release. If we were able to rescue your draft, you’ll see it on the “All Posts” screen after you update to 3.8.3. (We’ll also be pushing 3.8.3 out as a background update, so you may just see a draft appear.)

So, if you tried to jot down a quick idea last week, I hope WordPress has recovered it for you. Maybe it’ll turn into that novella.

Download WordPress 3.8.3 or click “Update Now” on Dashboard → Updates.

This affected version 3.7.2 as well, so we’re pushing a 3.7.3 to these installs, but we’d encourage you to update to the latest and greatest.

Now for some good news:
WordPress 3.9 is near.
Expect it this week

cPanel Security Team: Heartbleed Vulnerability

Heartbleed is a serious vulnerability in OpenSSL 1.0.1 through 1.0.1f.

This vulnerability allows an attacker to read 64 kilobyte chunks of memory from from servers and clients that connect using SSL through a flaw in the OpenSSL’s implementation of the heartbeat extension.

What does this mean for cPanel servers?

cPanel & WHM does not provide any copies of the OpenSSL library. The daemons and applications shipped with cPanel & WHM link to the version of OpenSSL provided by the core operating system. RedHat 6, CentOS 6, and CloudLinux 6 provided vulnerable versions of OpenSSL 1.0.1. All three distros have published patched versions of their OpenSSL 1.0.1 RPMs to their mirrors. To update any affected servers, run “yum update” to install the patched version of OpenSSL and restart all SSL-enabled services or reboot the system.

You can ensure you are updated by running the following command:

<br />

# rpm -q --changelog openssl | grep -B 1 CVE-2014-0160<br />

* Mon Apr 07 2014 Tomáš Mráz 1.0.1e-16.7<br />

- fix CVE-2014-0160 - information disclosure in TLS heartbeat extension<br />

You should see the information noting the fix to CVE-2014-0160.

RHEL/CentOS 5 servers, which are using the OpenSSL 0.9.8 RPM included in the official OS repositories, are not vulnerable to the Heartbleed issue since they are using an older version of OpenSSL that never contained this vulnerability.

What steps do I need to take as an Admin/root of our servers running cPanel & WHM?

Once the RPM of OpenSSL has been updated you should reset all certificates via the Manage Service SSL Certificates interface in WHM.

Home » Service Configuration » Manage Service SSL Certificates

You will need to click the ‘Reset Certificate’ link for each service: FTP, Exim, cPanel/WHM/Webmail Service, and Dovecot or Courier Mail Server.

You should also check the SSL certificates in the Manage SSL Hosts interface of WHM.

Home » SSL/TLS » Manage SSL Hosts

Many Certificate Authorities are helping their customers regenerate SSL certificates at no cost. This may vary and your Certificate Authority should be contacted prior to any actions to ensure the proper procedures are followed.

Do we need to reset our passwords and regenerate our private and public keys on the server?

Due to the nature of the vulnerability it is impossible to know what other information, including private keys, passwords, and session ID’s, has been compromised. The attack occurs before a full connection to your server has been made, leaving no indications in any logs that an attack has occurred. It is recommended that you regenerate all SSH keys and reset all passwords across the server.