Windows iSCSI Service Denial of Service Vulnerability.

CVE-2023-21527

Windows Lightweight Directory Access Protocol (LDAP) Denial of Service Vulnerability.

CVE-2023-21557

CVE-2023-21538

Internet Key Exchange (IKE) Protocol Denial of Service Vulnerability.

CVE-2023-21547

An issue in MPD (Music Player Daemon) v0.23.10 allows attackers to cause a Denial of Service (DoS) via a crafted input.

**Bug report****Describe the bug**

When sending 1. large input and 2. that would trigger the logging of an error on MPD on windows, MPD just segfaults. For instance, sending listplaylist <400 times 'A'> swiftly makes MPD segfaults.

The error probably stems from https://github.com/MusicPlayerDaemon/MPD/blob/master/src/system/Error.hxx#L94-L95 , and the fact that snprintf returns the _number of bytes which would have been written to the final string if enough space had been available_ (https://linux.die.net/man/3/snprintf), and not the number of bytes actually written.  
I think changing it by a min(return\_value, 512) would work and I'd gladly submit a PR if that's the way to go :)

It also means that it's possible to write 0x3a20 (which corresponds to the :  manually written) about anywhere on the stack, which leads to crashes when it's written to, for instance, rip, but could probably be used for more malicious purposes.

**Expected Behavior**

MPD does not crash when sent arbitrary big input.

**Actual Behavior**

MPD crashes when sent big payloads.

**Version**

    PS C:\Users\Paul\Downloads> .\mpd.exe --version
    Music Player Daemon 0.23.10 (0.23.10)
    Copyright 2003-2007 Warren Dukes <warren.dukes@gmail.com>
    Copyright 2008-2021 Max Kellermann <max.kellermann@gmail.com>
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    Database plugins:
     simple proxy
    
    Storage plugins:
     local nfs curl
    
    
    Decoders plugins:
     [vorbis] ogg oga
     [oggflac] ogg oga
     [flac] flac
     [opus] opus ogg oga
     [dsdiff] dff
     [dsf] dsf
     [hybrid_dsd] m4a
     [openmpt] mptm mod s3m xm it 669 amf ams c67 dbm digi dmf dsm dtm far imf ice j2b m15 mdl med mms mt2 mtm nst okt plm psm pt36 ptm sfx sfx2 st26 stk stm stp ult wow gdm mo3 oxm umx xpk ppm mmcmp
     [modplug] 669 amf ams dbm dfm dsm far it med mdl mod mtm mt2 okt s3m stm ult umx xm
     [wildmidi] mid
     [ffmpeg] 16sv 3g2 3gp 4xm 8svx aa3 aac ac3 adx afc aif aifc aiff al alaw amr anim apc ape asf atrac au aud avi avm2 avs bap bfi c93 cak cin cmv cpk daud dct divx dts dv dvd dxa eac3 film flac flc fli fll flx flv g726 gsm gxf iss m1v m2v m2t m2ts m4a m4b m4v mad mj2 mjpeg mjpg mka mkv mlp mm mmf mov mp+ mp1 mp2 mp3 mp4 mpc mpeg mpg mpga mpp mpu mve mvi mxf nc nsv nut nuv oga ogm ogv ogx oma ogg omg opus psp pva qcp qt r3d ra ram rl2 rm rmvb roq rpl rvc shn smk snd sol son spx str swf tak tgi tgq tgv thp ts tsp tta xa xvid uv uv2 vb vid vob voc vp6 vmd wav webm wma wmv wsaud wsvga wv wve
     [gme] ay gbs gym hes kss nsf nsfe rsn sap spc vgm vgz
     [pcm]
    
    Filters:
    
    
    Tag plugins:
    
    
    Output plugins:
     null jack httpd snapcast recorder winmm wasapi
    
    Encoder plugins:
     null vorbis opus lame wave flac
    
    Input plugins:
     file curl ffmpeg nfs
    
    Playlist plugins:
     extm3u m3u pls xspf asx rss flac cue embcue
    
    Protocols:
     http:// https:// nfs://
    
    Other features:
     ipv6 tcp
    PS C:\Users\Paul\Downloads>
    

**Configuration**

    music_directory		"C:/Users/Paul/Downloads/Music"
    playlist_directory		"C:/Users/Paul/Downloads/playlists"
    log_file			"C:/Users/Paul/Downloads/log"
    
    audio_output {
    	type		"null"
    	name		"My Null Output"
    }
    
    database {
    plugin "simple"
    path "C:/Users/Paul/Downloads/database"
    }
    

