https://www.openwall.com/lists/oss-security/2024/07/01/3
We discovered a vulnerability (a signal handler race condition) in OpenSSH's server (sshd): if a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is called asynchronously, but this signal handler calls various functions that are not async-signal-safe (for example, syslog()). This race condition affects sshd in its default configuration.
On investigation, we realized that this vulnerability is in fact a regression of CVE-2006-5051 ("Signal handler race condition in OpenSSH before 4.4 allows remote attackers to cause a denial of service (crash), and possibly execute arbitrary code"), which was reported in 2006 by Mark Dowd.
Zerosquare (./2105) :J'ai découvert l'existence de Spiped récemment qui permet dans le cas de l'utilisation avec SSH d'ajouter une couche de sécu complémentaire en permettant d'éviter l'envoi ne serait-ce que d'un seul bit à SSH tant qu'on a pas le bon secret.https://www.openwall.com/lists/oss-security/2024/07/01/3
We discovered a vulnerability (a signal handler race condition) in OpenSSH's server (sshd): if a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is called asynchronously, but this signal handler calls various functions that are not async-signal-safe (for example, syslog()). This race condition affects sshd in its default configuration.
On investigation, we realized that this vulnerability is in fact a regression of CVE-2006-5051 ("Signal handler race condition in OpenSSH before 4.4 allows remote attackers to cause a denial of service (crash), and possibly execute arbitrary code"), which was reported in 2006 by Mark Dowd.
Cisco on Wednesday disclosed a maximum-security vulnerability that allows remote threat actors with no authentication to change the password of any user, including those of administrators with accounts, on Cisco Smart Software Manager On-Prem devices.
The Cisco Smart Software Manager On-Prem resides inside the customer premises and provides a dashboard for managing licenses for all Cisco gear in use. It’s used by customers who can’t or don’t want to manage licenses in the cloud, as is more common.
In a bulletin, Cisco warns that the product contains a vulnerability that allows hackers to change any account's password. The severity of the vulnerability, tracked as CVE-2024-20419, is rated 10, the maximum score.
“This vulnerability is due to improper implementation of the password-change process,” the Cisco bulletin stated. “An attacker could exploit this vulnerability by sending crafted HTTP requests to an affected device. A successful exploit could allow an attacker to access the web UI or API with the privileges of the compromised user.”
There are no workarounds available to mitigate the threat.
SAPwned: SAP AI vulnerabilities expose customers’ cloud environments and private AI artifacts | Wiz Blogwiz.ioWiz Research uncovers vulnerabilities in SAP AI Core, allowing malicious actors to take over the service and access customer data.
Our research into SAP AI Core began through executing legitimate AI training procedures using SAP’s infrastructure. By executing arbitrary code, we were able move laterally and take over the service – gaining access to customers’ private files, along with credentials to customers’ cloud environments: AWS, Azure, SAP HANA Cloud, and more. The vulnerabilities we found could have allowed attackers to access customers’ data and contaminate internal artifacts – spreading to related services and other customers’ environments.
Specifically, the access we gained allowed us to:
• Read and modify Docker images on SAP’s internal container registry
• Read and modify SAP’s Docker images on Google Container Registry
• Read and modify artifacts on SAP’s internal Artifactory server
• Gain cluster administrator privileges on SAP AI Core’s Kubernetes cluster
• Access customers’ cloud credentials and private AI artifacts
On Thursday, researchers from security firm Binarly revealed that Secure Boot is completely compromised on more than 200 device models sold by Acer, Dell, Gigabyte, Intel, and Supermicro. The cause: a cryptographic key underpinning Secure Boot on those models that was compromised in 2022. In a public GitHub repository committed in December of that year, someone working for multiple US-based device manufacturers published what’s known as a platform key, the cryptographic key that forms the root-of-trust anchor between the hardware device and the firmware that runs on it. The repository was located at https://github.com/raywu-aaeon/Ryzen2000_4000.git, and it's not clear when it was taken down.
The repository included the private portion of the platform key in encrypted form. The encrypted file, however, was protected by a four-character password, a decision that made it trivial for Binarly, and anyone else with even a passing curiosity, to crack the passcode and retrieve the corresponding plain text. The disclosure of the key went largely unnoticed until January 2023, when Binarly researchers found it while investigating a supply-chain incident. Now that the leak has come to light, security experts say it effectively torpedoes the security assurances offered by Secure Boot.
“It’s a big problem,” said Martin Smolár, a malware analyst specializing in rootkits who reviewed the Binarly research and spoke to me about it. “It’s basically an unlimited Secure Boot bypass for these devices that use this platform key. So until device manufacturers or OEMs provide firmware updates, anyone can basically… execute any malware or untrusted code during system boot. Of course, privileged access is required, but that’s not a problem in many cases.”
Binarly researchers said their scans of firmware images uncovered 215 devices that use the compromised key, which can be identified by the certificate serial number 55:fb:ef:87:81:23:00:84:47:17:0b:b3:cd:87:3a:f4. A table appearing at the end of this article lists each one.
The researchers soon discovered that the compromise of the key was just the beginning of a much bigger supply-chain breakdown that raises serious doubts about the integrity of Secure Boot on more than 300 additional device models from virtually all major device manufacturers. As is the case with the platform key compromised in the 2022 GitHub leak, an additional 21 platform keys contain the strings “DO NOT SHIP” or “DO NOT TRUST.”
Zeph (./2121) :Y a tant de choses que ça ?
Oh, vu la quantité de données qui doivent exister dans un lnk ça semble idiot mais plausible
GhostWrite Vulnerability Affects RISC-V CPU, Mitigating Takes A ~77% Performance Hit
Phoronix
Security researchers with the CISPA Helmholtz Center for Information Security have disclosed GhostWrite, a new CPU vulnerability affecting a common RISC-V processor.
While we are used to hearing about CPU vulnerabilities for x86/x86_64 and ARM, there's been less so for RISC-V in part since it hasn't been as big of a target for security researchers with less notable devices out in the market currently relying on RISC-V. But with more vendors exploring their own RISC-V chips and even more RISC-V single board computers coming to market that are more capable, it will become an increasing target for both security researchers and attackers.
The GhostWrite vulnerability allows unprivileged attackers to read/write to any part of the computer's memory and to be able to control peripheral devices like network adapters. The researchers note that the vulnerability cannot be fixed without disabling "around half of the CPU's functionality." GhostWrite comes down to an architectural bug and isn't a speculative execution vulnerability like we are so used to seeing these days.
The RISC-V CPU where the GhostWrite vulnerability was discovered is the T-Head XuanTie C910, which is found in various bare metal cloud instances like the previously reviewed Scaleway EM RV1 to various Lichee devices from compute clusters to gaming consoles to laptops and various RISC-V single board computers.
A critical vulnerability has been identified in the Windows TCP/IP Stack that allows for unauthenticated RCE. No user interaction is required, making this a zero-click vulnerability. This vulnerability affects all supported versions of Windows and Windows Servers.
This remote code vulnerability enables an unauthenticated attacker to repeatedly send IPv6 packets, that include specially crafted packets, to a Windows machine which could enable remote code execution. Microsoft has released urgent security patches and recommends to install these asap.
It has been assigned a CVSS score of 9.8. With a low complexity to exploit, can be performed unauthenticated and exploited remotely. Successful exploitation leads to SYSTEM level execution on the target endpoint.