28

I have an Ubuntu 12.04 server. I have updated the OpenSSL package in order to fix the heartbleed vulnerability. But I am still vulnerable even, even though I have restarted the web server, and even the whole server.

To check my vulnerability I used:

dpkg gives:

dpkg -l |grep openssl
ii  openssl  1.0.1-4ubuntu5.12   Secure Socket Layer (SSL) binary and related cryptographic tools

(launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12)

Improve this question
3
  • Output of openssl version -a?
    – Nathan C
    Apr 8, 2014 at 17:55
  • I'm running 12.04 server (with nginx) too. Mine is setup to automatically install security updates and when I run the python script it says not vulnerable. Did you install nginx from from package repository or manually?
    – mikeazo
    Apr 8, 2014 at 18:33
  • 1
    What are you running on this port? If it's a 3rd party app, you might have a static library
    – Nathan C
    Apr 9, 2014 at 18:58

8 Answers 8

Reset to default
29

Ensure that the libssl1.0.0 package has been updated as well (that package contains the actual library, the openssl package contains the tools) and that all services using the library have been restarted after the upgrade.

You have to RESTART all services using openssl (service apache restart).

Improve this answer
1
  • 4
    To get a list of the services using your older, now-replaced version of libssl, try: "lsof -n | grep ssl | grep DEL". Or, if you're super-paranoid, you can get a list of everything using any version of libssl: "lsof -n | grep libssl | cut -c1-10 | sort | uniq"
    – Jemenake
    Apr 9, 2014 at 17:12
3

It's possible you are a false positive case, per the FAQ:

I'm getting false positives (red)!

Be careful, unless you glitched the site hammering the button, there is no way I can think of a red is not a red.

Check the memory dump, if it's there then the tool got it from somewhere.

Let's say I'm 99% certain that you should look better if you restarted all processes after updating correctly.

Update: still, I'm getting consistently reports of unaffected versions going red. Please come comment to the issue if you are affected. I'm looking for 3 things: memory dumps (to figure out where they came from), timestamps (as accurate as possible, try with the Network tab), a complete description of what you clicked and typed.

You can test your site using another tool like SSLLabs, and see if you are still reported as vulnerable.
You should also report the issue with the http://filippo.io/Heartbleed tester as described above.

Improve this answer
2
  • Came up as vulnerable to Heartbleed using SSLLabs
    – Matt
    Apr 9, 2014 at 18:52
  • @Matt You may in fact have a problem then - check out the memory dump (are you getting one?) and hook up with the nice folks behind the filippo.io tool.
    – voretaq7
    Apr 9, 2014 at 18:54
2

If you happen to be running mod_spdy make sure you update your mod_spdy install. See https://groups.google.com/forum/#!topic/mod-spdy-discuss/EwCowyS1KTU for details. You'll need to either upgrade the mod_spdy deb or remove the previous version completely.

Improve this answer
2

You likely have a program listening on 443 that has a staticly-linked openssl library. This means the program has its own openssl packaged with it - update this program, too! If one's not available, notify the vendor immediately and suspend this application if at all possible!

Improve this answer
2

It is possible that you are experiencing the bug listed on the FAQ page. It appears that under certain circumstances that you can get a vulnerable notification even on a patched system.

I'm getting false positives (red)!

Be careful, unless you glitched the site hammering the button, there is no way I can think of a red is not a red. Check the memory dump, if it's there then the tool got it from somewhere. Let's say I'm 99% certain that you should look better if you restarted all processes after updating correctly.

Update: still, I'm getting consistently reports of unaffected versions going red. Please come comment to the issue if you are affected. I'm looking for 3 things: memory dumps (to figure out where they came from), timestamps (as accurate as possible, try with the Network tab), a complete description of what you clicked and typed.

I would suggest testing with an alternate test such as Qualys to confirm that your system is no longer vulnerable. If it isn't head over to Github and report it.

It's still broken

What is? The "server" you talk about may have a static linked OpenSSl library. This means that even though you updated your system your application is still at risk! You need to talk to the software vendor immediately to get a patch or turn off the service until you do.

Do I really have to disable the service until the patch is out?

Yes, running a vulnerable service is extremely dangerous to the point of possible negligence! You could be leaking any data that the server decrypts from transport and not even know it!

Improve this answer
1

Make sure that your nginx uses system library: http://nginx.com/blog/nginx-and-the-heartbleed-vulnerability/

Improve this answer
0

This is very possible if the application running on 443 uses a static library for OpenSSL. If this is the case, you have to update that application to not be vulnerable anymore.

Improve this answer
0

I was finally able to fix my issue that was similar to OP. My server is a LAMP stack from Bitnami. Following these instructions :

wget http://downloads.bitnami.com/files/download/opensslfixer/bitnami-opensslfixer-1.0.1g-     1-linux-x64-installer.run
chmod 755 bitnami-opensslfixer-1.0.1g-1-linux-x64-installer.run
./bitnami-opensslfixer-1.0.1g-1-linux-x64-installer.run --forcefix 1 --forcelegacy 1

http://community.bitnami.com/t/apache-error-after-the-recommended-heartbleed-patch/23530/9

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .