Source
ghsa
The p2p discovery protocol assumes that the peer IP must be valid IPv4 address.
The P2P protocols lack of rate limit. For example, in relay protocol, when a node receives a broadcasted `tx_hashes`, it will mark it in memory to avoid duplicated requests. [code → ](https://github.com/nervosnetwork/ckb/blob/26e4837212c392c3c706a0da7a056131fb060433/sync/src/relayer/transactions_process.rs#L67). It is easy to establish a DoS attach by generating random tx hashes. ### Impact It affects all nodes connected to the P2P network. ### Workarounds Apply rate limit on the data sent to CKB P2P port.
# Microsoft Security Advisory CVE-2020-0605: .NET Framework Remote Code Execution Vulnerability ## Executive Summary A remote code execution vulnerability exists in .NET software when the software fails to check the source markup of a file. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. Exploitation of the vulnerability requires that a user open a specially crafted file with an affected version of .NET Framework. In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to t...
via [email protected] There are multiple type conversions in ckb that unsafely cast between byte pointers and other types of pointers. This results in unaligned pointers, which are not allowed by the Rust language, and are considered undefined behavior, meaning that the compiler is free to do anything with code. This can lead to unpredictable bugs that can become security vulnerabilities. Some of the bugs here could potentially lead to buffer overreads in malformed data (it's not clear to me as I haven't investigated the practical impact of these bugs). Two of these (in blockchain.rs) do not create unaligned data. They do though perform an unsafe operation that may not uphold the invariants of the safe function they are in, and could lead to undefined behavior and buffer overreads on malformed input. These are of the same nature as those in my previous report about the molecule crate. Patch attached for commit 1b09e37c8e1b7945495cd18d9782417fbe51e986 that fixes all cases I know of...
### Impact Arbitrary local file inclusion via the `$lang` property, remotely exploitable if host application passes unfiltered user data into that property. The 3 CVEs listed are applications that used PHPMailer that were vulnerable to this problem. ### Patches It's not known exactly when this was fixed in the host applications, but it was fixed in PHPMailer 5.2.0. ### Workarounds Filter and validate user-supplied data before use. ### References https://nvd.nist.gov/vuln/detail/CVE-2006-5734 https://nvd.nist.gov/vuln/detail/CVE-2007-3215 https://nvd.nist.gov/vuln/detail/CVE-2007-2021 Example exploit: https://www.exploit-db.com/exploits/14893 ### For more information If you have any questions or comments about this advisory: * Open a private issue in [the PHPMailer project](https://github.com/PHPMailer/PHPMailer)
PHPMailer before 1.7.4, when configured to use sendmail, allows remote attackers to execute arbitrary shell commands via shell metacharacters in the SendmailSend function in `class.phpmailer.php`. ### Impact Shell command injection, remotely exploitable if host application does not filter user data appropriately. ### Patches Fixed in 1.7.4 ### Workarounds Filter and validate user-supplied data before putting in the into the `Sender` property. ### References https://nvd.nist.gov/vuln/detail/CVE-2007-3215 ### For more information If you have any questions or comments about this advisory: * Open a private issue in [the PHPMailer project](https://github.com/PHPMailer/PHPMailer)
Ylianst MeshCentral 1.1.16 suffers from Use of a Broken or Risky Cryptographic Algorithm.
### Impact Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626. ### Patches `runc` runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4. ### Workarounds Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability. ### References * [CVE-2024-21626](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv) * [Vulnerability: runc process.cwd and leaked fds container breakout](https://snyk.io/blog/cve-2024-21626-runc-process-cwd-container-breakout/)
## Summary When calls to external contracts are made, we write the input buffer starting at byte 28, and allocate the return buffer to start at byte 0 (overlapping with the input buffer). When checking `RETURNDATASIZE` for dynamic types, the size is compared only to the minimum allowed size for that type, and not to the returned value's `length`. As a result, malformed return data can cause the contract to mistake data from the input buffer for returndata. This advisory is given a severity of "Low" because when the called contract returns invalid ABIv2 encoded data, the calling contract can read different invalid data (from the dirty buffer) than the called contract returned. ## Details When arguments are packed for an external call, we create a buffer of size `max(args, return_data) + 32`. The input buffer is placed in this buffer (starting at byte 28), and the return buffer is allocated to start at byte 0. The assumption is that we can reuse the memory becase we will not be able ...
# Impact There is a potential for a mutation XSS (mXSS) vulnerability in AntiSamy caused by flawed parsing of the HTML being sanitized. To be subject to this vulnerability the `preserveComments` directive must be enabled in your policy file. As a result, certain crafty inputs can result in elements in comment tags being interpreted as executable when using AntiSamy's sanitized output. # Patches Patched in AntiSamy 1.7.5 and later. This is due to parsing behavior in the [neko-htmlunit](https://github.com/HtmlUnit/htmlunit-neko) dependency, just by updating to a newer version the issue was solved. See important remediation details in the reference given below. # Workarounds If you cannot upgrade to a fixed version of the library, the following mitigation can be applied until you can upgrade: Manually edit your AntiSamy policy file (e.g., antisamy.xml) by deleting the `preserveComments` directive or setting its value to `false`, if present. As the previously mentioned policy settin...