**Log**

The backtrace is misleading, since we're dealing with stack frame corruptions here, but added a few excerpts, depending on the length of the payload:

    PS C:\Users\Paul\Downloads> gdb --args mpd --stderr --no-daemon --verbose mpd.conf
    GNU gdb (GDB) (Cygwin 11.2-1) 11.2
    Copyright (C) 2022 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Type "show copying" and "show warranty" for details.
    This GDB was configured as "x86_64-pc-cygwin".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <https://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
        <http://www.gnu.org/software/gdb/documentation/>.
    
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from mpd...
    (gdb) run
    Starting program: /cygdrive/c/Users/Paul/Downloads/mpd --stderr --no-daemon --verbose mpd.conf
    [New Thread 17592.0x512c]
    [New Thread 17592.0x4248]
    [New Thread 17592.0x2140]
    warning: Invalid parameter passed to C runtime function.
    config_file: loading file mpd.conf
    warning: Invalid parameter passed to C runtime function.
    vorbis: Xiph.Org libVorbis 1.3.7
    opus: libopus 1.3.1
    hybrid_dsd: The Hybrid DSD decoder is disabled because it was not explicitly enabled
    decoder: Decoder plugin 'wildmidi' is unavailable: configuration file does not exist: /etc/timidity/timidity.cfg
    simple_db: reading DB
    curl: version 7.85.0
    curl: with Schannel
    input: Input plugin 'ffmpeg' is unavailable: No protocol
    [New Thread 17592.0x28a4]
    [New Thread 17592.0x1834]
    client: [0] opened from 192.168.0.60:15032
    client: [0] process command "listplaylist AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
    
    Thread 1 received signal SIGSEGV, Segmentation fault.
    0x0000203a560f6c54 in ?? ()
    (gdb) bt
    #0  0x0000203a560f6c54 in ?? ()
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)
    (gdb)
    

