Patching/Upgrading OpenSSL
-
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.
-
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 -
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,
PeterThere 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.
-
Returning to the original thread, has the 2.1.2 build gone off the rails?
-
-
-
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
-
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.
-
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
-
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.
-
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…
-
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.
-
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.
-
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 -
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.
-
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.
-
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.
-
Not a topic for this thread, but see the mess that was 2.0.x and before packages for reasons why PBIs are better. The problem is primarily packages stomping all over each other with different versions of things like perl, openldap, etc. Uninstalling one package could render another one (or the base system) broken. There haven't been any such problems with PBIs, the only drawback is the extra space and sometimes duplicated files. If you want to open a new debate on that, start a fresh thread.
-
Well, frankly said, stuff that cannot be compiled against and run with what's shipped with the base system, well… either needs to be fixed or - failing that - simply should not be packaged and distributed. That's pretty much it. (Simplified, but that basically is the deal. People do not want to end up with 3 versions of openldap, 5 versions of perl and 7 versions of openssl just because some package has bugs and noone wants to fix it. Cannot see how's this beneficial to maintainers either - look at what happened now...
(And yeah, debating PBI would be worth its own topic.)
-
It's not that simple or easy, but may get better in the future after 2.2. Back seat driving is easy, actual solutions not so much. Still off topic for this thread.
