Hd Moore

The root-privileged `wsserver` terminal-bridge daemon allows a connected client to execute arbitrary commands on the appliance as root. This occurs because the daemon constructs a shell command using client-supplied WebSocket fields and passes it to the `system()` and `popen()` functions without proper quoting, escaping, or character-set validation. Additionally, the daemon's public-key session path does not perform an appliance-session check.

The software verifies the RSA signature of a firmware image using a public key stored in the `/conf/public.pem` file. An authenticated Redfish client with `firmware-update` privileges can overwrite this file via the `UpdateService.UploadSignKey` action, as the system only validates that the filename ends in `.pem`. This allows an attacker to replace the trust anchor with a custom key and subsequently install a malicious firmware image signed with the corresponding private key. The system lacks a hardware root-of-trust, such as Platform Firmware Resilience (PFR), to detect the key substitution.

The device-management process in openUBMC improperly handles PLDM-over-MCTP and NCSI-over-MCTP responses from on-bus devices. Three response parsers within the shared transport libraries subtract a fixed header or reserved-field size from a response length provided by the device without performing a lower-bound check. If a response is undersized, the unsigned length difference wraps to a very large value, causing the parser to read memory far beyond the response buffer. This issue affects the base PLDM control class and the Huawei NCSI driver, making it reachable via any PLDM endpoint or Huawei NIC on the internal management bus.

The software assigns a full privilege set to pseudo-identities used by SNMP callers. This allows an authenticated user with low privileges to execute mapped backend operations with administrative authority. The issue occurs in `route mapper/account.lua` within the `get user privilege()` function, which returns a complete nine-privilege set for the `special users` group, including the `SNMPv1 v2c` pseudo-user.

openUBMC ships with a default SNMPv3 USM key that utilizes a single value for both authentication and privacy. Because these keys are constants within the open-source build and not unique per unit, an attacker can recover them to authenticate SNMPv3 requests and decrypt traffic. The issue involves the `AuthenticationKey` and `EncryptionKey` variables defined in the `manifest/build/customization/default password.lua` and `account/manufacture/default password.lua` files. These keys are not rotated during Administrator password resets, allowing them to persist after account provisioning. Since SNMP access is mapped to full device administration privileges, this could allow unauthorized system resets and firmware upgrades.

A logic flaw in the IPMI implementation allows an unauthenticated client to force the RAKP Message 1 handler to return before the authentication object's constructor defaults are overwritten. Consequently, the IPMI service accepts a RAKP Message 3 where the HMAC is calculated using a predictable `bmcRandomNum` and a constant 20-byte `userKey` initialized as '0penBmc'. This issue affects OpenBMC and downstream vendors using phosphor-net-ipmid as their IPMI stack, including NVIDIA and H3C.

A logic flaw in the IPMI implementation of OpenBMC allows the authorization context of an active session to be replaced with a target account. This occurs while the original integrity and encryption keys remain active, enabling privilege escalation without the need for re-authentication. This implementation is used by several downstream vendors, including NVIDIA and H3C.

An issue exists when using GPT scanning with `FF LBA64 = 1` where an unbounded loop count is derived from the GPT header field `GPTH PtNum`. This can lead to extremely long or effectively infinite scans during the mount-time process, resulting in a loop with an unreachable exit condition.

A divide-by-zero issue exists in the exFAT sync logic. This occurs during write or sync operations when crafted metadata causes the calculation `n fatent - 2` to result in zero. Divide-by-zero is a condition where a program attempts to divide a number by zero, which typically leads to a system crash or application failure.

An integer overflow occurs in the `mount volume()` function during FAT32 processing when the operation `fasize *= fs->n fats` wraps. This allows an attacker to control file-size metadata, resulting in unsafe read lengths for downstream callers. This issue can be exploited via crafted FAT images on USB sticks or SD cards to achieve arbitrary code execution on embedded devices, including those using ESP-IDF, STM32Cube, Zephyr, and ArduPilot. Additionally, remote delivery is possible through OTA or update pipelines. Real-world exploitation has been demonstrated on a camera device.

An issue exists in the handling of long filenames when LFN (Long File Name) is enabled. The `fno.fname` variable can reach up to 255 characters, and many callers copy this data into short fixed buffers without performing bounds checks, leading to a buffer overflow. A buffer overflow occurs when a program writes more data to a block of memory than it is allocated to hold.

An uninitialized cluster exposure occurs when the `f lseek()` function extends files beyond the end-of-file (EOF) without zero-filling newly allocated clusters. This issue is a Use of Uninitialized Resource, where the system fails to clear memory or storage before use, potentially exposing sensitive data previously stored in those clusters.

A stack-based buffer overflow occurs in the `f getlabel()` function. This issue arises because the exFAT label length `XDIR NumLabel` is trusted without enforcing the maximum limits defined by the specification.

An integer underflow occurs during interleaved read and write operations on fragmented filesystems. This issue is caused by an unsigned-subtraction wrap in the `f read()` and `f write()` functions when evaluating the condition `fp->sect - sect < cc`, which leads to a stale dirty-cache skip.

An attacker can gain access to a restricted shell on an unconfigured Abilis CPX device by repeatedly failing to authenticate via SSH. Specifically, after three unsuccessful authentication attempts, a fourth attempt allows login and enables connection relaying. This occurs because the device does not properly handle repeated failed login attempts.

The affected Raisecom devices permit the establishment of SSH sessions without requiring user authentication. This could enable attackers to obtain shell access without legitimate credentials. The issue affects industrial and telecommunications equipment.

The issue is related to insufficient input validation for a specific command in the implementation of a CLI command, which could allow an authenticated, local attacker to overwrite files in the flash memory of the device. An attacker could exploit this by issuing a command with crafted arguments, potentially allowing them to overwrite or create files with data already present in other files hosted on the affected device.

A vulnerability in the multicast DNS (mDNS) protocol configuration could allow an unauthenticated adjacent attacker to obtain sensitive information about the device on which the Webex client is running. The vulnerability exists because sensitive information is included in the mDNS reply. An attacker could exploit this vulnerability by doing an mDNS query for a particular service against an affected device. A successful exploit could allow the attacker to gain access to sensitive information.

The issue concerns a default SSH public key in the authorized keys file for the `mateidu` user. This allows remote attackers to gain SSH access if they have knowledge of the private key.

The issue is related to weaknesses in the authentication procedure of the ScreenOS operating system. This allows a remote attacker to gain administrative access by entering a specially crafted password during an SSH or TELNET session.