OpenERP and Heartbleed
No doubt by now you will have seen loads of stuff in the media about the Heartbleed bug. This is a pretty bad bug, there have been other huge bugs in the past too, but this one has a very media friendly name and a cute logo so it gets the coverage that it deserves. In short it affects https connections to web servers and other types of server that use ssl in a less obvious way. We have been updating and fixing servers that we host but we know that rather a lot of people have been using our guides to installing OpenERP, if you have, and you set up the https connections to the server (part 2 of the guides), then you are probably vulnerable to the heartbleed bug. OpenERP itself does not do the https bit, we used either Apache or Nginx as a reverse proxy to add the ssl layer.
Firstly use this testing tool http://filippo.io/Heartbleed to see if your system is vulnerable. You may need to check the box to ignore certificates if you are using a self-signed certificate. The fix to OpenSSL is already in the Ubuntu repositories, so you just need to pull the upgrade (this will update all packages, which is fine)
sudo apt-get update
sudo apt-get dist-upgrade
and then restart your webserver service, which could be apache or nginx, if you can’t remember which then just try both, one will fail with an unrecognised service error.
sudo service nginx restart
sudo service apache2 restart
This might get you up and running in seconds, but I found one one machine the openerp process had got a bit upset, if you can’t log in after restarting the web process then you could restart the openerp server process, or just restart everything with:
sudo reboot
Now use http://filippo.io/Heartbleed again to confirm that you are fixed.
If you are not using https you might be fine, you have an inherently less secure connection to your server, but the server won’t serve up it’s memory to anyone who asks for it. Even if you are not using https right now, do update anyway, it is a good thing to do.
The above process only describes part of the process to close the bug. It fixes the original hole, but you should also revoke and re-issue any private keys / stored passwords / etc that were stored on that machine, since it may have been exposed while vulnerable.
yes, that is a good point, this just protects against future attacks, if you have already been attacked (unlikely) and someone had read/write access to your server memory then really the machine should be wiped and rebuilt from the ground up, it could have rootkits and all sorts on it. The general advice seems to be that the likely bad thing to take from the server memory would be the SSL private key, so yes, it would be good to repeat the process of signing a new key, if you have a CA provided key then you can revoke the old one and request a new one, if it is self-signed then you can’t revoke it but you can generate a new one. If an attacker has your private key they can’t do a huge amount with it, they can decrypt the traffic, which puts you back to where you are with regular http, they can also impersonate the server – which would fool browsers that have already accepted the self-signed key. The attacker can’t read and write arbitrary memory using it because this hole is now closed. Repeating the steps in http://www.theopensourcerer.com/2012/03/how-to-openerp-6-1-ubuntu-10-04-lts-nginx-ssl-reverse-proxy/ to create a new key and replace the one in /etc/nginx/ssl/server.key and changing passwords is certainly advisable but the critical issue is closing the hole.
[…] The whole Heartbleed® thing “has a very media friendly name and a cute logo,” as a British FOSS professional put it. It’s like a branding exercise. Also see this post titled “What Heartbleed Can Teach […]