Patching/Upgrading OpenSSL

jimp · Apr 9, 2014, 10:33 PM

Is the server side (listener side) of site-to-site OpenVPN configured with a pre-shared key vulnerable to the heartbleed exploit? I don't know if the PSK is functionally similar to a TLS authentication key.

The good news is that most (not all) of our server listener ports have a WAN rule restricting connections to those ports to static IPv4 addresses. The bad news is the 'not all' part.

Questions:
1. Are IP-agnostic site-to-site OpenVPN listeners (configured with PSK) vulnerable to heartbleed?
2. If the answer to #1 is "yes, vulnerable", and if the aforementioned unrestricted listeners are configured to be limited to ONE connection, and if the connection has been nailed up the entire time, would that prevent a drive-by from exploiting the vulnerability?
3. If the answer to #1 is "yes, vulnerable" and the answer to #2 is 'No, vulnerable', is the post-update remedy to simply re-key the vulnerable server and client? In other words would the SINGLE vulnerable server listener expose ALL of the PSK's bound to ALL of the server instances, or just the one? (simplifying re-keying)

Thanks in advance for the rapid response to the vulnerability!

PSK is not vulnerable. This was specific to SSL/TLS.

hans-d · Apr 9, 2014, 10:43 PM

Also some snort rules http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/, slightly different from the the snort team.

dgcom · Apr 9, 2014, 10:46 PM

Did some more testing, but could not make rules from here to work in custom rules.
However, updated emerging-current_events.rules works pretty well.

Anyone, who has snort installed should get free ETOpen rules updated and check emerging-current_events.rules on WAN interface.

fatsailor · Apr 9, 2014, 11:38 PM

@jimp:

freebsd-update won't work on pfSense, and would break things if it did. At least for now. Might change in the future.

OpenVPN and lighttpd don't need rebuilt, they are not statically linked to OpenSSL.

Just wait for a firmware update, it'll be coming soon.

That's my plan- wait. It appears that at least the FBSD p1 patch to 10.0 stuffed things up a bit. They updated the shared libs, but not the headers. Now anyone compiling ports has issues…...

Since freebsd-update can potentially break things, I for one would argue you need to take it out of the distro. You don't want a cowboy (like myself) going crazy updating and breaking things.

I'd love to see it in the distro, but I realize that such a mechanism creates a major can of worms in trying to maintain configuration management.

pvoigt · Apr 9, 2014, 11:59 PM

@fatsailor:

That's my plan- wait. It appears that at least the FBSD p1 patch to 10.0 stuffed things up a bit. They updated the shared libs, but not the headers. Now anyone compiling ports has issues…...

Hm, I have yesterday installed p1 on FreeBSD 10.0-RELEASE. And today I have upgraded e.g. port www/apache22. I did not have any problems when building and installing. And Apache is still working. Do you have any reference for your "Now anyone compiling ports has issues…..". Or have I just been favoured by fortune :)

Regards,
Peter

fatsailor · Apr 10, 2014, 1:24 AM

@pvoigt:

Hm, I have yesterday installed p1 on FreeBSD 10.0-RELEASE. And today I have upgraded e.g. port www/apache22. I did not have any problems when building and installing. And Apache is still working. Do you have any reference for your "Now anyone compiling ports has issues…..". Or have I just been favoured by fortune :)

Regards,
Peter

There was a post on the FreeBSD forums about a mismatch between the libraries and the headers when configuring 'curl':

checking for OpenSSL headers version… 0.9.8 - 0x0090819fL
checking for OpenSSL library version... 1.0.1
checking for OpenSSL headers and library versions matching... no
configure: WARNING: OpenSSL headers and library versions do not match.

I didn't see any headers in p1 (but then I just did a simple grep). It's likely that apache's configure doesn't check for consistency between the headers and the libraries.

zandr · Apr 10, 2014, 2:09 AM

Returning to the original thread, has the 2.1.2 build gone off the rails?

Darkk · Apr 10, 2014, 2:45 AM

@zandr:

Returning to the original thread, has the 2.1.2 build gone off the rails?

Say it aint so!

BBcan177 · Apr 10, 2014, 4:50 AM

http://packetstormsecurity.com/news/view/23941/Everything-You-Need-To-Know-About-The-Heartbleed-SSL-Bug.html

pvoigt · Apr 10, 2014, 8:38 AM

@fatsailor:

There was a post on the FreeBSD forums about a mismatch between the libraries and the headers when configuring 'curl':

checking for OpenSSL headers version… 0.9.8 - 0x0090819fL
checking for OpenSSL library version... 1.0.1
checking for OpenSSL headers and library versions matching... no
configure: WARNING: OpenSSL headers and library versions do not match.

I didn't see any headers in p1 (but then I just did a simple grep). It's likely that apache's configure doesn't check for consistency between the headers and the libraries.

Thanks so far. But could you please provide the URL of this issue. I would like to follow that topic. I have just searched the FreeBSD forum but did not find it.

Peter

fatsailor · Apr 10, 2014, 1:12 PM

@dgcom:

@jimp:

