# Might wanna recompile or patch that OpenSSL, buddy (4/7/2014)



## texteditor (Apr 7, 2014)

http://heartbleed.com/

http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerabilities

https://access.redhat.com/security/cve/CVE-2014-0160

https://www.openssl.org/news/secadv_20140407.txt

OpenSSL's TLS ~1.0.1 through 1.0.2+ has a leak in the heatbeat extension that can cause private key leakage. A patched version is out allegedly, or you can rebuild OpenSSL with the -DOPENSSL_NO_HEARTBEATS. flag

Happy patchin'


----------



## tchen (Apr 7, 2014)

Useful test

http://filippo.io/Heartbleed


----------



## HalfEatenPie (Apr 7, 2014)

Thanks a ton!  Pretty important information right here!


----------



## sv01 (Apr 7, 2014)

thanks, just update my Debian


----------



## thedediguy (Apr 7, 2014)

why thank you


----------



## jarland (Apr 7, 2014)

Thanks for the heads up. All patched where it matters. The rest...meh hack away 


Easily scripted for centos 6, for the lazy. Stolen entirely from a source Ryan linked me to and turned into a quick bash script to make it faster to push.

http://dal.jarland.me/openssl.sh


Source: http://www.ptudor.net/linux/openssl/


----------



## wlanboy (Apr 8, 2014)

Damn - just thinking about re-issue my SSL cert.


----------



## peterw (Apr 8, 2014)

tchen said:


> Useful test
> 
> http://filippo.io/Heartbleed


All of my domains are vulnerable. Shit.


----------



## George_Fusioned (Apr 8, 2014)

After updating the OpenSSL package, check which services are using the old OpenSSL libraries with 'lsof -n | grep ssl | grep DEL' - then restart as needed.


----------



## eva2000 (Apr 8, 2014)

CentOS updated openssl is available now according to https://rhn.redhat.com/errata/RHSA-2014-0376.html


```
yum list openssl openssl-devel -q
Installed Packages
openssl.x86_64                                                             1.0.1e-16.el6_5.4                                                       @updates
openssl-devel.x86_64                                                       1.0.1e-16.el6_5.4                                                       @updates
Available Packages
openssl.x86_64                                                             1.0.1e-16.el6_5.7                                                       updates 
openssl-devel.x86_64                                                       1.0.1e-16.el6_5.7                                                       updates
```


----------



## Nikki (Apr 8, 2014)

Debian Wheezy also has an updated openssl.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743883


----------



## perennate (Apr 8, 2014)

vpsboard still vulnerable?


----------



## howardsl2 (Apr 8, 2014)

Relevant changelog for Ubuntu openssl package:

https://launchpad.net/ubuntu/+source/openssl/+changelog

Run "apt-get update; apt-get upgrade" to see other software that have been updated in the Ubuntu repos. Before doing that, make sure you have "deb http://security.ubuntu.com/ubuntu ... " in your "/etc/apt/sources.list".


----------



## Ishaq (Apr 8, 2014)

By the way, OpenSSH is NOT vulnerable to this. Because it does not use the TLS protocol. So you don't need to worry about changing keypairs, etc.


----------



## Nikki (Apr 8, 2014)

Here's a better script to test your servers, found it earlier after searching around. When it comes to things like this, even if a site seems very trustworthy you should never rely on them to test vulnerabilities.

https://gist.github.com/takeshixx/10107280


----------



## DomainBop (Apr 8, 2014)

George_Fusioned said:


> After updating the OpenSSL package, check which services are using the old OpenSSL libraries with 'lsof -n | grep ssl | grep DEL' - then restart as needed.


I think that bears repeating.   Also, if you have an OpenVZ VPS, depending on the kernel version, that command may not give any output and so you may have to run just "lsof -n | grep ssl" and restart anything that uses SSL to be on the safe side (or you could just reboot...)

On another note, I just discovered that lsof wasn't installed on my Vultr Tokyo VPS (fixed by apt-get lsof)


----------



## Magiobiwan (Apr 8, 2014)

FYI, CentOS 6.5 will still have the version "e" version string, but it WAS Backported.


----------



## jarland (Apr 8, 2014)

Got the update today. Apparently the guide+script I linked before doesn't fix it, I just got false negatives from that test site and I'm not ashamed to say I couldn't test this exploit if my life depended on it. Yum update it is!


----------



## MannDude (Apr 8, 2014)

perennate said:


> vpsboard still vulnerable?


