v2.5 client on Win7 - Out of Memory caused by --register-dns

[tct]

using W7 32bit Openvpn 2.5.0 client and OpenVPN 2.5.0 x86_64-pc-linux-gnu server.

Starting Openvpn from an administrator command prompt (Not the GUI). Interactive service running or not.

If the client uses (or the server pushes) register-dns then OOM.

On my VM this is 100% reproducible OOM with any client config (I tested three).

Client log snip:

2020-10-29 16:41:36 us=615613 OpenVPN 2.5.0 i686-w64-mingw32 [SSL (OpenSSL)] [LZ
O] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
2020-10-29 16:41:36 us=631238 Windows version 6.1 (Windows 7) 32bit
2020-10-29 16:41:36 us=631238 library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO
 2.10


<Snip>


2020-10-29 16:41:37 us=178113 PUSH: Received control message: 'PUSH_REPLY,topolo
gy net30,route 10.63.110.0   255.255.255.0,explicit-exit-notify 3,comp-lzo no,co
mpress lz4,ping 10,ping-restart 60,tun-ipv6,redirect-private def1 block-local,se
tenv-safe client_dynamic xxxxxxxxxx.cli.w7e,setenv-safe opt foo,explicit-exit-no
tify 3,comp-lzo no,ping 10,ping-restart 60,topology net30,ifconfig 10.63.110.106
 10.63.110.105,peer-id 0,cipher AES-256-GCM'
2020-10-29 16:41:37 us=193738 WARNING: Compression for receiving enabled. Compre
ssion has been used in the past to break encryption. Sent packets are not compre
ssed unless "allow-compression yes" is also set.
2020-10-29 16:41:37 us=193738 OPTIONS IMPORT: timers and/or timeouts modified
2020-10-29 16:41:37 us=193738 OPTIONS IMPORT: explicit notify parm(s) modified
2020-10-29 16:41:37 us=209363 OPTIONS IMPORT: compression parms modified
2020-10-29 16:41:37 us=209363 OPTIONS IMPORT: --ifconfig/up options modified
2020-10-29 16:41:37 us=209363 OPTIONS IMPORT: route options modified
2020-10-29 16:41:37 us=209363 OPTIONS IMPORT: environment modified
2020-10-29 16:41:37 us=209363 OPTIONS IMPORT: peer-id set
2020-10-29 16:41:37 us=209363 OPTIONS IMPORT: adjusting link_mtu to 1625
2020-10-29 16:41:37 us=224988 OPTIONS IMPORT: data channel crypto options modifi
ed
2020-10-29 16:41:37 us=224988 Data Channel: using negotiated cipher 'AES-256-GCM
'
2020-10-29 16:41:37 us=224988 Data Channel MTU parms [ L:1553 D:1450 EF:53 EB:40
6 ET:0 EL:3 ]
2020-10-29 16:41:37 us=224988 Outgoing Data Channel: Cipher 'AES-256-GCM' initia
lized with 256 bit key
2020-10-29 16:41:37 us=224988 Incoming Data Channel: Cipher 'AES-256-GCM' initia
lized with 256 bit key
2020-10-29 16:41:37 us=240613 interactive service msg_channel=0
2020-10-29 16:41:37 us=240613 ROUTE_GATEWAY 10.10.201.1/255.255.255.0 I=10 HWADD
R=08:00:27:10:b8:d0
2020-10-29 16:41:37 us=256238 ROUTE: bypass_host_route[0]=10.10.201.1
2020-10-29 16:41:37 us=271863 open_tun
2020-10-29 16:41:37 us=318738 tap-windows6 device [OpenVPN TAP-Windows6] opened
2020-10-29 16:41:37 us=318738 TAP-Windows Driver Version 9.24
2020-10-29 16:41:37 us=318738 TAP-Windows MTU=1500
2020-10-29 16:41:37 us=318738 Notified TAP-Windows driver to set a DHCP IP/netma
sk of 10.63.110.106/255.255.255.252 on interface {47A3A9E2-8A2B-438E-B67C-F5976E
27249B} [DHCP-serv: 10.63.110.105, lease-time: 31536000]
2020-10-29 16:41:37 us=334363 Successful ARP Flush on interface [17] {47A3A9E2-8
A2B-438E-B67C-F5976E27249B}
2020-10-29 16:41:37 us=349988 do_ifconfig, ipv4=1, ipv6=0
2020-10-29 16:41:37 us=349988 IPv4 MTU set to 1500 on interface 17 using SetIpIn
terfaceEntry()
2020-10-29 16:41:42 us=490613 TEST ROUTES: 4/4 succeeded len=3 ret=1 a=0 u/d=up
2020-10-29 16:41:42 us=490613 C:\Windows\system32\route.exe ADD 92.1.246.125 MAS
K 255.255.255.255 10.10.201.1
2020-10-29 16:41:42 us=506238 ROUTE: CreateIpForwardEntry succeeded with dwForwa
rdMetric1=10 and dwForwardType=4
2020-10-29 16:41:42 us=506238 Route addition via IPAPI succeeded [adaptive]
2020-10-29 16:41:42 us=506238 C:\Windows\system32\route.exe ADD 10.10.201.1 MASK
 255.255.255.255 10.10.201.1 IF 10