VPN or SSH is best. Letting anyone even touch your GUI port remotely from an arbitrary IP is a bad thing. As this proves, it's not about a password, it's about exploiting the service itself. Custom ports won't hide you for long.

Are you saying VPN or SSH never had any security issues? Don't think so. VPN is also not convenient - does not work from many locations. SSH is better, but theoretically can be exploited as well - with the bug you do not know about (yet).

What is really missing for Web UI is the IP lockout if someone tries to brute force password.

It's really about the size of the attack surface you present to an adversary. The surface of SSH is small and WELL understood. The surface of a web GUI is large and not well understood.

Using an approach like FAIL2BAN to block IP's is useful, but it is far from sufficient protection.

fatsailor · Apr 10, 2014, 1:16 PM

@pvoigt:

@fatsailor:

There was a post on the FreeBSD forums about a mismatch between the libraries and the headers when configuring 'curl':

checking for OpenSSL headers version… 0.9.8 - 0x0090819fL
checking for OpenSSL library version... 1.0.1
checking for OpenSSL headers and library versions matching... no
configure: WARNING: OpenSSL headers and library versions do not match.

I didn't see any headers in p1 (but then I just did a simple grep). It's likely that apache's configure doesn't check for consistency between the headers and the libraries.

Thanks so far. But could you please provide the URL of this issue. I would like to follow that topic. I have just searched the FreeBSD forum but did not find it.

Peter

Yes - Finding things at FBSD forums isn't easy.

Here you go - http://forums.freebsd.org/viewtopic.php?f=5&t=45870&start=25

There's been been no further discussion on the topic

jimp · Apr 10, 2014, 3:57 PM

FYI- 2.1.2 images are being tested now, so far no problems have been found, and every Heartbleed test we've tried has passed on them.

dgcom · Apr 10, 2014, 4:03 PM

Good news.

What about rebuilt packages? Anyone testing them? I installed updates on 2.1.1 and have syslog-ng and vhosts broken, did not look in detail what is wrong yet…

jimp · Apr 10, 2014, 4:10 PM

Packages should be OK now, make sure to uninstall and then reinstall (not update) to ensure that it obtains the latest binaries.

If you do a firmware upgrade to 2.1.2 when it comes, they will be reinstalled properly there during the upgrade process.

If you have problems with specific packages post upgrade, start a new thread for each once individually.

dgcom · Apr 10, 2014, 4:15 PM

I will first wait for 2.1.2, then troubleshoot packages. Both mentioned are not essential for now.
Snort and HAProxy-devel are good after update.

Thanks again.

pvoigt · Apr 10, 2014, 4:39 PM

@fatsailor:

Yes - Finding things at FBSD forums isn't easy.

Here you go - http://forums.freebsd.org/viewtopic.php?f=5&t=45870&start=25

There's been been no further discussion on the topic

Thank you vey much. Yeah, finding things in the forums isn't easy. But the really unbelievable thing is that I have even been already subsribed to just this thread but did not see the curl/header sub-topic :).

Even at the risk of driving off-topic: To me as a non-expert the described header mismatch seems not that problemmatic because:

curl just complains about the header mismatch, but I did not read any hint that it refuses to build or becomes unstable.
it is detected in the environment of the question, whether a port is build against the base or the port version of openssl.

Or do you expect a subsequent patch with updated headers? Nevertheless, I am going to follow that thread.

Regards,
Peter

doktornotor · Apr 10, 2014, 4:49 PM

@jimp:

Packages should be OK now, make sure to uninstall and then reinstall (not update) to ensure that it obtains the latest binaries.

I already commented on this on the issue tracker: Simply stop messing with packages without version bumps. This really is insane practice with absolutely no benefit whatsoever. Highly annoying at best, and worse yet very dangerous in cases like this. You just cannot have different packages with the same version installing different files depending on whether it's a first install, reinstall or upgrade, and you cannot have different packages with the same version installing different files depending on whether I install now or 10 minutes later. Ditto if the fixes affect configuration of the packages.

Stupid practice, drop it.

jimp · Apr 10, 2014, 4:51 PM

I replied on the ticket but it's better here:

We're looking into a way to do that but the version numbers are controlled by the FreeBSD port versions and not directly by us. Unless the FreeBSD port gets bumped, then we'd have to maintain our own copies of the port with our own custom version numbers and so on (a nightmare to keep synchronized). That is, unless there's another mechanism in the PBI build process that lets us set an additional number to signify a change.

The version number of the pfSense packages did change.

The problem is that the version of (for example) haproxy didn't change.

doktornotor · Apr 10, 2014, 5:02 PM

I must be missing something about PBI. The entire idea of "lets bundle separate libraries for each package so that they are self-contained" simply goes beyond me. This is not what you should do for exactly the reasons like this - instead of a simple single system library update you now go and need to recompile tons of packages. Where's the benefit in pretending that runtime dependencies don't exist? Exactly the same reason why bundling (either untouched or modified versions) of libraries in the source code - instead of compiling against the system ones - sucks from security POV. Coming from the Linux world - this is just on par with Windows. I seriously don't get it.