(Apr 9) Updated samba4 packages that fix three security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having Moderate [More…]
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
Only 30,000 of the 500,000+ SSL certificates affected by the Heartbleed bug have been reissued up until today, and even fewer certificates have been revoked.
Some of the first sites to deploy newly issued certificates in response to the OpenSSL vulnerability included Yahoo, Adobe, CloudFlare, DuckDuckGo, GitHub, Reddit , Launchpad, PayPal, Netflix and Amazon’s CloudFront content delivery network.
Such is the haste to fix the fallout of the Heartbleed bug, some certificate authorities and website administrators have been making careless mistakes. PayPal’s Hosted Message Applications, such as the one at
https://view.paypal-communication.com, are now using Extended Validation certificates issued by VeriSign on 10 April 2014. The
CAB Forum requires certificate authorities to adhere to a
stringent set of guidelines [pdf] when issuing EV certificates, and it is the CA’s responsibility to verify the accuracy of the information in the certificate. In particular, they must verify that the legal name of the subject in an EV certificate matches the name which appears on official government records.
However, this verification does not appear to have been performed correctly in the case of these certificates, as they have been erroneously issued to an organisation named "PayPal, Inc.\0a" instead of "PayPal, Inc."
If you don’t revoke your certificate, you may still be vulnerable to impersonation
If your private key has been stolen, just reissuing the certificate is not enough to mitigate the risks posed by the Heartbleed bug. Websites which were affected by the bug could still be vulnerable to impersonation attacks in the future if they fail to revoke their certificates, even if they have upgraded to the latest version of OpenSSL and replaced their SSL certificates.
If a remote attacker successfully retrieved private keys from a server while it was still vulnerable to the Heartbleed bug, then he would be able to impersonate the server by creating his own valid SSL certificate. The crucial issue is that an attacker can still do this after the affected website has upgraded to the latest version of OpenSSL, and it does not matter whether the real website has since deployed a new SSL certificate with different keys: Unless the previous certificate is revoked, the site will still be vulnerable to man-in-the-middle attacks.
Despite the importance of revoking certificates which could have been stolen using the Heartbleed bug, many website administrators and certificate authorities have yet to do this. Activity on certificate revocation lists peaked at a rate of 2,600 revocations per hour on the day the Heartbleed bug was announced (Monday April 7, 2014). On a typical Monday, we would expect to see a total of around 10,000-14,000 SSL certificates being revoked over the course of the day. On the Monday that the Heartbleed bug was announced to the public, this figure jumped to more than 18,000, suggesting that at least 4,000 of these revocations were in direct response to the Heartbleed bug. On the next day (Tuesday), 16,000 certificates were revoked, followed by 17,000 on Wednesday. Note that fewer revocations usually take place over weekends.
Certificate authorities must revoke certificates within 24 hours if there is evidence of a key compromise. A private key is said to be compromised if its value has been disclosed, or if there exists a practical technique by which an unauthorised person may discover its value. Arguably, all certificates on sites vulnerable to the Heartbleed bug should be revoked by now, as such a technique was successfully carried out by the researchers behind heartbleed.com.
Even if you revoke your certificate, you may still be vulnerable to impersonation
However, even if all of the affected certificates were to be revoked, contemporary web browser software handles certificate revocation poorly. The most frequent users of a site — often its administrators — can continue using a revoked certificate for weeks or months without the browser notifying them that anything is amiss. In this situation, an attacker can perform a man-in-the-middle (MITM) attack by presenting the certificate to unsuspecting users whose browsers will behave as if they were connecting to the legitimate site. For example, some browsers only perform OCSP revocation checks for Extended Validation certificates, while others ignore certificate revocation lists completely.
You are encouraged to read our previous article on certificate revocation.
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.
The following issue was resolved:
[-] Integration with Key Administrator Partner Central did not work in Plesk 11.5. (PPPM-1552)