or

    (gdb) run mpd.conf
    Starting program: /cygdrive/c/Users/Paul/Downloads/mpd mpd.conf
    [New Thread 6764.0x4328]
    [New Thread 6764.0xb08]
    [New Thread 6764.0x204c]
    warning: Invalid parameter passed to C runtime function.
    warning: Invalid parameter passed to C runtime function.
    Nov 27 23:28 : decoder: Decoder plugin 'wildmidi' is unavailable: configuration file does not exist: /etc/timidity/timidity.cfg
    [New Thread 6764.0x448c]
    [New Thread 6764.0x18fc]
    
    Thread 1 received signal SIGSEGV, Segmentation fault.
    0x00007ff77f0d4166 in GetFullMessage[abi:cxx11](std::exception const&, char const*, char const*) (e=..., fallback=fallback@entry=0x7ff77f3d9be3 "Unknown exception", separator=separator@entry=0x7ff77f3d9be0 "; ") at ../../src/util/Exception.cxx:60
    60      ../../src/util/Exception.cxx: No such file or directory.
    (gdb) bt
    #0  0x00007ff77f0d4166 in GetFullMessage[abi:cxx11](std::exception const&, char const*, char const*) (e=...,
        fallback=fallback@entry=0x7ff77f3d9be3 "Unknown exception", separator=separator@entry=0x7ff77f3d9be0 "; ")
        at ../../src/util/Exception.cxx:60
    #1  0x00007ff77f0d4102 in GetFullMessage[abi:cxx11](std::__exception_ptr::exception_ptr, char const*, char const*) (
        ep=..., fallback=fallback@entry=0x7ff77f3d9be3 "Unknown exception", separator=separator@entry=0x7ff77f3d9be0 "; ")
        at ../../src/util/Exception.cxx:72
    #2  0x00007ff77f0ef783 in Log (level=level@entry=LogLevel::ERROR, ep=...) at ../../src/Log.cxx:44
    #3  0x00007ff77f0e33e8 in LogError (ep=...) at ../../src/Log.hxx:141
    #4  playlist_open_path_suffix (mutex=..., path=...) at ../../src/playlist/PlaylistStream.cxx:50
    #5  playlist_open_path (path=..., mutex=...) at ../../src/playlist/PlaylistStream.cxx:62
    #6  0x00007ff77f0e698a in playlist_open_in_playlist_dir (mutex=..., uri=0x29a3fe864f5 'A' <repeats 200 times>...)
        at ../../src/util/StringPointer.hxx:54
    #7  playlist_mapper_open (uri=0x29a3fe864f5 'A' <repeats 200 times>..., storage=0x29a416f3dc0, mutex=...)
        at ../../src/playlist/PlaylistMapper.cxx:79
    #8  0x00007ff77f0dfba9 in playlist_open_any (located_uri=..., storage=<optimized out>, mutex=...)
        at ../../src/playlist/PlaylistAny.cxx:46
    #9  0x00007ff77f0e55c9 in playlist_file_print (r=..., partition=..., loader=..., uri=..., detail=detail@entry=false)
        at ../../src/playlist/Print.cxx:71
    #10 0x00007ff77f0e4f02 in handle_listplaylist (client=..., args=..., r=...) at ../../src/client/Client.hxx:255
    #11 0x00007ff77f0d8e33 in command_process (client=..., num=num@entry=0, line=line@entry=0x29a3fe864e8 "listplaylist")
        at ../../src/command/AllCommands.cxx:432
    #12 0x00007ff77f18864d in Client::ProcessLine (this=this@entry=0x29a3fe864d0, line=<optimized out>,
        line@entry=0x29a3fe864e8 "listplaylist") at ../../src/client/Process.cxx:137
    #13 0x00007ff77f188e53 in Client::OnSocketInput (length=<optimized out>, data=0x29a3fe864e8, this=0x29a3fe864d0)
        at ../../src/client/Read.cxx:49
    #14 Client::OnSocketInput (this=0x29a3fe864d0, data=0x29a3fe864e8, length=<optimized out>)
        at ../../src/client/Read.cxx:29
    #15 0x00007ff77f129b95 in BufferedSocket::ResumeInput (this=this@entry=0x29a3fe864d0)
        at ../../src/event/BufferedSocket.cxx:76
    #16 0x00007ff77f129dc9 in BufferedSocket::OnSocketReady (this=0x29a3fe864d0, flags=<optimized out>)
        at ../../src/event/BufferedSocket.cxx:113
    #17 0x00007ff77f19c552 in EventLoop::Run (this=this@entry=0xe4983fd378) at ../../src/event/Loop.cxx:362
    #18 0x00007ff77f0f8bf3 in MainConfigured (options=..., raw_config=...) at ../../src/Main.cxx:576
    #19 0x00007ff77f0f4478 in MainOrThrow (argc=argc@entry=2, argv=argv@entry=0x29a3fe81850) at ../../src/Main.cxx:691
    #20 0x00007ff77f0f1e19 in mpd_main (argc=argc@entry=2, argv=argv@entry=0x29a3fe81850) at ../../src/Main.cxx:697
    #21 0x00007ff77f0cd60a in win32_main (argc=argc@entry=2, argv=argv@entry=0x29a3fe81850)
        at ../../src/win32/Win32Main.cxx:137
    #22 0x00007ff77f38075e in main (argc=2, argv=0x29a3fe81850) at ../../src/Main.cxx:707
    (gdb)

CVE-2022-46449: MPD crashes on windows when large input is submitted · Issue #1676 · MusicPlayerDaemon/MPD

Remote Procedure Call Runtime Denial of Service Vulnerability.

CVE-2023-21525

An out-of-bounds read in Organization Specific TLV was found in various versions of OpenvSwitch.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[<thread-prev\] \[day\] \[month\] \[year\] \[list\]

Date: Wed, 21 Dec 2022 12:10:03 +0100
From: Ilya Maximets <i.maximets@....org>
To: oss-security@...ts.openwall.com, ovs-announce@...nvswitch.org,
 ovs-discuss <ovs-discuss@...nvswitch.org>
Cc: i.maximets@....org, Aaron Conole <aconole@...hat.com>,
 Qian Chen <cq674350529@...il.com>, John Helmert III <ajak@...too.org>
Subject: Re: \[ADVISORY\] LLDP underflow while parsing malformed Auto Attach TLV
 (Open vSwitch)

