OpenVPN Vulnerability CVE-7521
-
Hi, wondering when an update will be available for this issue with OpenVPN:
https://threatpost.com/openvpn-patches-critical-remote-code-execution-vulnerability/126425/Any info appreciated, many thanks!
-
-
Client Export is already updated with installers for OpenVPN 2.4.3 and 2.3.17
pfSense 2.4 snapshots have OpenVPN 2.4.3 right now
pfSense 2.3.5 snapshots have OpenVPN 2.3.17 right now
pfSense 2.3.4 will have something very soon. We have a 2.3.4-p1 release pending but there are a few blockers yet (like a fix from FreeBSD for the recent Stack Clash issue). We're experimenting with a way to have OpenVPN update to 2.3.17 as a part of the client export package update but it isn't working in an ideal way yet. At worst you might have to "pkg update; pkg upgrade -y openvpn23; /etc/rc.openvpn" (don't actually run this yet, it won't do anything until/unless we put a new OpenVPN up)
-
is it possible to update only the openvpn package?
-
It is possible, yes, but without some code to make sure other things happen like restarting all OpenVPN instances, it's not ideal. The last part of my post above would do exactly what you asked, if we provide an updated package on its own. Since FreeBSD has now published a fix for the Stack Clash issue we'll probably have an update out for all of this shortly.
-
We have pushed an updated OpenVPN package out for 2.4.3 since the -p1 release is still held up waiting on Stack Clash.
Details and update instructions are here: https://www.netgate.com/blog/important-update-for-openvpn.html
-
Jim, your blog post says, "We strongly recommend all users upgrade…". To clarify, does that mean "all users who use OpenVPN" or "all pfSense users"?
Thanks.
-
Even if you don't use it now, I'd update it anyhow so it doesn't become an issue if you decide to turn it on later and haven't updated anything yet.
-
OK, thanks. Since I have no plans to use it I'll upgrade when convenient rather than immediately.
-
We have pushed an updated OpenVPN package out for 2.4.3 since the -p1 release is still held up waiting on Stack Clash.
Details and update instructions are here: https://www.netgate.com/blog/important-update-for-openvpn.html
Hey jimp, thanks for all your help over the years here! Do we have a time frame for when 2.4.3-p1 will be available? I would really like to update this the official way. Side Note: I have read the netgate blog, but prefer the standard update method. Thanks in advance
,smAsh
-
We don't have a timeline from FreeBSD on when things will be settled there. If you keep an eye on FreeBSD news/announcements, once you see them release a Security Advisory for the Stack Clash stuff then we'll be following behind them shortly. Everything else is ready for the release I believe.
-
OK, thanks. Since I have no plans to use it I'll upgrade when convenient rather than immediately.
Guess will be doing the same, so far it is good.
-
We don't have a timeline from FreeBSD on when things will be settled there. If you keep an eye on FreeBSD news/announcements, once you see them release a Security Advisory for the Stack Clash stuff then we'll be following behind them shortly. Everything else is ready for the release I believe.
Jimp Good morning sir. Please don't take this personally, but I need to put this out there since its related to the security of a major piece of PFsense. NetGate needs to understand that the Stack Clash is a local exploitation problem while the OpenVPN items are a remote exploitation problem. I believe that a remote exploitation problem takes precedence over a local exploitation problem, and I'm sure most admins would agree. To hear that Netgate is holding up the official PFsense update patch waiting for the upstream to patch a lesser local problem is very concerning. The reason I'm being vocal about this is because I love PFsense. It is decisions like these out of Netgate that has me concerned for the future security of PFsense. Don't get me wrong I know I can manually patch from the command line, but that blog post & patch method in itself is yet another indicator of concern. Just push out an official patch ASAP! I do not feel that the folks at Netgate are taking security as seriously as they should. Side Note: I am not seeing much discussion online about Security Advisories for FreeBSD 10.3 & Stack Clash. Who knows when that will be dropped.
I am sure I will ruffle some feathers of others, and I'm sorry. I'm not trying to be a troll dick. I'm just trying to voice concern over a security issue being held up when it should not be. Thanks for allowing me to be a part of the PFsense community even if I do not agree with how this security issue is being handled.
NETGATE PLEASE release an official patch, and handle the Stack Clash afterwards. Thank you
smAsh,
-
Those concerns are why we put out the announcement and update packages we did.
We don't want to put out a 2.3.4-p1 and then a few days later put out another 2.3.4-p2 going through two lengthy testing and release cycles back-to-back.
Also, under the correct conditions, Stack Clash can be remotely exploited.
-
I'm sorry I was unaware that Stack Clash was remotely exploitable. My research did not find that piece of information, only local exploitation. I' be quit now, and wait for the official update. Thanks Jimp
smAsh,
-
I'm sorry I was unaware that Stack Clash was remotely exploitable. My research did not find that piece of information, only local exploitation. I' be quit now, and wait for the official update. Thanks Jimp
smAsh,
I think he meant it in the way that any local exploit could potentially be coupled with a remote exploit.
-
I'm sorry I was unaware that Stack Clash was remotely exploitable. My research did not find that piece of information, only local exploitation. I' be quit now, and wait for the official update. Thanks Jimp
I think he meant it in the way that any local exploit could potentially be coupled with a remote exploit.
While that is true, there is also this:
https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash
Is it exploitable remotely?
Our research has mainly focused on local exploitation: as of this writing on June 19, 2017, we do not know of any remotely exploitable application. However, remote exploitation of the Stack Clash is not excluded; although local exploitation will always be easier, and remote exploitation will be very application-specific. The one remote application that we did investigate (the Exim mail server) turned out to be unexploitable by sheer luck.
They didn't test many applications, and the one they did test happened to not be exploitable, but the possibility still exists.
It's dangerous to assume it's local only given the context.
-
I was always under the impression that the stack was a fixed size, which is why you can configure the size and if your stack gets greater than that size, you get a stack overflow. When did stacks start to "grow automatically"?! Unless they're talking about the stack being thinly allocated via zero pageing it.
-
We have pushed an updated OpenVPN package out for 2.4.3 since the -p1 release is still held up waiting on Stack Clash.
Details and update instructions are here: https://www.netgate.com/blog/important-update-for-openvpn.html
Will any of these methods still work for those of us on 2.3.3 who haven't updated to 2.3.4 as yet? If possible, I'd like to get this fix installed without doing a full system upgrade yet (since there's a new version coming out so soon anyways for the StackClash vulnerability).
-
No, the update is only available to people on 2.3.4
However, if you update from 2.3.3 to 2.3.4 now, you'll pick up the new OpenVPN during the update automatically.
-
From those instructions, I chose option #2:
If a firewall currently has the OpenVPN Client Export package installed:
Update the package to version 1.4.12 or later from System > Package Manager on the Installed Packages tab, which will also update openvpn in the base system.
Manually restart each instance of OpenVPN from Status > Services or reboot the firewall.All looks good. Running "pkg info -x openvpn" from Diagnostics > Command Prompt gives me:
openvpn-client-export-2.4.3_3 openvpn23-2.3.17 pfSense-pkg-openvpn-client-export-1.4.12The one thing I'm unclear about is the third paragraph in the article:
Users of the OpenVPN Client Export package should also update that package on pfSense installations (See item #2 below), and update all client devices with the latest version of OpenVPN. The latest version of the OpenVPN Client Export Package (1.4.9 or later) contains Windows installers for OpenVPN 2.4.3 and 2.3.17. Re-running an exported installer will not update the client; OpenVPN must be removed from the client first before installing a new exported client. Alternately, manually download and install the latest client directly from OpenVPN (that's https://openvpn.net/index.php/open-source/downloads.html).
I'm assuming by "update all client devices with the latest version of OpenVPN," that means (in my case) the OpenVPN for Android app I installed on my Android phones. Since the phones automatically updated that and the "What's New" for the app says it fixed CVE-2017-7508, CVE-2017-7520, CVE-2017-7521, and CVE-2017-7522, I again assume I don't have to do anything with the phone app. But, do I have to re-export the profiles from pfSense (I originally exported the Inline Configurations for Android and pointed OpenVPN for Android on the phones at them)?
-
I'm assuming by "update all client devices with the latest version of OpenVPN," that means (in my case) the OpenVPN for Android app I installed on my Android phones. Since the phones automatically updated that and the "What's New" for the app says it fixed CVE-2017-7508, CVE-2017-7520, CVE-2017-7521, and CVE-2017-7522, I again assume I don't have to do anything with the phone app.
Correct.
But, do I have to re-export the profiles from pfSense (I originally exported the Inline Configurations for Android and pointed OpenVPN for Android on the phones at them)?
No, the settings are the same it's the client itself that needed an update. Only Windows users who wanted to install the latest version using the export package needed to export anything again.