2020-10-29 16:41:42 us=506238 ROUTE: CreateIpForwardEntry succeeded with dwForwa
rdMetric1=10 and dwForwardType=4
2020-10-29 16:41:42 us=521863 Route addition via IPAPI succeeded [adaptive]
2020-10-29 16:41:42 us=521863 C:\Windows\system32\route.exe ADD 10.63.110.0 MASK
 255.255.255.0 10.63.110.105
2020-10-29 16:41:42 us=521863 ROUTE: CreateIpForwardEntry succeeded with dwForwa
rdMetric1=10 and dwForwardType=4
2020-10-29 16:41:42 us=521863 Route addition via IPAPI succeeded [adaptive]
2020-10-29 16:41:42 us=521863 C:\Windows\system32\route.exe ADD 10.10.201.128 MA
SK 255.255.255.128 10.63.110.105
2020-10-29 16:41:42 us=537488 ROUTE: CreateIpForwardEntry succeeded with dwForwa
rdMetric1=10 and dwForwardType=4
2020-10-29 16:41:42 us=537488 Route addition via IPAPI succeeded [adaptive]
2020-10-29 16:41:42 us=537488 C:\Windows\system32\route.exe ADD 10.10.201.0 MASK
 255.255.255.128 10.63.110.105
2020-10-29 16:41:42 us=553113 ROUTE: CreateIpForwardEntry succeeded with dwForwa
rdMetric1=10 and dwForwardType=4
2020-10-29 16:41:42 us=553113 Route addition via IPAPI succeeded [adaptive]
2020-10-29 16:41:42 us=553113 WARNING: this configuration may cache passwords in
 memory -- use the auth-nocache option to prevent this
2020-10-29 16:41:42 us=553113 Initialization Sequence Completed
2020-10-29 16:41:42 Start ipconfig commands for register-dns...
2020-10-29 16:41:42 C:\Windows\system32\ipconfig.exe /flushdns
2020-10-29 16:41:42 C:\Windows\system32\ipconfig.exe /registerdns
OpenVPN: Out of Memory
2020-10-29 16:41:50 us=193738 SIGTERM received, sending exit notification to pee
r
2020-10-29 16:41:53 us=537488 TCP/UDP: Closing socket
2020-10-29 16:41:53 us=537488 C:\Windows\system32\route.exe DELETE 10.63.110.0 M
ASK 255.255.255.0 10.63.110.105
2020-10-29 16:41:53 us=537488 Route deletion via IPAPI succeeded [adaptive]
2020-10-29 16:41:53 us=537488 C:\Windows\system32\route.exe DELETE 10.10.201.128
 MASK 255.255.255.128 10.63.110.105