On 12/20/22 22:39, Ilya Maximets wrote:
> Description
> ===========
> 
> Multiple versions of Open vSwitch are vulnerable to crafted LLDP
> packets causing denial of service, and data underflow attacks.
> Triggering the vulnerabilities requires LLDP processing to be enabled
> for a specific port.  Open vSwitch versions prior to 2.4.0 are not
> vulnerable.
> 
> The Common Vulnerabilities and Exposures project (cve.mitre.org)
> did not assign the identifier to this issue yet.  The identifier will
> be communicated separately.

Following CVE identifiers have been allocated for the issue (one per
TLV type since they can have a slightly different effect):

 - CVE-2022-4337 for Out-of-Bounds Read in Organization Specific TLV
 - CVE-2022-4338 for Integer Underflow in Organization Specific TLV

The fix referenced in this advisory covers both issues.

> This issue does not affect the \`lldpd'
> project, although they share a code base.  The issue is related to
> parsing the Auto Attach TLVs, which is specific to the Open vSwitch
> implementation.
> 
> 
> Mitigation
> ==========
> 
> For any version of Open vSwitch, preventing LLDP packets from reaching
> Open vSwitch mitigates the vulnerability.  We do not recommend
> attempting to mitigate the vulnerability this way because of the
> following difficulties:
> 
>     - Open vSwitch obtains packets before the iptables host firewall,
>       so ebtables on the Open vSwitch host cannot ordinarily block the
>       vulnerability.
> 
>     - If Open vSwitch is configured to receive and transmit LLDP
>       messages, the required functionality will need to be disabled
>       potentially disrupting the network.
> 
> We have found that Open vSwitch is subject to a denial of service, and
> possibly a remote code execution exploit when LLDP processing is enabled
> on an interface.  By default, interfaces are not configured to process
> LLDP messages.
> 
> 
> Fix
> ===
> 
> Patches to fix these vulnerabilities in Open vSwitch 2.13.x and newer are
> applied to the appropriate branches, and the original patch is located
> at:
> 
>    https://mail.openvswitch.org/pipermail/ovs-dev/2022-December/400596.html
> 
> Recommendation
> ==============
> 
> We recommend that users of Open vSwitch apply the respective patch, or
> upgrade to a known patched version of Open vSwitch.  These include:
> 
> \* 3.0.3
> \* 2.17.5
> \* 2.16.6
> \* 2.15.7
> \* 2.14.8
> \* 2.13.10
> 
> 
> Acknowledgments
> ===============
> 
> The Open vSwitch team wishes to thank the reporter:
> 
>   Qian Chen <cq674350529@...il.com>
> 

**Download attachment "**OpenPGP\_0xB9F7EC77C829BF96.asc**" of type "**application/pgp-keys**" (4740 bytes)**

**Download attachment "**OpenPGP\_signature**" of type "**application/pgp-signature**" (841 bytes)**

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2022-4337: security - Re: [ADVISORY] LLDP underflow while parsing malformed Auto Attach TLV (Open vSwitch)

A denial of service vulnerability exists in the cfg_server cm_processConnDiagPktList opcode of Asus RT-AX82U 3.0.0.4.386_49674-ge182230 router's configuration service. A specially-crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

A denial of service vulnerability exists in the cfg\_server cm\_processConnDiagPktList opcode of Asus RT-AX82U 3.0.0.4.386\_49674-ge182230 router’s configuration service. 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.

Asus RT-AX82U 3.0.0.4.386\_49674-ge182230

**PRODUCT URLS**

RT-AX82U - https://www.asus.com/us/Networking-IoT-Servers/WiFi-Routers/ASUS-Gaming-Routers/RT-AX82U/

**CVSSv3 SCORE**

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

**CWE**

CWE-125 - Out-of-bounds Read

**DETAILS**

The Asus RT-AX82U router is one of the newer Wi-Fi 6 (802.11ax)-enabled routers that also supports mesh networking with other Asus routers. Like basically every other router, it is configurable via a HTTP server running on the local network. However, it can also be configured to support remote administration and monitoring in a more IOT style.

The cfg_server and cfg_client binaries living on the Asus RT-AX82U are both used for easy configuration of a mesh network setup, which can be done with multiple Asus routers via their GUI. Interestingly though, the cfg_server binary is bound to TCP and UDP port 7788 by default, exposing some basic functionality. The TCP port and UDP ports have different opcodes, but for our sake, we’re only dealing with a particular set of ConnDiag opcodes which look like such:

    struct tlv_holder connDiagPacketHandlers = 
    {
        uint32_t type = 0x5
        tlv_func *tfunc = cm_processREQ_CHKSTA
    }
    struct tlv_holder connDiagPacketHandlers[1] = 
    {
        uint32_t type = 0x6
       tlv_func *tfunc = cm_processRSP_CHKSTA
    }
    

The above TLVs are accessible from the cm_recvUDPHandler thread in a particular codeflow:

    0001ed90      cm_recvUdpHandler()
                  // [...]
    0001edf8      int32_t bytes_read = recvfrom(sfd: cm_ctrlBlock.udp_sock, buf: &readbuf, len: 0x7ff, flags: 0, srcaddr: &sockadd, addrlen: &sockaddsize) // [1]
                    // [...]
    0001ee00      if (bytes_read == 0xffffffff)
                    // [...]
    0001ee98      else if (sockadd.sa_data[2].d != cm_ctrlBlock.self_address)
                    // [...]
    0001f0e0          char* malloc_824 = malloc(bytes: 0x824) // [2]
    0001f0e4          struct udp_resp* inp = malloc_824
    0001f0e8          if (malloc_824 != 0)
    0001f184              memset(malloc_824, 0, 0x824)        // [3]
    0001f194              memcpy(inp, &readbuf, bytes_read)
    0001f198              int32_t ipaddr = sockadd.sa_data[2].d
    0001f19c              inp->bytes_read = bytes_read
    0001f1a4              int32_t ip = ipaddr u>> 0x18 | (ipaddr u>> 0x10 & 0xff) << 8 | (ipaddr u>> 8 & 0xff) << 0x10 | (ipaddr & 0xff) << 0x18
    0001f1d4              snprintf(s: &inp->ip_addr_str, maxlen: 0x20, format: "%d.%d.%d.%d", ip u>> 0x18, ip u>> 0x10 & 0xff, ip u>> 8 & 0xff, ror.d(ip, 0) & 0xff, var_864, var_860, var_85c, var_858, var_854)
    0001f1dc              int32_t var_838_1 = readbuf[4].d
    0001f1dc              int32_t var_834_1 = readbuf[8].d
    0001f1e8              if (readbuf[0].d == 0x6000000)      // [4]
    0001f1f0                  r0_6 = cm_addConnDiagPktToList(inp: inp)
    

At \[1\], the server reads in 0x7ff bytes from its UDP 7788 port, and at \[2\] and \[3\], the data is then copied from the stack over to a cleared-out heap allocation of size 0x824. Assuming the first four bytes of the input packet are “\\x00\\x00\\x00\\x06”, then the packet gets added to a particular linked list structure, the connDiagUdpList. Before we continue on though, it’s appropriate to list out the structure of the input packet:

    struct tlv_pkt {
        uint32_t type;
        uint32_t datalen;
        uint32_t crc;
        uint8_t data[];
    }
    

Continuing on, another thread is constantly polling the connDiagUdpList, and if a packet is seen, then we jump over to cm_processConnDiagPktList():

    00053ca8  int32_t cm_processConnDiagPktList()    
    00053cc8      pthread_mutex_lock(mutex: &connDiagLock)
    00053cd8      struct list* connDiagUdp = connDiagUdpList
    00053ce8      if (connDiagUdp->entry_count s> 0)
    00053d2c          for (struct listitem* item = connDiagUdp->tail; item != 0; item = item->next)
    00053d30              struct udp_resp* input_pkt = item->inp
    00053d38              if (input_pkt != 0)
    00053d44                  uint32_t null = terminateConnDiagPktList
    00053d4c                  if (null != 0)
    00053d4c                      break
    00053d50                  uint32_t hex_6000000 = input_pkt->req_type_le
    00053d58                  uint32_t dlen = input_pkt->datalen_le
    00053d68                  int32_t dlenle = input_pkt->bytes_read - 0xc  // [5]
    00053d6c                  uint32_t crcle = input_pkt->crcle
                                // [...]
    00053d80                  if (dlenle == (dlen u>> 0x18 | (dlen u>> 0x10 & 0xff) << 8 | (dlen u>> 8 & 0xff) << 0x10 | (dlen & 0xff) << 0x18)) //[6]
    00053e0c                      char* buf = &input_pkt->readbuf
    00053e18                      crc = do_crc32(IV: null, buf: buf, bufsize: dlenle) // [7]
    

At \[5\], the actual length of the input packet minus twelve is compared against the length field inside the packet itself \[6\]. Assuming they match, the CRC is then checked, another field provided in the packet itself. A flaw is present in this function, however, in that there is a check missing in this code path that can be seen in both the TCP and UDP handlers: the code needs to verify that the size of the received packet is >= 0xC bytes. Thus, if a packet is received that is less than 0xC bytes, the dlenle field at \[5\] underflows to somewhere between 0xFFFFFFFC and 0xFFFFFFFF. The check against the length field \[6\] can be easily bypassed by just correctly putting the underflowed length inside the packet. The CRC check at \[7\] isn’t an issue, since if the bufsize parameter is less than zero, it automatically skips CRC calculation. Since a CRC skip results in a return value of 0x0, we need to make sure that the crc field is “\\x00\\x00\\x00\\x00”. Conveniently, this is handled already for us if our packet is only 8 bytes long, since the buffer that the packet lives in was memset to 0x0 beforehand.

While we can pass all the above checks with an 8-byte packet, it does prevent us from having any control over what occurs after. We end up hitting cm_processConnDiagPkt(uint32_t tlv_type, uint32_t datalen, uint32_t crc, char *databuf, char *ipaddr) which just passes us off to the appropriate TLV handler. Since our opcode has to be “\\x00\\x00\\x00\\x06”, we always hit cm_processRSP_CHKSTA(char *pktbuf, uint32_t pktlen, uint32_t ipaddr):

    00052f20  int32_t cm_processRSP_CHKSTA(char* pktbuf, uint32_t pktlen, int32_t ipaddr)
    00052f50      char jsonbuf[0x800]
    00052f50      memset(&jsonbuf, 0, 0x800)
                                 // [...]
    00052f64      if (cm_ctrlBlock.group_key_ready != 0)
    00053004          char* groupkey = cm_selectGroupKey(which_key: 1)
    0005300c          if (groupkey == 0)
                                                  // [...]
    00053098              goto label_530a0
    000530c0          char* r0_11 = do_decrypt(sesskey1: groupkey, sesskey2: cm_selectGroupKey(which_key: 0), pktbuf: pktbuf, pktlen: pktlen) //[8]
    

Assuming there is a group key (which there should always be, even if the AImesh setting is not configured), then we end up hitting the do_decrypt function at \[8\], which decrypts the data of our input packet with one of the groupkeys. The do_decrypt function ends up hitting aes_decrypt as shown below:

    0001db18  void* aes_decrypt(char* sesskey1, char* pktbuf, char* pktlen, int32_t* outlen)
    0001db30      int32_t ctx = EVP_CIPHER_CTX_new()
    0001db38      int32_t outl = 0
    0001db3c      void* ctx = ctx
    0001db40      void* ret
    0001db40      if (ctx == 0)
                                        // [...]
    0001db6c      else
    0001db6c          char* bytesleft = nullptr
    0001db7c          int32_t r0_2 = EVP_DecryptInit_ex(ctx, EVP_aes_256_ecb(), 0, sesskey1, 0)
                                         // [...]
    0001db84          if (r0_2 != 0)
    0001dba0              *outlen = 0
    0001dbac              void* alloc_size = EVP_CIPHER_CTX_block_size(ctx) + pktlen
    0001dbb4              maloced = malloc(bytes: alloc_size)  // 0xc...
    0001dbbc              if (maloced == 0)
                                                         //[...]
    0001dbe4              else
    0001dbe4                  memset(maloced, 0, alloc_size)
    0001dbec                  void* mbuf = maloced
    0001dbf0                  char* pktiter = pktlen
    0001dc00                  void* inpbuf
    0001dc00                  void* r3_2
    0001dc00                  while (true)
    0001dc00                      inpbuf = &pktbuf[pktlen - pktiter]
    0001dc04                      if (pktiter u<= 0x10)
    0001dc04                          break
    0001dc10                      bytesleft = 0x10
    0001dc1c                      int32_t r0_8 = EVP_DecryptUpdate(ctx, mbuf, &outl, inpbuf, 0x10) //[9]
    0001dc20                      r3_2 = r0_8
    0001dc24                      if (r0_8 == 0)
    0001dc24                          break
    0001dc60                      int32_t outl_len = outl
    0001dc64                      pktiter = pktiter - 0x10
    0001dc6c                      mbuf = mbuf + outl_len
    0001dc74                      *outlen = *outlen + outl_len
    

For brevity’s sake, we can skip all the way to \[9\], where EVP_DecryptUpdate is called repeatedly in a loop over the input buffer. Since the pktlen argument has been underflowed to atleast 0xFFFFFFFC, it suffices to say that we have a wild read, resulting in a crash when reading unmapped memory.

**Crash Information**

    potentially unexpected fatal signal 11.
    CPU: 1 PID: 12452 Comm: cfg_server Tainted: P           O    4.1.52 #2
    Hardware name: Generic DT based system
    task: d04cd800 ti: d0632000 task.ti: d0632000
    PC is at 0xb6c7f460
    LR is at 0xb6d3ca04
    pc : [<b6c7f460>]    lr : [<b6d3ca04>]    psr: 60070010
    sp : b677c46c  ip : 00ff4ff4  fp : b6600670
    r10: b6c7ef40  r9 : 00000000  r8 : beec0b82
    r7 : b6600670  r6 : 00000010  r5 : b6620c38  r4 : 00ff5004
    r3 : b6c7f440  r2 : 00000000  r1 : 00000000  r0 : 00000000
    Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
    Control: 10c5387d  Table: 1048c04a  DAC: 00000015
    CPU: 1 PID: 12452 Comm: cfg_server Tainted: P           O    4.1.52 #2
    Hardware name: Generic DT based system
    [<c0026fe0>] (unwind_backtrace) from [<c0022c38>] (show_stack+0x10/0x14)
    [<c0022c38>] (show_stack) from [<c047f89c>] (dump_stack+0x8c/0xa0)
    [<c047f89c>] (dump_stack) from [<c003ac30>] (get_signal+0x490/0x558)
    [<c003ac30>] (get_signal) from [<c00221d0>] (do_signal+0xc8/0x3ac)
    [<c00221d0>] (do_signal) from [<c0022658>] (do_work_pending+0x94/0xa4)
    [<c0022658>] (do_work_pending) from [<c001f4cc>] (work_pending+0xc/0x20)
    

**TIMELINE**

2022-08-24 - Vendor Disclosure  
2022-11-16 - Vendor Patch Release  
2023-01-10 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-38393: TALOS-2022-1592 || Cisco Talos Intelligence Group

The cryptomining malware, which typically targets Linux, is exploiting weaknesses in an open source container tool for initial access to cloud environments.

A malware that typically targets Linux environments for cryptocurrency mining has found a new target: vulnerable images and weakly configured PostgreSQL containers in Kubernetes that can be exploited for initial access, Microsoft has found.

Kinsing is a Golang-based malware best known for its targeting of Linux environments, but Microsoft researchers recently observed the Kinsing malware evolving its tactics, Microsoft security researcher Sunders Bruskin divulged in a recently published report. 

Kubernetes, meanwhile, has become the standard open source tool for managing enterprise application deployment mainly because it's cost-effective, offers autoscaling, and can run on any infrastructure. Indeed, 85% of IT leaders consider Kubernetes "extremely important" to cloud-native strategies.

That Kinsing would begin to find new ways to exploit Kubernetes clusters is on brand for the malware, especially because Kubernetes, like the cloud itself, is notoriously difficult to secure. Attackers have found multiple holes in Kubernetes — including the discovery of more than 380,000 open Kubernetes API servers exposed on the Internet — that have made it open season on cloud environments that use the management platform. Threat actors are even using compromised Kubernetes clusters to launch further malicious attacks.

"Exposing the cluster to the Internet without proper security measures can leave it open to attack from external sources," Bruskin acknowledged in the post.

**Targeting Vulnerable Container Images**

One of the new ways Kinsing is targeting Kubernetes environments is by targeting images that are vulnerable to remote code execution (RCE), the researchers found. This allows attackers with network access to exploit the container and run their malicious payload, they said.

In their observations, Microsoft researchers observed several application images frequently infected with Kinsing malware, including PHPUnit, Liferay, Oracle WebLogic, and WordPress, Bruskin wrote.

A series of high-severity vulnerabilities in WebLogic that Oracle revealed in 2020 — CVE-2020-14882, CVE-2020-14750, and CVE-2020-14883 — have become particular targets of attackers wielding the Kinsing malware, which goes after unpatched WebLogic server images, researchers said.

Attacks begin with scanning of a wide range of IP addresses, looking for an open port that matches the WebLogic default port (7001), Bruskin revealed.

"If vulnerable, attackers can use one of the exploits to run their malicious payload (Kinsing, in this case)," he wrote, using a malicious command.

**PostgreSQL in the Crosshairs**

Microsoft researchers also recently observed a significant amount of Kubernetes clusters running PostgreSQL containers that were infected with Kinsing. They attributed the infections to attackers targeting several common misconfigurations that expose these servers, they said.

One is to use the "trust authentication" setting to configure these containers, which means PostgreSQL will assume that anyone who can connect to the server is authorized to access the database with whatever database user name they specify.  
"However, in some cases, this range is wider than it should be or even accepts connections from any IP address (i.e. 0.0.0.0/0)," Bruskin explained in the post. "In such configurations, attackers can freely connect to the PostgreSQL servers without authentication, which may lead to code execution."

Some network configurations in Kubernetes also are prone to Address Resolution Protocol (ARP) poisoning, which allows attackers to impersonate applications in the cluster. This means that even specifying a private IP address in the "trust" configuration may pose a security risk, the researchers said. ARP is the process of connecting a dynamic IP address to a physical machine's MAC address.

Indeed, as a general rule, configuring a PostgreSQL container to allow access to a broad range of IP addresses is exposing it to a potential threat, Bruskin warned.

Even if administrators don't configure it using an unsecured "trust authentication" method, attackers can brute-force PostgreSQL accounts, use denial-of-service (DoS) or distributed DoS (DDoS) attackers on the container's availability, or exploit the container and the database itself to compromise Kubernetes clusters, he wrote.

**Protecting the Enterprise Cloud**

Researchers offered both general rules of thumb for enterprises implementing Kubernetes environments and specific mitigations to avoid exposing them to attacks that target vulnerable images and common PostgreSQL misconfigurations.

In general, security teams must remain aware of exposed containers and vulnerable images and try to mitigate the risk before they are breached, Bruskin advised.

"Regularly updating images and secure configurations can be a game changer for a company when trying to be as protected as possible from security breaches and risky exposure," he wrote.

To mitigate the risk of implementing containers with vulnerable images, organizations can take several steps when deploying an image to the container, the researchers said. The first is to ensure that the image is from a known registry and that it's been patched and updated to the latest version, they said.

Organizations should also scan all images for vulnerabilities, identifying which ones are vulnerable and what those vulnerabilities are, especially the ones that are used in exposed containers. Finally, the researchers said, minimizing access to the container by assigning access to specific IPs and applying the "least privileges" rule to the user can also prevent attackers from exploiting vulnerable images in Kubernetes environments.

Microsoft: Kinsing Targets Kubernetes via Containers, PostgreSQL

Lilith >_> of Cisco Talos discovered these vulnerabilities.
Cisco Talos recently discovered three vulnerabilities in Asus router software.
The Asus RT-AX82U router is one of the newer Wi-Fi 6 (802.11ax)-enabled routers that also supports mesh networking with other Asus routers. Like other routers, it is configurable via

Tuesday, January 10, 2023 11:01

_Lilith >\_> of Cisco Talos discovered these vulnerabilities._

Cisco Talos recently discovered three vulnerabilities in Asus router software.

The Asus RT-AX82U router is one of the newer Wi-Fi 6 (802.11ax)-enabled routers that also supports mesh networking with other Asus routers. Like other routers, it is configurable via an HTTP server running on the local network. However, it can also be configured to support remote administration and monitoring in more of an IOT style.

Talos has identified TALOS-2022-1586 (CVE-2022-35401), an authentication bypass vulnerability that can lead to full administrative privileges. An attacker would need to send a series of HTTP requests to exploit this vulnerability.

TALOS-2022-1590 (CVE-2022-38105) is an information disclosure vulnerability in the opcode of the router’s configuration service that can lead to a disclosure of sensitive information. An attacker can send a network request to trigger this vulnerability.

TALOS-2022-1592 (CVE-2022-38393) is a denial of service vulnerability, also in the opcode of the configuration service. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

Cisco Talos worked with Asus to ensure that these issues were resolved and an update is available for affected customers, all in adherence to Cisco’s vulnerability disclosure policy.

Users are encouraged to update this affected product as soon as possible: Asus RT-AX82U 3.0.0.4.386\_49674-ge182230. Talos tested and confirmed this version of Asus could be exploited by these vulnerabilities.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 60394 and 60473. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org.

Tag

#dos