Patching/Upgrading OpenSSL
-
Any plans to get such patches easier in the future? As much as I like to hope, but I do not think this is the last one :(
It depends on the issue. This one's difficult because it requires recompiling a slew of PBIs, which is very time consuming, and building an entire release. If it were as simple as "here's a file, copy this and you're fixed", we would have provided that file 24 hours ago. It's also not something that's exploitable in the common uses of the system and where people are using reasonable security practices. Spend a lot more time looking at your web servers, mail servers, etc. right now, and follow my recommendations in the post above.
-
@cmb:
Any plans to get such patches easier in the future? As much as I like to hope, but I do not think this is the last one :(
It depends on the issue. This one's difficult because it requires recompiling a slew of PBIs, which is very time consuming, and building an entire release. If it were as simple as "here's a file, copy this and you're fixed", we would have provided that file 24 hours ago. It's also not something that's exploitable in the common uses of the system and where people are using reasonable security practices. Spend a lot more time looking at your web servers, mail servers, etc. right now, and follow my recommendations in the post above.
I perfectly understand implications of this particular issue, and yes - it is not just a matter of replacing openssl executable… What I am saying is that recompiling everything is not very efficient. But, I guess, you know your product :)
As for "not something that's exploitable in the common uses" - my major concern is web UI, which I would think is exposed often for remote management and packages like stunnel, HAProxy, Squid... Whatever deals with SSL frontend in any way - shouldn't build system be smart enough to recompile only if dependencies changed?
I, personally, do not run anything, based on recent versions of openssl - except pfSense.
-
@cmb:
It appears we'll beat every other similar-scoped open source distribution, and probably nearly all similar commercial appliances, in issuing fixes. There are already several updated PBIs uploaded with the patched openssl.
And you are right with that. We just openend a case with Juniper about the SSL Issue and besides transferring ownerships of the ticket and "assuring us, it is already worked on and they are hard at work" nothing happened. So yes, it perhaps would have been nice to post a short statement here (or the forums generally) but the bug tracker showed, they were working on it. That's more than I can say about Juniper and others. ;)
Thanks and kudos to the team.
-
moderator edit: don't do this, see the 2.1.2 link below.
-
You know, this requires a full new release… It's not a matter of compiling/packaging one package and typing one command in a package manager, unlike those other reputable projects.
Yes, I know. But I haven't heard that it is being worked on yet… And pfsense.org site is still vulnerable, so someone can exploit and put a rogue download mirror... :(
There is also a package to apply custom system patches - may be that can be used in interim to update openssl?
And not having mechanism for quickly applying such security fixes is not really good approach to a security application, you know...
Forgive my ignorance, but why could a user not simply grab the new OpenSSL version, from FreeBSD and compile?
-
Forgive my ignorance, but why could a user not simply grab the new OpenSSL version, from FreeBSD and compile?
I'd suggest reading the entire thread since it's already answered.
-
edit: scratch that. Another security fix was made earlier that the first build of 2.1.2 just missed. It's rebuilding.
-
@cmb:
Any plans to get such patches easier in the future? As much as I like to hope, but I do not think this is the last one :(
It depends on the issue. This one's difficult because it requires recompiling a slew of PBIs, which is very time consuming, and building an entire release. If it were as simple as "here's a file, copy this and you're fixed", we would have provided that file 24 hours ago. It's also not something that's exploitable in the common uses of the system and where people are using reasonable security practices. Spend a lot more time looking at your web servers, mail servers, etc. right now, and follow my recommendations in the post above.
Forgive my ignorance, but why could a user not simply grab the new OpenSSL version, from FreeBSD and compile?
-
@cmb:
Any plans to get such patches easier in the future? As much as I like to hope, but I do not think this is the last one :(
It depends on the issue. This one's difficult because it requires recompiling a slew of PBIs, which is very time consuming, and building an entire release. If it were as simple as "here's a file, copy this and you're fixed", we would have provided that file 24 hours ago. It's also not something that's exploitable in the common uses of the system and where people are using reasonable security practices. Spend a lot more time looking at your web servers, mail servers, etc. right now, and follow my recommendations in the post above.
Forgive my ignorance, but why could a user not simply grab the new OpenSSL version, from FreeBSD and compile?
Yes he could and did… but he apparently did something really bad according to this thread (still, his firewalls seem to be working fine with this approach, perhaps
because he doesn't use pbi packages on them). -
Packages on pfSense are in pbi-packages since 2.1 which means that each package that uses OpenSSL or other dependencies will have their own copy of the binaries. So if you have stunnel, squid or other packages that also use OpenSSL, the package pbi-package will have to be recompiled.
-
@developers: Thanks for working that fast on this problem.
-
Are there going to be updated 2.2 snapshots released to address this issue?
-
Of course. Obviously it's a lower priority for the dev team.
It's less of an issue because no-body is using 2.2 for anything other than internal experimentation are they? ;)Steve
-
It's less of an issue because no-body is using 2.2 for anything other than internal experimentation are they? ;)
And I thought it's exactly that what gets you the "Hero"-Membership…
-
It's less of an issue because no-body is using 2.2 for anything other than internal experimentation are they? ;)
I use it in production because I like to take life to the extreme.
I'm actually just a simple home user, but this bug is still somewhat concerning to me. I've disabled WAN WebConfigurator access for the time being, just to be safe.
-
Hardcore! :P
Steve
-
@ingenieurmt:
I'm actually just a simple home user, but this bug is still somewhat concerning to me. I've disabled WAN WebConfigurator access for the time being, just to be safe.
Why would you have that enabled in the first place?
-
You should never ever ever ever ever expose the configuration to internet. Use VPN or SSH to access a machine inside your network and access the configuration from within your network.
-
You should never ever ever ever ever expose the configuration to internet. Use VPN or SSH to access a machine inside your network and access the configuration from within your network.
Properly protected web UI (good password, custom port + SSL) is no worse than VPN or SSH.
-
You should never ever ever ever ever expose the configuration to internet. Use VPN or SSH to access a machine inside your network and access the configuration from within your network.
Properly protected web UI (good password, custom port + SSL) is no worse than VPN or SSH.
Except in this case where your SSL could have been spewing confidential data all over… :-)
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.