Still waiting to get my cert reissued. Already ran the updates and still getting positives, though now the site is claiming it's issuing false positives due to load...


----------



## DomainBop (Apr 8, 2014)

Nikki said:


> Debian Wheezy also has an updated openssl.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743883


Debian Wheezy has issued 2 fixes in the past 24 hours so if you updated it last night you need to do it again. 

1.0.1e-2+deb7u5 <--last night's upgrade

1.0.1e-2+deb7u6 <--today's upgrade (today's upgrade will restart some services but not all so you'll still need to check with lsof or reboot)


----------



## wlanboy (Apr 8, 2014)

DomainBop said:


> Debian Wheezy has issued 2 fixes in the past 24 hours so if you updated it last night you need to do it again.


And don't forget to:


Recompile everything that depends on openssl
Restart all services depending on openssl


----------



## howardsl2 (Apr 8, 2014)

DomainBop said:


> Debian Wheezy has issued 2 fixes in the past 24 hours so if you updated it last night you need to do it again.
> 
> 1.0.1e-2+deb7u5 <--last night's upgrade
> 
> 1.0.1e-2+deb7u6 <--today's upgrade (today's upgrade will restart some services but not all so you'll still need to check with lsof or reboot)


Related new announcement - http://seclists.org/bugtraq/2014/Apr/34

Quoted from link: "In case of doubt a full system restart is recommended."


----------



## Nick_A (Apr 8, 2014)

Please fix VPSB D:


----------



## willie (Apr 8, 2014)

There is also insecurity on the client side, so you have to upgrade that too, not just the server, if you're using openssl clients for something.


----------



## adly (Apr 8, 2014)

Looking like it's still waiting on the certificate to be reissued. Any idea on when that will be done?


----------



## MannDude (Apr 8, 2014)

adly said:


> Looking like it's still waiting on the certificate to be reissued. Any idea on when that will be done?


It's been reissued but I am at work and little I can do for this right now. I shouldn't even be on vpsB right now.

I get off in 5 hours. I got the SSL reissued so now just need to update everything.


----------



## lbft (Apr 8, 2014)

https://www.mattslifebytes.com/?p=533

https://www.michael-p-davis.com/using-heartbleed-for-hijacking-user-sessions/

It's possible to hijack sessions on vulnerable servers - for example, someone provided proof that they were able to access my VPSBoard account that way.

Perhaps it's a good idea to avoid logging in to sensitive systems until their servers are fixed.


----------



## MannDude (Apr 8, 2014)

Fixed.


----------



## Francisco (Apr 8, 2014)

Looks to be good now 

Over here I'm seeing that it's EOF'ing the heartbeat crap and the certificate was changed to one

issued just today.

Good work everyone,

Francisco


----------



## eva2000 (Apr 8, 2014)

Indeed good work...

anyone subscribing to http://www.hostingseclist.com ? seems useful


----------



## jarland (Apr 8, 2014)

eva2000 said:


> Indeed good work...
> 
> 
> anyone subscribing to http://www.hostingseclist.com ? seems useful


Been quite useful I'll admit. Every time something gets stacked on the to-do list, keeping up with these things proves more difficult without assistance.


----------



## eva2000 (Apr 8, 2014)

subscribed now myself

another cool tool to check for this on sites you visit that use https/SSL https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafdggilajhpic


----------



## willie (Apr 8, 2014)

The new certificate is misconfigured so it throws error dialogs when you visit the site.  It's supposed to be chained with an intermediate certificate that probably came with it in the email from the CA, but otherwise should be available on the CA website someplace.

Edit: it's fixed now.  Some kind of CDN thing?  It definitely didn't send the intermediate cert when I check in a few minutes ago, but it sends it now.


----------



## MannDude (Apr 8, 2014)

willie said:


> The new certificate is misconfigured so it throws error dialogs when you visit the site.  It's supposed to be chained with an intermediate certificate that probably came with it in the email from the CA, but otherwise should be available on the CA website someplace.
> 
> Edit: it's fixed now.  Some kind of CDN thing?  It definitely didn't send the intermediate cert when I check in a few minutes ago, but it sends it now.


Fixed. Globalsign got a new middle cert.

Was working in Chrome/Chromium without issue. Seems like FF and derivatives were throwing up warnings. Should be good now.


----------



## wlanboy (Apr 9, 2014)

Hopefully all clients (Browser, Email, OpenVPN, IRC, well all using SSL) will have that patch soon too.


----------



## adly (Apr 9, 2014)

