An information disclosure vulnerability exists in the ClientConnect() functionality of SoftEther VPN 5.01.9674. A specially crafted network packet can lead to a disclosure of sensitive information. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.

CVE-2023-31192: 2023/06/30: SE202301: Security Advisory: CVE-2023-27395 etc: Fixed 6 vulnerabilities of SoftEther VPN in cooperation with Cisco Systems, Inc.

An authentication bypass vulnerability exists in the CiRpcServerThread() functionality of SoftEther VPN 5.01.9674 and 4.41-9782-beta. An attacker can perform a local man-in-the-middle attack to trigger this vulnerability.

**SUMMARY**

An authentication bypass vulnerability exists in the CiRpcServerThread() functionality of SoftEther VPN 5.01.9674 and 4.41-9782-beta. An attacker can perform a local man-in-the-middle attack to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

SoftEther VPN 4.41-9782-beta  
SoftEther VPN 5.01.9674

**PRODUCT URLS**

SoftEther VPN - https://www.softether.org/

**CVSSv3 SCORE**

7.8 - CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-300 - Channel Accessible by Non-Endpoint (‘Man-in-the-Middle’)

**DETAILS**

SoftEther is a multi-platform VPN project that provides both server and client code to connect over a variety of VPN protocols, including Wireguard, PPTP, SSTP, L2TP, etc. SoftEther has a variety of features for both enterprise and personal use, and enables Nat Traversal out-of-the-box for remote-access setups behind firewalls.

Within the SoftEtherVPN client there exists some interesting architectural decisions, first and foremost being the fact that the SoftEtherVPN client itself consists of an RPC client and an RPC server. While the process differs on Linux and Windows, there are some core common elements. The VPN client’s RPC server binds to a given TCP port within the range of 9931-9936, on all interfaces, and then the VPN client’s RPC client connects to that port to send the VPN client commands. For ease of reference, we will be referring to these components as the RPC client and RPC server, but just know that these are both contained within the client-side portion of SoftEtherVPN.

