The OpenVPN Project (openvpn.exe) part of Avast's installation.

Will the next version of Avast include the latest version of openvpn.exe (current version 2.3.0.0) part of the Avast 2014.9.0.2018 installation to it’s latest version aka 2.3.3.0?
The openvpn.exe can be found in “C:\Program Files\AVAST Software\Avast\OpenVPN”
I see now that Secunia PSI (https://secunia.com) is flagging this outdated executable.

Thanks for your reply.

PS: bit ironic your own “software checking tool” fails to flag this openvpn.exe

While scanning my computer this afternoon. Secunia PSI prompted me to update OpenVPN. Since I did not install OpenVPN I figured the software was part of my Avast AV.

Location:

C:\Program Files\Avast Software\Avast\OpenVPN\openvpn.exe - installed version 2.3.0.0.

The latest version of OpenVPN is 2.3.3.

http://secunia.com/advisories/58062

Avast Internet Security version- 2014.9.0.2018.

Will this be patched anytime soon? ::slight_smile: #moderator #heartbleed

Avast does have “SecureLine VPN” it is a paid product.
OpenVPN is not part of avast.

See http://www.avast.com/en-us/secureline-vpn
FAQ found here http://www.avast.com/en-us/faq.php?article=AVKB44#idt_15

It is true that avast! uses OpenVPN engine to provide for the SecureLine service but we have fixed the mentioned vulnerability ourselves (by upgrading OpenSSL libraries to 1.0.1g). If you already have the latest avast! (2014.9.0.2018), you can disregard the warning.

I have the latest version of Avast!, and the vulnerability still exists on my machine according to Secunia PSI.

Contact Secunia via their user forum and let them know of the changes made by avast!. You can link the Secunia forum moderators back to your thread over there. Use the PSI forum to post over there.

It’s up to Secunia to update their database detections, and not the other way around, as avast! has already modified the openvpn.exe file independently by themselves. Usually Secunia is very good about doing that in the past, so…

I am unsatisfied about this problem either
I might disregard the warning as I see that some files (ssleay32.dll and libeay32.dll) have been updated with new Avast version 2014.9.0.2018, however I don’t think this is a proper and appropriated way to handle this kind of problems for a PC-security related company g

Perhaps on further problems you recommend to disregard warnings from Avast protection as well ? for customers who care about their PC system its a joke to make such statements :-((
Even if there is no security related problem Avast provides security software and as I see now how issues are handled by Avast I think I go to another bakery to get another security software from a company who take this seriously

Even so… the changelog might help you to include the next fix simply as it changes and fixes things all the same when people use the VPN provided by Avast! (NOTE: this log is for the normal suite so I cant tell which part(s) are used when using the Avast! version):

Overview of changes in OpenVPN v2.3
OpenVPN 2.3.3
Alon Bar-Lev (1):
pkcs11: use generic evp key instead of rsa

Arne Schwabe (8):
Add support of utun devices under Mac OS X
Add support to ignore specific options.
Add a note what setenv opt does for OpenVPN < 2.3.3
Add reporting of UI version to basic push-peer-info set.
Fix compile error in ssl_openssl introduced by polar external-management patch
Fix assertion when SIGUSR1 is received while getaddrinfo is successful
Add warning for using connection block variables after connection blocks
Introduce safety check for http proxy options

David Sommerseth (5):
man page: Update man page about the tls_digest_{n} environment variable
Remove the --disable-eurephia configure option
plugin: Extend the plug-in v3 API to identify the SSL implementation used
autoconf: Fix typo
Fix file checks when --chroot is being used

Davide Brini (1):
Document authfile for socks server

Gert Doering (9):
Fix IPv6 examples in t_client.rc-sample
Fix slow memory drain on each client renegotiation.
t_client.sh: ignore fields from “ip -6 route show” output that distort results.
Make code and documentation for --remote-random-hostname consistent.
Reduce IV_OPENVPN_GUI_VERSION= to IV_GUI_VER=
Document issue with --chroot, /dev/urandom and PolarSSL.
Rename ‘struct route’ to ‘struct route_ipv4’
Replace copied structure elements with including <net/route.h>
Workaround missing SSL_OP_NO_TICKET in earlier OpenSSL versions

Heikki Hannikainen (1):
Always load intermediate certificates from a PKCS#12 file

Heiko Hund (2):
Support non-ASCII TAP adapter names on Windows
Support non-ASCII characters in Windows tmp path

James Yonan (3):

  TLS version negotiation
  Added "setenv opt" directive prefix.
  Set SSL_OP_NO_TICKET flag in SSL context for OpenSSL builds, to disable TLS stateless session resumption.

Jens Wagner (1):
Fix spurious ignoring of pushed config options (trac#349).

Joachim Schipper (3):
Refactor tls_ctx_use_external_private_key()
–management-external-key for PolarSSL
external_pkcs1_sign: Support non-RSA_SIG_RAW hash_ids

Josh Cepek (2):
Correct error text when no Windows TAP device is present
Require a 1.2.x PolarSSL version

Klee Dienes (1):
tls_ctx_load_ca: Improve certificate error messages

Max Muster (1):
Remove duplicate cipher entries from TLS translation table.

Peter Sagerson (1):
Fix configure interaction with static OpenSSL libraries

Steffan Karger (7):
Do not pass struct tls_session* as void* in key_state_ssl_init().
Require polarssl >= 1.2.10 for polarssl-builds, which fixes CVE-2013-5915.
Use RSA_generate_key_ex() instead of deprecated, RSA_generate_key()
Also update TLSv1_method() calls in support code to SSLv23_method() calls.
Update TLSv1 error messages to SSLv23 to reflect changes from commit 4b67f98
If --tls-cipher is supplied, make --show-tls parse the list.
Add openssl-specific common cipher list names to ssl.c.

Tamas TEVESZ (1):
Add support for client-cert-not-required for PolarSSL.

Thomas Veerman (1):
Fix “.” in description of utun.

OpenVPN 2.3.2

Arne Schwabe (3):
Only print script warnings when a script is used. Remove stray mention of script-security system.
Move settings of user script into set_user_script function
Move checking of script file access into set_user_script

Davide Brini (1):
Provide more accurate warning message

Gert Doering (3):
Fix NULL-pointer crash in route_list_add_vpn_gateway().
Fix problem with UDP tunneling due to mishandled pktinfo structures.
Preparing for v2.3.2 (ChangeLog, version.m4)

James Yonan (1):
Always push basic set of peer info values to server.

Jan Just Keijser (1):
make ‘explicit-exit-notify’ pullable again

Josh Cepek (2):
Fix proto tcp6 for server & non-P2MP modes
Fix Windows script execution when called from script hooks

Steffan Karger (2):
Fixed tls-cipher translation bug in openssl-build
Fixed usage of stale define USE_SSL to ENABLE_SSL

svimik (1):
Fix segfault when enabling pf plug-ins

OpenVPN 2.3.1

Arne Schwabe (4):
Remove dead code path and putenv functionality
Remove unused function xor
Move static prototype definition from header into c file
Remove unused function no_tap_ifconfig

Christian Hesse (1):
fix build with automake 1.13(.1)

Christian Niessner (1):
Fix corner case in NTLM authentication (trac #172)

Gert Doering (6):
Update README.IPv6 to match what is in 2.3.0
Repair “tcp server queue overflow” brokenness, more <stdbool.h> fallout.
Permit pool size of /64…/112 for ifconfig-ipv6-pool
Add MIN() compatibility macro
Fix directly connected routes for “topology subnet” on Solaris.
Preparing for v2.3.1 (ChangeLog, version.m4)

Heiko Hund (5):
close more file descriptors on exec
Ignore UTF-8 byte order mark
reintroduce --no-name-remapping option
make --tls-remote compatible with pre 2.3 configs
add new option for X.509 name verification

Jan Just Keijser (1):
man page patch for missing options

Josh Cepek (2):
Fix parameter listing in non-debug builds at verb 4
(updated) [PATCH] Warn when using verb levels >=7 without debug

Matthias Andree (1):
Enable TCP_NODELAY configuration on FreeBSD.

Samuli Seppänen (4):
Removed ChangeLog.IPv6
Added cross-compilation information INSTALL-win32.txt
Updated README
Cleaned up and updated INSTALL

Steffan Karger (7):
PolarSSL-1.2 support
Improve PolarSSL key_state_read_{cipher, plain}text messages
Improve verify_callback messages
Config compatibility patch. Added translate_cipher_name.
Switch to IANA names for TLS ciphers.
Fixed autoconf script to properly detect missing pkcs11 with polarssl.
Use constant time memcmp when comparing HMACs in openvpn_decrypt.

Frankly I would suggest not to become like (sorry to mention) Videolan when they too got flagged by Secunia for libraries included within their software provided by 3rd parties. I believe it would be the job of Avast! to check this before a product is made public to use or bought or update when required.

That’s my humble opinion.

Update:
Someone already mentioned the “workaround” at Secunia → http://secunia.com/community/forum/thread/show/14894/open_vpn2_x.
If they come out with the advice to update the executable still will you then update?
Also know some companies use OSI from Secunia. I bet these companies would love an answer like “ignore” the warning when they use Avast! to protect their business.

(I can stick my head in the sand sure but that will not resolve this flagging… for now.)

Hi again,

I acknowledge there are many improvements in OpenVPN 2.3.x and we are likely to include updated version at some point (probably in the next release). However, there are other things to consider and we have to use stable version (or version proven to be stable). In releases like this one, we include only critical fixes with minimal changes necessary minimizing the chance to break something. The issue with Secunia is that it assigned security vulnerability to whole OpenVPN product (at given versions) even if the vulnerability lies only in those libraries we patches ourselves. I looked into release notes of OpenVPN but didn’t find any change that would require immediate action. Mostly because most of them don’t apply to our specific use of the OpenVPN and we would just risk problems with no real advantage.

If they come out with the advice to update the executable still will you then update?
I hope that Secunia will be able to fix its detection but if they decide otherwise, we'll have to do something about it. Ideally, they should instruct users to upgrade avast!, not OpenVPN as the most users have no idea what OpenVPN even is and why it's on their computer.

Fair enough answer for now.
You might also take a more proactive approach and included test-runs with various tools like the one from Secunia to iron out “falls-positives” before it gets released to the public. Just saying these tools a free.
Frankly I would expect Avast! to fix this detection error from their end and not Secunia. This would to me be a sign you are dedicated to show the community you take issue’s like this seriously as you make the software available.
(Like adding this to release notes if no workaround is yet known.)

Can you confirm that Secunia already fixed the detection? You may have to restart & rescan computer but warning doesn’t show for me anymore.

especially with the logfile showing the advantages of openssl 2.33 I cannot really accept this “don’t think about it, it’s all alright” statement from Avast
Its NOT all right !! I don’t think (hope) that Secunia will change the detection rules- at the end the PSI-scanner only scans files found on the computer with the latest available version (if any update is relevant for security reasons, like this one) and openssl 2.3.0 IS NOT SECURE - no more to discuss

May I ask: if you claim, that you use a different openssl-version and fixed the problem otherwise, why do you use the same filenames and version numbers ? and why do you state under Help > About Avast to use “OpenSSL, Copyright the OpenSSL Project” ?? when you claim here in the thread that you have a personal version of SLL software that has no security problems ?

I tried to update the OpenSSL service myself, a download-link is provided by PSI-software and the path could be set to the Avast-OpenSSL-folder but unfortunately its not possible, even after disabling the Avast scanner for 10 minutes and switching of the Avast services it was not possible, its not possible to change the file-ownership to me and let me delete it manually (on one hand that behavior is acceptable from a virus scanner related software)

However, I will wait for a week and see if anything changes, otherwise I will switch my computers to another software from a company that takes it more seriously - security is your business, the behavior and statements from Avast are not acceptable. Obviously your are only interested in un-experienced users that simply like a nice Systray icon and a message “Everything is all right”. As I am satisfied with Avast for some years I have not expected this :frowning:

Rechecked on baremetal host installation and as a guest within VMware Workstation 10.0.2 build-1744117:

  • Vista Ent x64: No (Guest OS )
  • Windows 7 Ent x64 : No (Guest OS)
  • Windows 7 Ulti x64: No (Host)
  • Windows 8.1 Pro (Update 1) x64: No (Guest OS)

Additionally tested on:

  • Windows XP x64 Edition: No (Guest OS and I would not use it much as this is now an End of Life OS), as I had not updated it recently flagging also on a older version of Avast! v2014.9.0.2013
  • Windows XP Pro: No (Guest OS and I would not use it much as this is now an End of Life OS)

“No” means it is still flagged.
Btw the “openvpn.exe” last was modified on 12/24/2013. Makes it a little old too…

Since no real workaround has been suggested by Avast! brightest I will post the workaround I now deploy on my various PC’s in regards to the “openvpn.exe” flagging by in this case PSI from Secunia.

It basically involved purging my Avast! installation of the SecureLine add-on. Get that bit of “bloatware” of the PC and the flagging will stop.
Mind you I state “bloatware” maybe a bit harshly as Avast! has included alot of additional software many may not fully use to it maximum but remain to this day part of the default installation.

I know I would not use SecureLine simple as there are other VPN-services out there that seem to take better care of their service then what I now see from Avast! “added” value.

Basically I am saying “SecureLine” is OpenVPN but then recompiled by Avast! but behind on updates,options and/or added features.
If I were to use OpenVPN software I would get it directly from OpenVPN.net itself and get the latest (fixed) version of this software.

Something similar occurred with Secunia when Python released their v3.3.3 to address security flaws. LibreOffice (and possibly OpenOffice) contain Python, but the functions called from within LibreOffice wouldn’t trigger the vulnerability. Secunia was alerting on Python being out of date. Secunia corrected the alert. LibreOffice later released an updated version that included Python 3.3.3.

Maurice Joyce locked the thread for some reason.

That’s a very poor showing of cooperation on their part.

That can be explained in many ways. I myself still see the issue to be resolved by Avast!.
The openvpn.exe seems to have been compiled by Avast!. It’s up to them to correct issue’s. Asking others (Secunia) to ignore it is just bad taste.

Guys, I do not consider it a workaround. We fixed the security vulnerability in OpenSSL libraries (I personally did so) and now we have to talk it through with Secunia folks because this is clear false positive if I use AV term. Updating the OpenVPN executable to the latest version is completely another matter and we will do so when there is any advantage in doing so.

Now it seems to me that I am just adding fuel to the flames by any statement I make. I am sorry if I sound harsh but I kinda know what I am doing and to be honest, yes I am fairly confident there is no known security vulnerability in OpenVPN.exe 2.3.0 (do not confuse with OpenVPN software or OpenSSL libraries). OpenVPN.exe is just poorly chosen anchor to OpenVPN product and from my point of view it’s a bug in Secunia PSI detection.

When I removed the unwanted SecureLine software I stopped getting flags
Works for me… Besides if indeed SecureLine is not to be removed then pray tell why I can uncheck it in your Avast! Custom Installation?

Of course you can remove the SecureLine feature if you don’t [intend to] use it - it’s the same as with many other optional avast! features. Then the related files are removed from avast! installation folder.
On the other hand, if you don’t use SecureLine, then the openvpn.exe file is not used anyway (so even if it were vulnerable, the problem could never manifest, i.e. you’d be safe).