Nice, looks like forward secrecy is supported with some browsers too. Not sure it that was enabled before. Just checking; the old certificate was revoked, right?


----------



## mojeda (Apr 11, 2014)

Cloudflare is claiming that on nginx servers it's incredibly unlikely that someone is able to get your private SSL keys.

They also said while it's unlikely they would be able to with apache2 as well, it seems apache2 might be more vulnerable to it than nginx.

http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed

They've setup a server with ssl that is challenging anyone to grab the private key: https://www.cloudflarechallenge.com/heartbleed.


----------



## wlanboy (Apr 11, 2014)

Good comic about this:

http://xkcd.com/1354/


----------



## MCH-Phil (Apr 11, 2014)

Private keys were stolen.  Source:  https://www.cloudflarechallenge.com/heartbleed


----------



## eva2000 (Apr 12, 2014)

http://thread.gmane.org/gmane.comp.encryption.openssl.user/51243



> Date: 2014-04-11 17:22:21 GMT (1 day, 10 hours and 26 minutes ago)
> 
> 
> Akamai Technologies is pleased to offer the following patch to OpenSSL. It adds a "secure arena" that is used to store RSA private keys.  This arena is mmap'd, with guard pages before and after so pointer over- and under-runs won't wander into it. It's also locked into memory so it doesn't appear on disk, and when possible it's also kept out of core files.  This patch is a variant of what we've been using to help protect customer keys for a decade.
> ...


----------



## Sardonik (Apr 13, 2014)

As a curious hobbiest, I'm a bit confused about something...

Heartbleed has prompted much discussion about the need to change passwords and reissue/revoke SSL certs, but it seems to me that there's at least one more potential level of evil here. If secure comms have, potentially, been compromised for years, it seems likely that at least some systems have been compromised using sniffed admin credentials. Acting to preserve root access once it's been gained seems like a logical next step, assuming a stealthy root-kit style compromise is available to the attackers.

Can we really trust the OS currently installed on systems which were setup prior to application of the heartbleed bug patch and which use CPanel etc for administration? If SSL reissuance/revocation is considered prudent as a reaction to this bug, shouldn't OS re-installation also be indicated?


----------



## tchen (Apr 13, 2014)

Sardonik said:


> If SSL reissuance/revocation is considered prudent as a reaction to this bug, shouldn't OS re-installation also be indicated?


Varying degrees of yes.  Most of the bigger shops (outside of hosting) should have tripwires and other host based intrusion systems in place that would detect direct manipulation of the system - hence why most press-releases concentrate on just the SSL endpoint.  If you lack basic monitoring however, then your right - there's a low trust level associated with anything on your server - which would have been the case anyways without Heartbleed, right?


----------



## Sardonik (Apr 13, 2014)

Thanks, that makes sense. I didn't factor tripwire modification monitoring into the equation.

Sent from my SM-N900T using Tapatalk


----------



## peterw (Apr 15, 2014)

Vmware long list of patches: OTA_HotelResRS


----------



## DomainBop (Apr 17, 2014)

Just when you thought the patching was over...Debian releases yet another patch for Wheezy to fix more vulnerabilities.

April 17th patch: https://www.debian.org/security/2014/dsa-2908

new: 1.0.1e-2+deb7u7


----------



## MCH-Phil (Apr 18, 2014)

I don't see the problem.  Patches are good.  No patches is bad.  There will always be more patches.


----------



## beast5 (Apr 20, 2014)

tchen said:


> Useful test
> 
> http://filippo.io/Heartbleed


thank you


----------



## peterw (Apr 23, 2014)

Oh shit: https://www.imperialviolet.org/2014/04/19/revchecking.html



> Revocation checking is in the news again because of a large number of revocations resulting from precautionary rotations for servers affected by the OpenSSL heartbeat bug. However, revocation checking is a complex topic and there's a fair amount of misinformation around. In short, it doesn't work and you are no more secure by switching it on. But let's quickly catch up on the background.


The browsers do not check if the ssl certificates are revoked. And they cannot do it by lists and they cannot do it by a check service. So all your revoked ssl certificates are still valid for the browsers until their validity ends.


----------



## MCH-Phil (Apr 23, 2014)

More misinformation   Chrome, specifically, will inform you of certificate revocation.  I have personally seen it happen 

Now I can't verify how active that is, if say I would refresh 100 times how many times that check would be performed or maybe it's stored etc..  If the OSCP servers are down ofcourse no protection.   But something > nothing?


----------

