OpenVPN 2.4.2 -- released on 2017.05.11

[Xentrk]

The OpenVPN updates are an outcome of the results of the OpenVPN code audit for security vulnerabilities independently by Quarkslabs (funded by OSTIF) and Cryptography Engineering (funded by Private Internet Access) between December 2016 and April 2017.

Here is the link to the OpenVPN page for more information

https://openvpn.net/index.php/open-source/downloads.html

RMerlin has released a refreshed 380.66 beta5 with OpenVPN 2.4.2

https://www.snbforums.com/threads/b...ta-is-now-available.38718/page-18#post-323955

 

[RMerlin]

Note that people shouldn't be worried about the issues found by the security audit: only two security issues, and both are quite esoteric. One of them for instance requires transmitting at least 196 GB of traffic to be exploitable, and it only leads to a potential DoS...

So that's good news - very few issues were found.

 

[sfx2000]

Note that people shouldn't be worried about the issues found by the security audit: only two security issues, and both are quite esoteric. One of them for instance requires transmitting at least 196 GB of traffic to be exploitable, and it only leads to a potential DoS...

So that's good news - very few issues were found.

Actually, some of the CVE's fixed are important for inbound OVPN connections...

One is related to oversized packets that basically stop the server process... which can lead to a denial of service..

The other is a replay issue - which is kinda scary - so nice that they solved it.

 

[RMerlin]

Actually, some of the CVE's fixed are important for inbound OVPN connections...

One is related to oversized packets that basically stop the server process... which can lead to a denial of service..

The other is a replay issue - which is kinda scary - so nice that they solved it.

A DoS is far less important to me than a data leak/compromise. Especially since both issues require the user to already be authenticated to be exploited. This means only one of your own users could generate the DoS, so whoever doing it would be quite easy to track down.

 

[sfx2000]

A DoS is far less important to me than a data leak/compromise. Especially since both issues require the user to already be authenticated to be exploited. This means only one of your own users could generate the DoS, so whoever doing it would be quite easy to track down.

The replay issue is more of a concern...

 

[RMerlin]

The replay issue is more of a concern...

I don't see any replay issue mentionned there. The two new CVEs addressed by 2.4.2 can only lead to an ASSERT(), stopping the process. All the other issues relative to replay attacks have already been patched in previous releases (remember the audit was done on 2.4.0, and we're now up to 2.4.2).

 

[sfx2000]

I don't see any replay issue mentionned there.

http://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-7479.html

unpatched devices with legacy... 2.4 plugged a hole for DOS...

depends on how one plays it... sometimes folks just want to listen in... the rollover on packet id's was a weakness...

 

[RMerlin]

http://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-7479.html

unpatched devices with legacy... 2.4 plugged a hole for DOS...

depends on how one plays it... sometimes folks just want to listen in... the rollover on packet id's was a weakness...

That article you linked makes no mention of a replay either.

It was discovered that OpenVPN improperly triggered an assert when
packet ids rolled over. An authenticated remote attacker could use
this to cause a denial of service (application crash).

The rollover leads to a crash, not to any kind of replay.

 

[sfx2000]

The OpenVPN updates are an outcome of the results of the OpenVPN code audit for security vulnerabilities independently by Quarkslabs (funded by OSTIF) and Cryptography Engineering (funded by Private Internet Access) between December 2016 and April 2017.

Here's the link to the Quarklabs Audit if folks are interested...

https://ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quarkslab-results/