For this particular vulnerability, let us examine exactly how the server does network configuration on Linux:

    // RPC server thread
    void CiRpcServerThread(THREAD *thread, void *param)
    {
        CLIENT *c;
        SOCK *listener;
        UINT i;
        LIST *thread_list;
        // Validate arguments
        if (thread == NULL || param == NULL)
        {
            return;
        }
    
        c = (CLIENT *)param;
    
        // RPC connection list
        c->RpcConnectionList = NewList(NULL);
    
        // Open the port
        listener = NULL;
        for (i = CLIENT_CONFIG_PORT;i < (CLIENT_CONFIG_PORT + 5);i++) // 9931; 9936  // [1]
        {
            listener = Listen(i); // [2]
            if (listener != NULL)
            {
                break;
            }
        }
    
        if (listener == NULL)
        {
            // Error
            Alert(CEDAR_PRODUCT_STR " VPN Client RPC Port Open Failed.", CEDAR_CLIENT_STR);
            return;
        }
    

At \[1\], we see that we loop over the specific listen ports. At \[2\], we try to create a listener. Assuming that the listener fails, the RPC Server just keeps increasing the port until it finds an open one. But this begs the question of how the RPC Client knows which port to connect to, and we find the answer in CcConnectRpcEx:

    REMOTE_CLIENT *CcConnectRpcEx(char *server_name, char *password, bool *bad_pass, bool *no_remote, UCHAR *key, UINT *key_error_code, bool shortcut_disconnect, UINT wait_retry)
    {
        // [...]
    
    #ifdef  OS_WIN32
        // read the current port number from the registry of the localhost
        if (StrCmpi(server_name, "localhost") == 0)
        {
            reg_port = MsRegReadIntEx2(REG_LOCAL_MACHINE, CLIENT_WIN32_REGKEYNAME, CLIENT_WIN32_REGVALUE_PORT, false, true); // [3]
            reg_pid = MsRegReadIntEx2(REG_LOCAL_MACHINE, CLIENT_WIN32_REGKEYNAME, CLIENT_WIN32_REGVALUE_PID, false, true);
    
            if (reg_pid != 0)
            {
                if (MsIsServiceRunning(GC_SVC_NAME_VPNCLIENT) == false)
                {
                    reg_port = 0;
                }
            }
            else
            {
                reg_port = 0;
            }
        }
    
        if (reg_port != 0)
        {
            s = Connect(server_name, reg_port); // [4]
    
            if (s != NULL)
            {
                goto L_TRY;
            }
        }
    
    #endif  // OS_WIN32
    

At least for Windows, assuming our server is running on local host, then a registry key is grabbed at \[3\] which contains the correct port to connect to \[4\]. But if the SoftEther VPN service is not running, or we are connecting remotely, or if we are using a Linux RPC client, then we hit the following code:

        port_start = CLIENT_CONFIG_PORT - 1;
    
    RETRY:
        port_start++;
    
        if (port_start >= (CLIENT_CONFIG_PORT + 5))
        {
            return NULL;
        }
    
        ok = false;
    
        while (true)
        {
            for (i = port_start;i < (CLIENT_CONFIG_PORT + 5);i++) // [5]
            {
                if (CheckTCPPort(server_name, i)) // [6]
                {
                    ok = true;
                    break;
                }
    
        // [...]
        }
    
    if (ok == false)
    {
        if (key_error_code)
        {
            *key_error_code = ERR_CONNECT_FAILED;
        }
        return NULL;
    }
    
    
    port_start = i;
    
    s = Connect(server_name, i);  // [7]
    

Again, we iterate over our specific port range at \[5\] and try to see if the TCP port is open at \[6\]. If the TCP port is closed, it is not considered an error unless all ports are closed. Assuming we’ve found a valid open port, we connect at \[7\].

With all this in mind, a vulnerability is apparent. Assume that a malicious user on a computer that’s expected to be running a SoftEtherVPN client binds to the first port available (9930 or 9931, which is possible without admin privileges), which the RPC server would normally bind to. When a normal SoftEtherVPN client user starts up their client, nothing errors out, since the RPC server would bind to the next available port after the malicious MitM port. The legitimate RPC client meanwhile would connect automatically to the malicious man-in-the-middle port without ever knowing their mistake and would send traffic unencrypted through the man-in-the-middle.

Assuming this occurs, locally or remotely, the attacker has gained a large attack surface. Aside from potentially exploiting other bugs within the RPC client and RPC server, the attacker would have the same access to the VPN client, potentially gaining access to sensitive networks. Alternatively, they could subsequently set up a man-in-the-middle attack against the VPN network itself, potentially leading to further escalation into the network. This could be done crudely either by adding a malicious trusted CA to the SoftEtherVPN client (which would write to the disk), or by intercepting and manipulating the network traffic between the RPC server and RPC client, such that untrusted CA certificates on the remote VPN side were automatically trusted without popping up a message.

**Crash Information**

    $ python2 decept.py 127.0.0.1 9931 127.0.0.1 9932 -l tcp -r tcp --timeout .1 --dont_kill
    [<_<] Decept proxy/sniffer [>_>]
    
    [*.*] Listening on 127.0.0.1:9931
    [$.$] local:tcp|remote:tcp
    [>.>] 12:15:37.349951 Received Connection from ('127.0.0.1', 52198)
    [>.>] 12:15:37.467882 Received Connection from ('127.0.0.1', 52208)
    0000   00 00 00 01 f9 6c ea 19 8a d1 dd 56 17 ac 08 4a    .....l.....V...J
    0010   3d 92 c6 10 77 08 c0 ef                            =...w...
    [o.o] 12:15:37.626257 Sent 24 bytes to remote (127.0.0.1:52208->127.0.0.1:9932)
    
    0000   00 00 00 00                                        ....
    [o.o] 12:15:37.733871 Sent 4 bytes to local (127.0.0.1:52208<-127.0.0.1:9932)
    
    0000   00 00 00 31 00 00 00 01 00 00 00 0e 66 75 6e 63    ...1........func
    0010   74 69 6f 6e 5f 6e 61 6d 65 00 00 00 02 00 00 00    tion_name.......
    0020   01 00 00 00 10 47 65 74 43 6c 69 65 6e 74 56 65    .....GetClientVe
    0030   72 73 69 6f 6e                                     rsion
    [o.o] 12:15:37.841662 Sent 53 bytes to remote (127.0.0.1:52208->127.0.0.1:9932)
    
    0000   00 00 01 c3 00 00 00 0b 00 00 00 16 43 6c 69 65    ............Clie
    0010   6e 74 42 75 69 6c 64 49 6e 66 6f 53 74 72 69 6e    ntBuildInfoStrin
    0020   67 00 00 00 02 00 00 00 01 00 00 00 30 43 6f 6d    g...........0Com
    0030   70 69 6c 65 64 20 32 30 32 33 2f 30 31 2f 31 38    piled 2023/01/18
    0040   20 31 37 3a 33 35 3a 34 37 20 62 79 20 74 68 69     17:35:47 by thi
    0050   65 66 79 20 61 74 20 6b 69 6c 6c 6d 65 00 00 00    efy at killme...
    0060   0f 43 6c 69 65 6e 74 42 75 69 6c 64 49 6e 74 00    .ClientBuildInt.
    0070   00 00 00 00 00 00 01 00 00 14 3c 00 00 00 12 43    ..........<....C
    0080   6c 69 65 6e 74 50 72 6f 64 75 63 74 4e 61 6d 65    lientProductName
    0090   00 00 00 02 00 00 00 01 00 00 00 26 53 6f 66 74    ...........&Soft
    00a0   45 74 68 65 72 20 56 50 4e 20 43 6c 69 65 6e 74    Ether VPN Client
    00b0   20 44 65 76 65 6c 6f 70 65 72 20 45 64 69 74 69     Developer Editi
    00c0   6f 6e 00 00 00 0d 43 6c 69 65 6e 74 56 65 72 49    on....ClientVerI
    00d0   6e 74 00 00 00 00 00 00 00 01 00 00 01 f6 00 00    nt..............
    00e0   00 14 43 6c 69 65 6e 74 56 65 72 73 69 6f 6e 53    ..ClientVersionS
    00f0   74 72 69 6e 67 00 00 00 02 00 00 00 01 00 00 00    tring...........
    0100   23 56 65 72 73 69 6f 6e 20 35 2e 30 32 20 42 75    #Version 5.02 Bu
    0110   69 6c 64 20 35 31 38 30 20 20 20 28 45 6e 67 6c    ild 5180   (Engl
    0120   69 73 68 29 00 00 00 0f 49 73 56 67 63 53 75 70    ish)....IsVgcSup
    0130   70 6f 72 74 65 64 00 00 00 00 00 00 00 01 00 00    ported..........
    0140   00 00 00 00 00 14 49 73 56 4c 61 6e 4e 61 6d 65    ......IsVLanName
    0150   52 65 67 75 6c 61 74 65 64 00 00 00 00 00 00 00    Regulated.......
    0160   01 00 00 00 00 00 00 00 07 4f 73 54 79 70 65 00    .........OsType.
    0170   00 00 00 00 00 00 01 00 00 0c 1c 00 00 00 0a 50    ...............P
    0180   72 6f 63 65 73 73 49 64 00 00 00 00 00 00 00 01    rocessId........
    0190   00 00 00 00 00 00 00 0c 53 68 6f 77 56 67 63 4c    ........ShowVgcL
    01a0   69 6e 6b 00 00 00 00 00 00 00 01 00 00 00 00 00    ink.............
    01b0   00 00 09 43 6c 69 65 6e 74 49 64 00 00 00 02 00    ...ClientId.....
    01c0   00 00 01 00 00 00 00                               .......
    [o.o] 12:15:37.949690 Sent 455 bytes to local (127.0.0.1:52208<-127.0.0.1:9932)
    

**VENDOR RESPONSE**

The vendor issued an advisory: https://www.softether.org/9-about/News/904-SEVPN202301

**TIMELINE**

2023-06-12 - Vendor Disclosure  
2023-06-30 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-32634: TALOS-2023-1755 || Cisco Talos Intelligence Group

A denial-of-service vulnerability exists in the vpnserver ConnectionAccept() functionality of SoftEther VPN 5.02. A set of specially crafted network connections can lead to denial of service. An attacker can send a sequence of malicious packets to trigger this vulnerability.

**SUMMARY**

A denial-of-service vulnerability exists in the vpnserver ConnectionAccept() functionality of SoftEther VPN 5.02. A set of specially crafted network connections can lead to denial of service. An attacker can send a sequence of malicious packets to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

SoftEther VPN 5.01.9674  
SoftEther VPN 5.02

**PRODUCT URLS**

SoftEther VPN - https://www.softether.org/

**CVSSv3 SCORE**

7.5 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-400 - Uncontrolled Resource Consumption

**DETAILS**

SoftEther is a multi-platform VPN project that provides both server and client code to connect over a variety of VPN protocols, including Wireguard, PPTP, SSTP, L2TP, etc. SoftEther has a variety of features for both enterprise and personal use, and enables Nat Traversal out-of-the-box for remote-access setups behind firewalls.

To various ends, SoftEther VPN server accepts and parses HTTP connections by default on all of its configured TCP ports. Out of the box, this means TCP ports 443, 992, 1194 and 5555. Each port runs the ListenerTCPMainLoop function, which quickly hits the following code:

    // TCP listener main loop
    void ListenerTCPMainLoop(LISTENER *r)
    {
        SOCK *new_sock;
        SOCK *s;
        // Validate arguments
        if (r == NULL)
        {
            return;
        }
    
        Debug("ListenerTCPMainLoop Starts.\n");
        r->Status = LISTENER_STATUS_TRYING;
    
        while (true)
        {
            bool first_failed = true;
            Debug("Status = LISTENER_STATUS_TRYING\n");
            r->Status = LISTENER_STATUS_TRYING;
    
            // Try to Listen
            while (true)
            {
                UINT interval;
                // Stop flag inspection
        // [...]
    
                // Accept loop
            while (true)
            {
                // Accept
                Debug("Accept()\n");
                new_sock = Accept(s);           // [1]
                if (new_sock != NULL)
                {
                    // Accept success
                    Debug("Accepted.\n");
                    TCPAccepted(r, new_sock);   // [2]
                    ReleaseSock(new_sock);
                }
                else
                {
        STOP:
                    Debug("Accept Canceled.\n");
                    // Failed to accept (socket is destroyed)
                    // Close the listening socket
                    Disconnect(s);
                    ReleaseSock(s);
                    s = NULL;
    
       // [...] 
    

It suffices to say that each of these listeners continuously listens for new TCP connections, accepts the connections \[1\] and then spawns a new thread inside of \[2\] that eventually leads to the ConnectionAccept function:

    // Function that accepts a new connection
    void ConnectionAccept(CONNECTION *c)
    {
        SOCK *s;
        X *x;
        K *k;
        LIST *chain;
        char tmp[128];
        UINT initial_timeout = CONNECTING_TIMEOUT;  // (15 * 1000)
        UCHAR ctoken_hash[SHA1_SIZE];
    
        // Validate arguments
        if (c == NULL)
        {
            return;
        }
    
        Zero(ctoken_hash, sizeof(ctoken_hash));
    
        // Get a socket
        s = c->FirstSock;
        AddRef(s->ref);
    
        Dec(c->Cedar->AcceptingSockets);
    
        IPToStr(tmp, sizeof(tmp), &s->RemoteIP);
    
        SLog(c->Cedar, "LS_CONNECTION_START_1", tmp, s->RemoteHostname, (IS_SPECIAL_PORT(s->RemotePort) ? 0 : s->RemotePort), c->Name);
    
        // Timeout setting
        initial_timeout += GetMachineRand() % (CONNECTING_TIMEOUT / 2);  // [3] 
        SetTimeout(s, initial_timeout);
    
        // Handle third-party protocols
        if (s->IsReverseAcceptedSocket == false && s->Type == SOCK_TCP)
        {
            if (c->Cedar != NULL && c->Cedar->Server != NULL)
            {
                PROTO *proto = c->Cedar->Server->Proto;
                if (proto && ProtoHandleConnection(proto, s, NULL) == true) // [4] // => wireguard or OpenVPN
                {
                    c->Type = CONNECTION_TYPE_OTHER;
                    goto FINAL;
                }
            }
        }
    
        // Specify the encryption algorithm
        Lock(c->Cedar->lock);                 // [5]
        {
            if (c->Cedar->CipherList != NULL)
            {
                SetWantToUseCipher(s, c->Cedar->CipherList);
            }
    
            x = CloneX(c->Cedar->ServerX);
            k = CloneK(c->Cedar->ServerK);
            chain = CloneXList(c->Cedar->ServerChain);
        }
        Unlock(c->Cedar->lock);
    

Assuming that our socket is not sending Wireguard or OpenVPN traffic \[4\] (which is checked by peeking at bytes), the connection is treated as an HTTPS connection. The c->Cedar->lock is set at \[5\], and then some non-trivial functions are called within the code block. Important to note, the Cedar object is shared between all threads within the SoftEtherVPN server, and as such, the c->Cedar->lock is also shared between all threads. Thus, if we have a program repeatedly making SSL connections to any of the TCP ports that the vpnserver is configured for, more and more threads start contesting for the c->Cedar->lock because the code starting at \[5\] runs much slower than the ListenerTCPMainLoop can spawn new threads. This results in an ever-increasing number of threads waiting for the lock, the Server thread dying and being respawned and a killing of all existing VPN connections.

While it is worth noting that each of our TCP sockets have a timeout that is set at \[3\], in practice, the timeout ends up being anywhere from 15 to 22 seconds, depending on the hostname of the machine the server is running on. If we hit all of the four default configured TCP ports from a single VM, we can kill the server within a couple minutes. Once the server reaches around 32657 threads, memory gets sparse and an alloc causes an Abort() to be called. While the SoftEther vpnserver network service will restart (as it runs as a service), due to the speed at which we can continuously kill it, we believe this can be used for performing a denial of service.

**Crash Information**

    <(^.^)>#bt
    #0  futex_wait (private=0, expected=2, futex_word=0x5616139cd770) at ../sysdeps/nptl/futex-internal.h:146
    #1  __GI___lll_lock_wait (futex=futex@entry=0x5616139cd770, private=0) at ./nptl/lowlevellock.c:49
    #2  0x00007fda0bc98082 in lll_mutex_lock_optimized (mutex=0x5616139cd770) at ./nptl/pthread_mutex_lock.c:48
    #3  ___pthread_mutex_lock (mutex=0x5616139cd770) at ./nptl/pthread_mutex_lock.c:93
    #4  0x00007fda0bed55cb in UnixLock (lock=0x5616139cd750) at /softether/SoftEtherVPN_orig/src/Mayaqua/Unix.c:1858
    #5  0x00007fda0bfeb016 in ConnectionAccept (c=c@entry=0x7fd9f4166b30) at /softether/SoftEtherVPN_orig/src/Cedar/Connection.c:3036
    #6  0x00007fda0c008142 in TCPAcceptedThread (param=<optimized out>, t=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:181
    #7  TCPAcceptedThread (t=<optimized out>, param=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:140
    #8  0x00007fda0be9943d in ThreadPoolProc (param=0x7fd9ba976270, t=0x7fd9ba9807c0) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:872
    #9  ThreadPoolProc (t=0x7fd9ba9807c0, param=0x7fd9ba976270) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:827
    #10 0x00007fda0bed57d1 in UnixDefaultThreadProc (param=0x7fd9ba980650) at /softether/SoftEtherVPN_orig/src/Mayaqua/Unix.c:1594
    #11 0x00007fda0bc94b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #12 0x00007fda0bd26a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    
       
    <(^.^)>#bt
    #0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140184485450624) at ./nptl/pthread_kill.c:44
    #1  __pthread_kill_internal (signo=6, threadid=140184485450624) at ./nptl/pthread_kill.c:78
    #2  __GI___pthread_kill (threadid=140184485450624, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
    #3  0x00007f81e5c42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
    #4  0x00007f81e5c287f3 in __GI_abort () at ./stdlib/abort.c:79
    #5  0x00007f81e5fc043e in AbortExit () at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:2086
    #6  0x00007f81e5fd7a42 in NewThreadInternal (thread_proc=thread_proc@entry=0x7f81e5fd53b0 <ThreadPoolProc>, param=param@entry=0x7f81344f4c00) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:1198
    #7  0x00007f81e5fd7bb2 in NewThreadNamed (thread_proc=thread_proc@entry=0x7f81e5fc51d0 <DnsResolverReverse>, param=param@entry=0x7f81344f7a10, name=name@entry=0x7f81e601758a "DnsResolverReverse") at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:997
    #8  0x00007f81e5fc4eae in DnsResolveReverse (dst=dst@entry=0x7f7f3e7545e0 "", size=size@entry=512, ip=ip@entry=0x7f7f51850294, timeout=500, timeout@entry=0, cancel_flag=cancel_flag@entry=0x0) at /softether/SoftEtherVPN_orig/src/Mayaqua/DNS.c:586
    #9  0x00007f81e5fee5a9 in GetHostName (hostname=0x7f7f3e7545e0 "", size=512, ip=0x7f7f51850294) at /softether/SoftEtherVPN_orig/src/Mayaqua/Network.c:15412
    #10 0x00007f81e5fee6a5 in AcceptInitEx (s=0x7f7f51850140, no_lookup_hostname=<optimized out>) at /softether/SoftEtherVPN_orig/src/Mayaqua/Network.c:12755
    #11 0x00007f81e61440fe in TCPAcceptedThread (param=<optimized out>, t=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:172
    #12 TCPAcceptedThread (t=<optimized out>, param=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:140
    #13 0x00007f81e5fd543d in ThreadPoolProc (param=0x7f81444ee2d0, t=0x7f812d624840) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:872
    #14 ThreadPoolProc (t=0x7f812d624840, param=0x7f81444ee2d0) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:827
    #15 0x00007f81e60117d1 in UnixDefaultThreadProc (param=0x7f812d6264e0) at /softether/SoftEtherVPN_orig/src/Mayaqua/Unix.c:1594
    #16 0x00007f81e5c94b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #17 0x00007f81e5d26a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    

**VENDOR RESPONSE**

Vendor pull request on Github: https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1911

**TIMELINE**

2023-04-26 - Vendor Disclosure  
2023-09-28 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-25774: TALOS-2023-1743 || Cisco Talos Intelligence Group

An integer underflow vulnerability exists in the vpnserver OvsProcessData functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

An integer underflow vulnerability exists in the vpnserver OvsProcessData functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

SoftEther VPN 5.01.9674  
SoftEther VPN 5.02  
While 5.01.9674 is a development version, it is distributed at the time of writing by Ubuntu and other Debian-based distributions.

**PRODUCT URLS**

SoftEther VPN - https://www.softether.org/

**CVSSv3 SCORE**

7.5 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-191 - Integer Underflow (Wrap or Wraparound)

**DETAILS**

SoftEther is a multi-platform VPN project that provides both server and client code to connect over a variety of VPN protocols, including Wireguard, PPTP, SSTP, L2TP, etc. SoftEther has a variety of features for both enterprise and personal use, and enables Nat Traversal out-of-the-box for remote-access setups behind firewalls.

Among the various VPN protocols that SoftEther can talk in, by default, OpenVPN code can be reached via any of the open TCP ports. Based on the start of the input buffer, we can either hit the OpenVPN code or the Wireguard code, or even the normal HTTPS server for management of the VPN configuration itself:

    bool ProtoHandleConnection(PROTO *proto, SOCK *sock, const char *protocol)
    {
        const PROTO_IMPL *impl;
        void *impl_data = NULL;
    
        UCHAR *buf;
        TCP_RAW_DATA *recv_raw_data;
        FIFO *send_fifo;
        INTERRUPT_MANAGER *im;
        SOCK_EVENT *se;
    
        if (proto == NULL || sock == NULL)
        {
            return false;
        }
    
        {
            const PROTO_CONTAINER *container = NULL;
            wchar_t *proto_name;
            LIST *options;
    
            if (protocol != NULL)
            {
                UINT i;
                for (i = 0; i < LIST_NUM(proto->Containers); ++i)
                {
                    const PROTO_CONTAINER *tmp = LIST_DATA(proto->Containers, i);
                    if (StrCmp(tmp->Name, protocol) == 0)
                    {
                        container = tmp;
                        break;
                    }
                }
            }
            else
            {
                UCHAR tmp[PROTO_CHECK_BUFFER_SIZE]; // 2 bytes
    
                if (Peek(sock, tmp, sizeof(tmp)) == 0)
                {
                    return false;
                }
    
                container = ProtoDetect(proto, PROTO_MODE_TCP, tmp, sizeof(tmp)); // [1] 
            }
    

Unless a protocol is explicitly passed to the ProtoHandleConnection function, we end up iterating over all the loaded proto->Containers and calling the container’s ProtoDetect() function at \[1\]:

    const PROTO_CONTAINER *ProtoDetect(const PROTO *proto, const PROTO_MODE mode, const UCHAR *data, const UINT size)
    {
        UINT i;
    
        if (proto == NULL || data == NULL || size == 0)
        {
            return NULL;
        }
    
        for (i = 0; i < LIST_NUM(proto->Containers); ++i)
        {
            const PROTO_CONTAINER *container = LIST_DATA(proto->Containers, i);
            const PROTO_IMPL *impl = container->Impl;
    
            if (ProtoEnabled(proto, container->Name) == false)
            {
                Debug("ProtoDetect(): skipping %s because it's disabled\n", container->Name);
                continue;
            }
    
            if (impl->IsPacketForMe != NULL && impl->IsPacketForMe(mode, data, size)) // [2]
            {
                Debug("ProtoDetect(): %s detected\n", container->Name);
                return container;
            }
        }
    
        Debug("ProtoDetect(): unrecognized protocol\n");
        return NULL;
    }
    

ProtoDetect() boils down to answering the question: Is this packet designated for this specific protocol? And so each container calls its Impl->IsPacketForMe at \[2\]. To understand what functions underpin the IsPacketForMe function pointer, let us quickly look to see where protocols actually get loaded:

    PROTO *ProtoNew(CEDAR *cedar)
    {
        PROTO *proto;
    
        if (cedar == NULL)
        {
            return NULL;
        }
    
        proto = Malloc(sizeof(PROTO));
        proto->Cedar = cedar;
        proto->Containers = NewList(ProtoContainerCompare);
        proto->Sessions = NewHashList(ProtoSessionHash, ProtoSessionCompare, 0, true);
    
        AddRef(cedar->ref);
    
        // WireGuard
        Add(proto->Containers, ProtoContainerNew(WgsGetProtoImpl()));   // [3]
        // OpenVPN
        Add(proto->Containers, ProtoContainerNew(OvsGetProtoImpl()));   // [4]
        // SSTP
        Add(proto->Containers, ProtoContainerNew(SstpGetProtoImpl()));  // [5]
    
        proto->UdpListener = NewUdpListener(ProtoHandleDatagrams, proto, &cedar->Server->ListenIP);
    
        return proto;
    }
    

Clearly written above, we can see that the only VPN protocols enabled by default in SoftEther are WireGuard \[3\], OpenVPN \[4\] and SSTP \[5\]. Since we only care about OpenVPN in this advisory, only the OvsGetProtoImpl function will follow:

    const PROTO_IMPL *OvsGetProtoImpl()
    {
        static const PROTO_IMPL impl =
        {
            OvsName,
            OvsOptions,
            NULL,
            OvsInit,
            OvsFree,
            OvsIsPacketForMe,
            OvsProcessData,
            OvsProcessDatagrams
        };
    
        return &impl;
    }
    

Wrapped by the most simple function, OvsGetProtoImpl() returns a set of function pointers to our proto->Containers. As such, we must now look at the OvsIsPacketForMe function and subsequently OvsProcessData:

    // Check whether it's an OpenVPN packet
    bool OvsIsPacketForMe(const PROTO_MODE mode, const void *data, const UINT size)
    {
        if (data == NULL || size < 2)
        {
            return false;
        }
    
        if (mode == PROTO_MODE_TCP)  // [6]
        {
            const UCHAR *raw = data;
            if (raw[0] == 0x00 && raw[1] == 0x0E)
            {
                return true;
            }
        }
        else if (mode == PROTO_MODE_UDP)
        {
            OPENVPN_PACKET *packet = OvsParsePacket(data, size);
            if (packet == NULL)
            {
                return false;
            }
    
            OvsFreePacket(packet);
            return true;
        }
    
        return false;
    }
    

Since we’re talking TCP, we hit the branch at \[6\]. The only thing that determines whether or not a packet is treated as OpenVPN traffic is if it starts with “\\x00\\x0E”. Continuing on, we now examine where the actual processing of data occurs in OvsProcessData:

    bool OvsProcessData(void *param, TCP_RAW_DATA *in, FIFO *out)
    {
        bool ret = true;
        UINT i;
        OPENVPN_SERVER *server = param;
        UCHAR buf[OPENVPN_TCP_MAX_PACKET_SIZE];  // 2000, 0x7d0  
    
        if (server == NULL || in == NULL || out == NULL)
        {
            return false;
        }
    
        // Separate to a list of datagrams by interpreting the data received from the TCP socket
        while (true)
        {
            UDPPACKET *packet;
            USHORT payload_size, packet_size;
            FIFO *fifo = in->Data;
            const UINT fifo_size = FifoSize(fifo);
    
            if (fifo_size < sizeof(USHORT))
            {
                // Non-arrival
                break;
            }
    
            // The beginning of a packet contains the data size
            payload_size = READ_USHORT(FifoPtr(fifo));           // [7]
            packet_size = payload_size + sizeof(USHORT);         // [8] 
    
            if (payload_size == 0 || packet_size > sizeof(buf))
            {
                ret = false;
                Debug("OvsProcessData(): Invalid payload size: %u bytes\n", payload_size);
                break;
            }
    
            if (fifo_size < packet_size) // fifo_size ends up being actual size of bytes recvd...
            {
                // Non-arrival
                break;
            }
    
    
        if (ReadFifo(fifo, buf, packet_size) != packet_size)    // [9]
        {
            ret = false;
            Debug("OvsProcessData(): ReadFifo() failed to read the packet\n");
            break;
        }
    
        // Insert packet into the list  // only a dos since we're oob'ing into thread stack data
        packet = NewUdpPacket(&in->SrcIP, in->SrcPort, &in->DstIP, in->DstPort, Clone(buf + sizeof(USHORT), payload_size), payload_size);  // [10]
        Add(server->RecvPacketList, packet);
    }
    
    // Process the list of received datagrams
    OvsRecvPacket(server, server->RecvPacketList, OPENVPN_PROTOCOL_TCP); // [11]
    

Starting out, because of our required “\\x00\\x0e” start to our packet, we hit the READ_USHORT at \[7\], and payload_size is naturally 0xe. The subsequent 0xe bytes get read in at \[9\], and then a UDP packet is created at \[10\] to pass the packet on for further processing at \[11\]. We need not go further, however, since the vulnerability lies plainly above. When hitting the next iteration of the while (true) loop, there is no requirement for our buffer to start with “\\x00\\x0e”. As such, if our next two bytes are, say, “\\xFF\\xFF”, then the payload_size gets set to 0xFFFF at \[7\], while the packet_size ushort gets set to 0x1 at \[8\]. Thus we read in a single byte at \[9\], which passes the return value check, and a new UDP packet is created with a length of payload_size at \[10\] (not packet_size).

While normally this would just read in out-of-bounds data from the buf stack buffer and pass it into further processing, since we’re in a linux thread, there’s usually a guard page at the bottom of the thread stack like so:

      0x7f5d00000000     0x7f5d00063000    0x63000        0x0  rw-p   // buf @ 0x7f5d00045abe
      0x7f5d486c6000     0x7f5d486c7000     0x1000        0x0  ---p   // guard pages
      0x7f5d486c7000     0x7f5d486f8000    0x31000        0x0  rw-p   // next thread 
    

Apparently the OvsProcessData function is not far up enough in the backtrace, and so our 0xFFFF read on the stack ends up hitting the guard page and causing a crash. This might behave differently if we are on a Windows SoftEther server; it has not been tested.

**Crash Information**

    Thread 22 "vpnserver" received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7f5d486c5380 (LWP 1214911)]
    __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:708
    708     ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
    <(^.^)>#bt
    #0  __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:708
    #1  0x00007f5d49959e1c in Clone (addr=addr@entry=0x7f5d486c3e52, size=size@entry=65535) at /softether/SoftEtherVPN_orig/src/Mayaqua/Memory.c:3790
    #2  0x00007f5d49ae7253 in OvsProcessData (param=0x7f5d0001d710, in=0x7f5d0000fa40, out=0x7f5d0000bbe0) at /softether/SoftEtherVPN_orig/src/Cedar/Proto_OpenVPN.c:171
    #3  0x00007f5d49acfc0a in ProtoHandleConnection (proto=0x558a14d696d0, sock=sock@entry=0x7f5d1c007080, protocol=protocol@entry=0x0) at /softether/SoftEtherVPN_orig/src/Cedar/Proto.c:590
    #4  0x00007f5d49aa6213 in ConnectionAccept (c=c@entry=0x7f5d0000df40) at /softether/SoftEtherVPN_orig/src/Cedar/Connection.c:3027
    #5  0x00007f5d49ac3142 in TCPAcceptedThread (param=<optimized out>, t=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:181
    #6  TCPAcceptedThread (t=<optimized out>, param=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:140
    #7  0x00007f5d4995443d in ThreadPoolProc (param=0x7f5cfc00c730, t=0x7f5cfc00c500) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:872
    #8  ThreadPoolProc (t=0x7f5cfc00c500, param=0x7f5cfc00c730) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:827
    #9  0x00007f5d499907d1 in UnixDefaultThreadProc (param=0x7f5cfc0072e0) at /softether/SoftEtherVPN_orig/src/Mayaqua/Unix.c:1594
    #10 0x00007f5d49759b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #11 0x00007f5d497eba00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    

**VENDOR RESPONSE**

Vendor pull request on Github: https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1824

**TIMELINE**

2023-04-03 - Vendor Disclosure  
2023-04-03 - Initial Vendor Contact  
2023-04-17 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-22308: TALOS-2023-1737 || Cisco Talos Intelligence Group

A denial-of-service vulnerability exists in the vpnserver EnSafeHttpHeaderValueStr functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service.

**SUMMARY**

A denial-of-service vulnerability exists in the vpnserver EnSafeHttpHeaderValueStr functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

SoftEther VPN 5.01.9674  
SoftEther VPN 5.02  
While 5.01.9674 is a development version, it is distributed at the time of writing by Ubuntu and other Debian-based distributions.

**PRODUCT URLS**

SoftEther VPN - https://www.softether.org/

**CVSSv3 SCORE**

7.5 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-125 - Out-of-bounds Read

**DETAILS**

SoftEther is a multi-platform VPN project that provides both server and client code to connect over a variety of VPN protocols, including Wireguard, PPTP, SSTP, L2TP, etc. SoftEther has a variety of features for both enterprise and personal use, and enables Nat Traversal out-of-the-box for remote-access setups behind firewalls.

To various ends, SoftEther VPN server accepts and parses HTTP connections by default on all of its configured TCP ports. Out of the box this means TCP ports 443, 992, 1194 and 5555. Assuming that our incoming packet does not look like any of the other supported TCP protocols, we eventually get to the ServerAccept function:

    // Server accepts a connection from client
    bool ServerAccept(CONNECTION *c)
    {
        bool ret = false;
        UINT err;
        PACK *p;
        char username_real[MAX_SIZE];
        char method[MAX_SIZE]; // 512
        char hubname[MAX_SIZE];
        char username[MAX_SIZE];
        char groupname[MAX_SIZE];
        UCHAR session_key[SHA1_SIZE];
        UCHAR ticket[SHA1_SIZE];
    
        // [...]
    
        // Validate arguments
        if (c == NULL)
        {
            return false;
        }
    
        // [...]
    
        // Receive the signature
        Debug("Downloading Signature...\n");
        error_detail_2 = NULL;
        if (ServerDownloadSignature(c, &error_detail_2) == false){  // [1] 
            //[...]
            goto CLEANUP;
        }
    

Assorted initialization and an unruly amount of stack variables are skipped just so we can quickly see the first branching piece of code we hit at \[1\] in ServerDownloadSignature:

    // Download the signature
    bool ServerDownloadSignature(CONNECTION *c, char **error_detail_str)
    {
        HTTP_HEADER *h;
        UCHAR *data;
        UINT data_size;
        SOCK *s;
        UINT num = 0, max = 19;
        SERVER *server;
        char *vpn_http_target = HTTP_VPN_TARGET2;
        // Validate arguments
        if (c == NULL)
        {
            return false;
        }
    
        server = c->Cedar->Server;
    
        s = c->FirstSock;          // [2]
    
        while (true)
        {
            bool not_found_error = false;
    
            num++;
            if (num > max)
            {
                // Disconnect
                Disconnect(s);
                c->Err = ERR_CLIENT_IS_NOT_VPN;
    
                *error_detail_str = "HTTP_TOO_MANY_REQUEST";
                return false;
            }
            // Receive a header
            h = RecvHttpHeader(s);  // [3]
            if (h == NULL)
            {
    
        // [...]
    

The SOCK *s variable is our client’s socket \[2\], which we then pass into the RecvHttpHeader function at \[3\] to actually read bytes and process the data:

    // Receive an HTTP header
    HTTP_HEADER *RecvHttpHeader(SOCK *s)
    {
        TOKEN_LIST *token = NULL;
        char *str = NULL;
        HTTP_HEADER *header = NULL;
        // Validate arguments
        if (s == NULL)
        {
            return NULL;
        }
    
        // Get the first line
        str = RecvLine(s, HTTP_HEADER_LINE_MAX_SIZE); // [4]
        if (str == NULL)
        {
            return NULL;
        }
    
        // Split into tokens
        token = ParseToken(str, " "); 
    
        FreeSafe(PTR_TO_PTR(str));
    
        if (token->NumTokens < 3)
        {
            FreeToken(token);
            return NULL;
        }
    
        // Creating a header object
        header = NewHttpHeader(token->Token[0], token->Token[1], token->Token[2]);
        FreeToken(token);
    
        if (StrCmpi(header->Version, "HTTP/0.9") == 0)
        {
            // The header ends with this line
            return header;
        }
    
        // Get the subsequent lines
        while (true)   
        {
            str = RecvLine(s, HTTP_HEADER_LINE_MAX_SIZE);  // [5]
            Trim(str);
            if (IsEmptyStr(str))
            {
                // End of header
                FreeSafe(PTR_TO_PTR(str)); 
                break;
            }
    
            if (AddHttpValueStr(header, str) == false) // [6] 
            {
                FreeSafe(PTR_TO_PTR(str)); 
                FreeHttpHeader(header);
                header = NULL;
                break;
            }
    
            FreeSafe(PTR_TO_PTR(str));
        }
    
        return header;
    }
    

To start, at \[4\], RecvLine reads in at max 0x1000 bytes or until it reads a “\\r\\n”. This line is split into the basic HTTP headers, and, assuming that’s all well and good, we enter the loop at \[5\] to continue reading the rest of the data. Again reading until 0x1000 bytes or “\\r\\n”, we take each line of the HTTP header and pass it into the AddHttpValueStr function at \[6\]. A quick digression before we delve into AddHttpValueStr: All of the parsed data is added into the HTTP_HEADER struct, which is just three pointers for the Method, Target and Version, and then a LIST * object which holds all of the actual HTTP headers:

    // HTTP header
    struct HTTP_HEADER
    {
        char *Method;                   // Method
        char *Target;                   // Target
        char *Version;                  // Version
        LIST *ValueList;                // Value list
    };
    

Continuing into AddHttpValueStr:

    // Adds the HTTP value contained in the string to the HTTP header
    bool AddHttpValueStr(HTTP_HEADER* header, char *string)
    {
        HTTP_VALUE *value = NULL;
        UINT pos = 0;
        char *value_name = NULL;
        char *value_data = NULL;
    
        // Validate arguments
        if (header == NULL || IsEmptyStr(string))
        {
            return false;
        }
    
        // Sanitize string
        EnSafeHttpHeaderValueStr(string, ' '); // [7]
    
        // Get the position of the colon
        pos = SearchStr(string, ":", 0);  // [8]
        if (pos == INFINITE)
        {
            // The colon does not exist
            return false;
        }
    
        if ((pos + 1) >= StrLen(string))
        {
            // There is no data
            return false;
        }
    
        // Divide into the name and the data
        value_name = Malloc(pos + 1);
        Copy(value_name, string, pos);
        value_name[pos] = 0;
        value_data = &string[pos + 1]; 
    
        value = NewHttpValue(value_name, value_data); // [9] 
        if (value == NULL)
        {
            Free(value_name);
            return false;
        }
    
        Free(value_name);
    
        AddHttpValue(header, value); // [10] 
    
        return true;
    }
    

At \[7\], there is some escaping and processing done on our char *string parameter that was passed in. Soon after, the string is separated at the colon \[8\], allocations are made to contain copies of the split string \[9\] and we finally add a new entry to the HTTP_HEADER->ValueList at \[10\]. We need not go much further, so let us examine the EnSafeHttpHeaderValueStr function to see how the input HTTP header string gets processed:

    // Replace '\r' and '\n' with the specified character.
    // If the specified character is a space (unsafe), the original character is removed.
    void EnSafeHttpHeaderValueStr(char *str, char replace)
    {
        UINT length = 0;
        UINT index = 0;
    
        // Validate arguments
        if (str == NULL)
        {
            return;
        }
    
        length = StrLen(str);
        while (index < length)
        {
            if (str[index] == '\r' || str[index] == '\n')
            {
                if (replace == ' ')
                {
                    Move(&str[index], &str[index + 1], length - index); // [11]
                }
                else
                {
                    str[index] = replace;
                }
            }
            else if (str[index] == '\\')
            {
                if (str[index + 1] == 'r' || str[index + 1] == 'n') 
                {
                    if (replace == ' ')
                    {
                        Move(&str[index], &str[index + 2], length - index); // [12]
                        index--;   
                    }             
                    else
                    {
                        str[index] = str[index + 1] = replace;
                        index++;
                    }
                }
            }
            index++;
        }
    }
    

To sum up this function, each character is checked to see if there’s a “\\r”, “\\n”, “\\\\r” or “\\\\n”. If there is, it is replaced with the char replace, or the entire string is shifted backwards by one or two bytes. While the code at \[11\] is valid because the char *str parameter is null terminated, and as such can never read out of bounds, the line at \[12\] is a different story. Since our Move function copies from [index + 2] and the length is length - index, every copy this line makes will hit the null terminator and the byte immediately after. As such, any HTTP header passed into this function that contains a “\\\\r” or “\\\\n” will cause a one-byte out-of-bounds read to happen. And at least for the code path we have followed above, our input char *str is allocated on the heap, which means that with very careful heap manipulation, we can cause this single byte to be the first byte of an unmapped page or non-readable page in memory, resulting in a server crash and denial of service.

**Crash Information**

    SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /softether/SoftEtherVPN/src/Mayaqua/Encrypt.c:4725:20 in 
    =================================================================
    ==89041==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040001a58bb at pc 0x565370d9394f bp 0x7f2598180410 sp 0x7f259817fbe0
    READ of size 26 at 0x6040001a58bb thread T30
        #0 0x565370d9394e in __asan_memmove (/softether/asan_build/vpnserver+0xa094e) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c6e1099 in Move /softether/SoftEtherVPN/src/Mayaqua/Memory.c:3822:2
        #2 0x7f259c7e4218 in EnSafeHttpHeaderValueStr /softether/SoftEtherVPN/src/Mayaqua/Str.c:2082:6
        #3 0x7f259c689be1 in AddHttpValueStr /softether/SoftEtherVPN/src/Mayaqua/HTTP.c:929:2
        #4 0x7f259c68b890 in RecvHttpHeader /softether/SoftEtherVPN/src/Mayaqua/HTTP.c:1145:7
        #5 0x7f259d94168b in ServerDownloadSignature /softether/SoftEtherVPN/src/Cedar/Protocol.c:5791:7
        #6 0x7f259d91dc91 in ServerAccept /softether/SoftEtherVPN/src/Cedar/Protocol.c:1228:6
        #7 0x7f259d677def in ConnectionAccept /softether/SoftEtherVPN/src/Cedar/Connection.c:3077:6
        #8 0x7f259d760478 in TCPAcceptedThread /softether/SoftEtherVPN/src/Cedar/Listener.c:181:2
        #9 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #10 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #11 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
        #12 0x7f259c1269ff  misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    
    0x6040001a58bb is located 0 bytes to the right of 43-byte region [0x6040001a5890,0x6040001a58bb)
    allocated by thread T30 here:
        #0 0x565370d941ce in malloc (/softether/asan_build/vpnserver+0xa11ce) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83b386 in UnixMemoryAlloc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2043:6
        #2 0x7f259c6dfb9e in InternalMalloc /softether/SoftEtherVPN/src/Mayaqua/Memory.c:3692:10
        #3 0x7f259c6df2da in MallocEx /softether/SoftEtherVPN/src/Mayaqua/Memory.c:3523:8
        #4 0x7f259c793df1 in RecvLine /softether/SoftEtherVPN/src/Mayaqua/Network.c:19506:11
        #5 0x7f259c68b8aa in RecvHttpHeader /softether/SoftEtherVPN/src/Mayaqua/HTTP.c:1136:9
        #6 0x7f259d94168b in ServerDownloadSignature /softether/SoftEtherVPN/src/Cedar/Protocol.c:5791:7
        #7 0x7f259d91dc91 in ServerAccept /softether/SoftEtherVPN/src/Cedar/Protocol.c:1228:6
        #8 0x7f259d677def in ConnectionAccept /softether/SoftEtherVPN/src/Cedar/Connection.c:3077:6
        #9 0x7f259d760478 in TCPAcceptedThread /softether/SoftEtherVPN/src/Cedar/Listener.c:181:2
        #10 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #11 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #12 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
    
    Thread T30 created by T27 here:
        #0 0x565370d7d64c in __interceptor_pthread_create (/softether/asan_build/vpnserver+0x8a64c) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83d677 in UnixInitThread /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1673:6
        #2 0x7f259c6ae087 in NewThreadInternal /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:1200:7
        #3 0x7f259c6ad525 in NewThreadNamed /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:997:10
        #4 0x7f259c770bcb in ConnectEx5 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14692:8
        #5 0x7f259c7279e7 in ConnectEx4 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14556:9
        #6 0x7f259c7279e7 in ConnectEx3 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14552:9
        #7 0x7f259c7279e7 in ConnectEx2 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14548:9
        #8 0x7f259c7279e7 in ConnectEx /softether/SoftEtherVPN/src/Mayaqua/Network.c:14544:9
        #9 0x7f259c7279e7 in GetMyPrivateIP /softether/SoftEtherVPN/src/Mayaqua/Network.c:4405:6
        #10 0x7f259c726e32 in RUDPIpQueryThread /softether/SoftEtherVPN/src/Mayaqua/Network.c:4345:8
        #11 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #12 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #13 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
    
    Thread T27 created by T25 here:
        #0 0x565370d7d64c in __interceptor_pthread_create (/softether/asan_build/vpnserver+0x8a64c) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83d677 in UnixInitThread /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1673:6
        #2 0x7f259c6ae087 in NewThreadInternal /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:1200:7
        #3 0x7f259c6ad525 in NewThreadNamed /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:997:10
        #4 0x7f259c72f950 in NewRUDP /softether/SoftEtherVPN/src/Mayaqua/Network.c:5351:22
        #5 0x7f259c71bdf2 in NewRUDPServer /softether/SoftEtherVPN/src/Mayaqua/Network.c:5178:6
        #6 0x7f259c71bdf2 in ListenRUDPEx /softether/SoftEtherVPN/src/Mayaqua/Network.c:2504:6
        #7 0x7f259d7632cb in ListenerTCPMainLoop /softether/SoftEtherVPN/src/Cedar/Listener.c:405:9
        #8 0x7f259d765924 in ListenerThread /softether/SoftEtherVPN/src/Cedar/Listener.c:563:3
        #9 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #10 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #11 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
    
    Thread T25 created by T0 here:
        #0 0x565370d7d64c in __interceptor_pthread_create (/softether/asan_build/vpnserver+0x8a64c) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83d677 in UnixInitThread /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1673:6
        #2 0x7f259c6ae087 in NewThreadInternal /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:1200:7
        #3 0x7f259c6ad525 in NewThreadNamed /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:997:10
        #4 0x7f259d768069 in NewListenerEx5 /softether/SoftEtherVPN/src/Cedar/Listener.c:821:6
        #5 0x7f259d76799e in NewListenerEx4 /softether/SoftEtherVPN/src/Cedar/Listener.c:772:9
        #6 0x7f259da20f4b in SiNewServerEx /softether/SoftEtherVPN/src/Cedar/Server.c:10934:10
        #7 0x7f259d9e8e51 in SiNewServer /softether/SoftEtherVPN/src/Cedar/Server.c:10795:9
        #8 0x7f259d9e8e51 in StStartServer /softether/SoftEtherVPN/src/Cedar/Server.c:6696:12
        #9 0x7f259c848901 in UnixExecService /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2560:3
        #10 0x7f259c849566 in UnixServiceMain /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2765:3
        #11 0x7f259c84917a in UnixService /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2679:5
        #12 0x7f259c029d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/softether/asan_build/vpnserver+0xa094e) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a) in __asan_memmove
    Shadow bytes around the buggy address:
      0x0c088002cac0: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 00
      0x0c088002cad0: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 02
      0x0c088002cae0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa
      0x0c088002caf0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
      0x0c088002cb00: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
    =>0x0c088002cb10: fa fa 00 00 00 00 00[03]fa fa fd fd fd fd fd fd
      0x0c088002cb20: fa fa fd fd fd fd fd fd fa fa fa fa fa fa fa fa
      0x0c088002cb30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c088002cb40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c088002cb50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c088002cb60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
    ==89041==ABORTING
    

**VENDOR RESPONSE**

Vendor pull request on Github: https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1829

**TIMELINE**

2023-04-11 - Vendor Disclosure  
2023-04-22 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-23581: TALOS-2023-1741 || Cisco Talos Intelligence Group

Cross-Site Request Forgery (CSRF) vulnerability in OTWthemes Blog Manager Light plugin <= 1.20 versions.

**Solution**

 No fix

No patched version is available.

Found this useful? Thank Mika for reporting this vulnerability. Buy a coffee ☕

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Blog Manager Light Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-45102: WordPress Blog Manager Light plugin <= 1.20 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Jonk @ Follow me Darling Sp*tify Play Button for WordPress plugin <= 2.10 versions.

**Solution**

 No fix

No patched version is available.

BuShiYue discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Sp\*tify Play Button for WordPress Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**Other vulnerabilities in this plugin**

 1 present

 2 patched

View all

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-41131: WordPress Sp*tify Play Button for WordPress plugin <= 2.10 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Fedor Urvanov, Aram Kocharyan Urvanov Syntax Highlighter plugin <= 2.8.33 versions.

**Solution**

 No fix

No patched version is available.

Found this useful? Thank Mika for reporting this vulnerability. Buy a coffee ☕

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Urvanov Syntax Highlighter Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-45106: WordPress Urvanov Syntax Highlighter plugin <= 2.8.33 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in YAS Global Team Permalinks Customizer plugin <= 2.8.2 versions.

**Solution**

 No fix

No patched version available.

Found this useful? Thank Mika for reporting this vulnerability. Buy a coffee ☕

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Permalinks Customizer Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-45103: WordPress Permalinks Customizer plugin <= 2.8.2 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Arul Prasad J Publish Confirm Message plugin <= 1.3.1 versions.

**Solution**

 No fix

No patched version is available.

Taihei Shimamine discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Publish Confirm Message Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

Source

CVE