Patching/Upgrading OpenSSL
-
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.
-
Forgive my ignorance, but why could a user not simply grab the new OpenSSL version, from FreeBSD and compile?
I ran some tests doing just that (build openssl package, then pkg_add the package) and the results were OK but I did not perform extensive testing. It did at least stop the GUI from exposing data via Heartbleed. It may have been OK in general even. I'd say it's sufficient as a stopgap but it's not better than a full firmware update where other programs have also been updated.
Don't forget there is also the ECDSA flaw in OpenSSL that was patched in the base system OpenSSL too.
-
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.
-
What is really missing for Web UI is the IP lockout if someone tries to brute force password.
That actually is NOT missing at all… you are welcome to try and lock yourself out. :P
-
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).
Not had any? No, but generally a better track record. If you protect access to the GUI properly behind a VPN, then even if the encryption of the VPN has failed (see PPTP) it is still useful for access control as an additional layer of protection/authentication.
OpenVPN works from anywhere that you can make an HTTPS connection from if you run it the right way(s). And the fact that it isn't convenient is a plus, not a minus.
What is really missing for Web UI is the IP lockout if someone tries to brute force password.
That's already present. But you don't want the world to be able to hit your GUI port directly anyhow, so it's more useful against local attackers/infected local hosts, but it is there.