2020-10-29 16:41:53 us=553113 Route deletion via IPAPI succeeded [adaptive]
2020-10-29 16:41:53 us=553113 C:\Windows\system32\route.exe DELETE 10.10.201.0 M
ASK 255.255.255.128 10.63.110.105
2020-10-29 16:41:53 us=553113 Route deletion via IPAPI succeeded [adaptive]
2020-10-29 16:41:53 us=568738 C:\Windows\system32\route.exe DELETE 92.1.246.125
MASK 255.255.255.255 10.10.201.1
2020-10-29 16:41:53 us=568738 Route deletion via IPAPI succeeded [adaptive]
2020-10-29 16:41:53 us=568738 C:\Windows\system32\route.exe DELETE 10.10.201.1 M
ASK 255.255.255.255 10.10.201.1
2020-10-29 16:41:53 us=584363 Route deletion via IPAPI succeeded [adaptive]
2020-10-29 16:41:53 us=584363 Closing TUN/TAP interface
2020-10-29 16:41:53 us=599988 TAP: DHCP address released
2020-10-29 16:41:53 us=599988 SIGTERM[soft,exit-with-notification] received, pro
cess exiting

C:\PROGRA~1\OpenVPN\config>

Client config:

register-dns

  ping-timer-rem
             dev tun
           proto udp
          nobind
    resolv-retry infinite
          client

     tls-timeout 10
 tls-version-min 1.2

          cipher AES-256-CBC
            auth SHA1

        comp-lzo no

  remote-cert-tls server
 verify-x509-name [redacted] name

       reneg-sec 300

            verb 4

remote host port

<ca>
-----BEGIN CERTIFICATE-----
..
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
..
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
..
-----END PRIVATE KEY-----
</key>

<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
..
-----END OpenVPN Static key V1-----
</tls-crypt>

[tct]

I have tested this on a real W7 PC 64bit and the same problem occurs.

I noticed also that when using the interactive service + GUI, the GUI sends a "request" for --register-dns to the service but there is no response to this request. Is the service receiving the request ?

[Gert Döring]

Huh, whatever netsh does should never result in *OpenVPN* running OOM. So something is broken here.

There are a few --register-dns related patches in 2.5, but I do not see how those could result in OOM ("no loops").

@stipa, @selva, any ideas?

[Selva Nair]

Replying to tincantech :

> 2020-10-29 16:41:42 us=553113 Initialization Sequence Completed
> 2020-10-29 16:41:42 Start ipconfig commands for register-dns...
> 2020-10-29 16:41:42 C:\Windows\system32\ipconfig.exe /flushdns
> 2020-10-29 16:41:42 C:\Windows\system32\ipconfig.exe /registerdns
> OpenVPN: Out of Memory

The only place I have seen that message (OpenVPN: Out of Memory) can come from is check_malloc_return() which could get called in openvpn_execve() while allocating buffer for env, conversion of utf8 to wide-string etc. as needed for CreateProcess() .

I can't think of any reason for this to happen just because the command line contains /registerdns.

[Gert Döring]

This is an interesting and annoying bug. A patch has posted to the list:

​ https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21365.html

and I have tested it - I couldn't reproduce the OOM (the background thread "just ended", but never crashed), but the patch looks right, and *with* the patch, register-dns from a "run from admin cmd.exe" openvpn call also works.

commit ab4688e3bd78d010ccc96adec66ab552bd009328 (master)
commit 2f2df474158b6c24325a47334fc8b5eb77a69b85 (release/2.5)
Author: Domagoj Pensa
Date: Tue Dec 15 18:16:00 2020 +0100

Fix too early argv freeing when registering DNS

@mattock: do you build "master snapshot" installers these days? If not, it would be good to have something to test for tincantech...

[Gert Döring]

There's NSIS installers in the usual place, ​ https://build.openvpn.net/downloads/snapshots/

• so, can you test that this works for you, please?

[Samuli Seppänen]

In particular this one installer:

• ​ https://build.openvpn.net/downloads/snapshots/openvpn-install-2.5.0-I900-release-2.5-20201215193647-2f2df474.exe

[tct]

I tested the one for Samuli and it worked ok.

2020-12-19 19:07:23 us=727862 Initialization Sequence Completed
2020-12-19 19:07:23 Start ipconfig commands for register-dns...
2020-12-19 19:07:23 C:\Windows\system32\ipconfig.exe /flushdns
2020-12-19 19:07:23 C:\Windows\system32\ipconfig.exe /registerdns
2020-12-19 19:07:26 End ipconfig commands for register-dns...

Tested on W7-32b VM only.

[Gert Döring]

Thanks for testing. I'll proceed to close the ticket as there is nothing left to do here.

Patch is in the tree already, 2.5.1 will be released "some time in January".