CWE-354

In ILIAS through 7.10, lack of verification when changing an email address (on the Profile Page) allows remote attackers to take over accounts.

Honeywell Experion PKS Safety Manager 5.02 has Insufficient Verification of Data Authenticity. According to FSCT-2022-0054, there is a Honeywell Experion PKS Safety Manager unauthenticated firmware update issue. The affected components are characterized as: Firmware update functionality. The potential impact is: Firmware manipulation. The Honeywell Experion PKS Safety Manager utilizes the DCOM-232/485 communication FTA serial interface and Enea POLO bootloader for firmware management purposes. An engineering workstation running the Safety Builder software communicates via serial or serial-over-ethernet link with the DCOM-232/485 interface. Firmware images were found to have no authentication (in the form of firmware signing) and only relied on insecure checksums for regular integrity checks. Firmware images are unsigned. An attacker with access to the serial interface (either through physical access, a compromised EWS or an exposed serial-to-ethernet gateway) can utilize hardcoded credentials (see FSCT-2022-0052) for the POLO bootloader to control the boot process and push malicious firmware images to the controller allowing for firmware manipulation, remote code execution and denial of service impacts. A mitigating factor is that in order for a firmware update to be initiated, the Safety Manager has to be rebooted which is typically done by means of physical controls on the Safety Manager itself. As such, an attacker would have to either lay dormant until a legitimate reboot occurs or possibly attempt to force a reboot through a secondary vulnerability.

On various RAD-ISM-900-EN-* devices by PHOENIX CONTACT an admin user could use the configuration file uploader in the WebUI to execute arbitrary code with root privileges on the OS due to an improper validation of an integrity check value in all versions of the firmware.

An issue was discovered in Qualys Cloud Agent 4.8.0-49. It executes programs at various full pathnames without first making ownership and permission checks (e.g., to help ensure that a program was installed by root) and without integrity checks (e.g., a checksum comparison against known legitimate programs). Also, the vendor recommendation is to install this agent software with root privileges. Thus, privilege escalation is possible on systems where any of these pathnames is controlled by a non-root user. An example is /opt/firebird/bin/isql, where the /opt/firebird directory is often owned by the firebird user.

go-tuf is a Go implementation of The Update Framework (TUF). go-tuf does not correctly implement the client workflow for updating the metadata files for roles other than the root role. Specifically, checks for rollback attacks are not implemented correctly meaning an attacker can cause clients to install software that is older than the software which the client previously knew to be available, and may include software with known vulnerabilities. In more detail, the client code of go-tuf has several issues in regards to preventing rollback attacks: 1. It does not take into account the content of any previously trusted metadata, if available, before proceeding with updating roles other than the root role (i.e., steps 5.4.3.1 and 5.5.5 of the detailed client workflow). This means that any form of version verification done on the newly-downloaded metadata is made using the default value of zero, which always passes. 2. For both timestamp and snapshot roles, go-tuf saves these metadata files as trusted before verifying if the version of the metafiles they refer to is correct (i.e., steps 5.5.4 and 5.6.4 of the detailed client workflow). A fix is available in version 0.3.0 or newer. No workarounds are known for this issue apart from upgrading.