How to fix Heartbleed Vulnerability on LAMP Server (Apache PHP) CVE-2014-0160

OpenSSL which is used by several million websites was found vulnerable to the heartbleed vulnerability. Thankfully it is quick and easy to fix following these instructions.

Why do I need to fix it?

When it is exploited it leads to the leak of memory contents from the server to the client. This means anything in the server memory (RAM) could be potentially sent to a person exploiting the bug. Here are examples of what is on your server memory:
1) The encryption keys themselves
2) User names and passwords used on the web
3) PHP Session IDs
4) Data being sent to other users

How can I test the vulnerability?

We used a python script to test the vulnerability on our servers. A single python file which sends the target server a carefully crafted heartbeat message and waits for the server to send back a lot of sensitive information. Alternatively you can use the SSL test tool on the ssllabs website.

How to fix on CentOS

>sudo yum update openssl
>service httpd restart

How to fix on Ubuntu

>sudo apt-get upgrade openssl
>service apache2 restart

Other things to consider

– Are there any other software statically linked to OpenSSL? Nginx? Ruby? PHP? You need to recompile or restart them
– Replace any API tokens or passwords in use
– You might have to create a new private key and CSR to get a new SSL certificate
– Do you feel like your users might have been compromised? You will then need to ask them to change passwords

Also read...

Comments

  1. Jamie said on :

    Thanks for posting. Recommended to fix this immediately.

    I guess graceful restart should also do?
    Redhat / CentOS / RHEL / Fedora Linux with:
    apachectl -k graceful

  2. Paul S said on :

    For anyone interested in the diff of the actual bug in openssl and the fix pastebin.com 5PP8JVqA

    /* Read type and payload length first */
    if (1 + 2 + 16 > s->s3->rrec.length)
    return 0; /* silently discard */
    hbtype = *p++;
    n2s(p, payload);
    if (1 + 2 + payload + 16 > s->s3->rrec.length)
    return 0; /* silently discard per RFC 6520 sec. 4 */
    pl = p;

    This does two things: the first check stops zero-length heartbeats. The second check checks to make sure that the actual record length is sufficiently long. That’s it.

  3. Adrian the monk said on :

    SSL / TLS has a not so frequently used heartbeat method . The allows a browser / user to say “here is N bytes of data, please echo it back to me”, then send N bytes of data.

    OpenSSL has a buffer where it stores a raw TLS message when it comes in, just as it came in over the wire, before it parses and handles it. The bug is that it allocates a buffer of size N and then copies N bytes of data from that spot regardless of whether the peer actually sent N bytes like it promised it would. If the peer sent fewer than N bytes, the raw TLS message will be shorter.

    So if you promise 65535 bytes of data but send 1, it will copy your 1 byte into its buffer plus 65534 bytes of whatever is after the raw TLS message. Then later it will echo all 65535 bytes of data in the buffer back to you over the TLS connection.

    So, wherever OpenSSL happens to put the raw TLS message in memory, you can read almost 64K of whatever data is after that. And you can do it essentially as often as you want.

  4. konrad said on :

    sorry if it sounds lame…. can i do it on shared hosting with SSL access?

Comments are closed.