#java

### Summary OpenMage is affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by a low-privileged attacker to inject malicious scripts into vulnerable form fields. ### Details `Mage_Adminhtml_Block_System_Config_Form_Field_File` does not escape filename value in certain situations. Same as: https://nvd.nist.gov/vuln/detail/CVE-2024-20717 ### PoC 1. Create empty file with this filename: `<img src=x onerror=alert(1)>.crt` 2. Go to _System_ > _Configuration_ > _Sales | Payment Methonds_. 3. Click **Configure** on _PayPal Express Checkout_. 4. Choose **API Certificate** from dropdown _API Authentication Methods_. 5. Choose the XSS-file and click **Save Config**. 6. Profit, alerts "1" -> XSS. 7. Reload, alerts "1" -> Stored XSS. ### Impact Affects admins that have access to any fileupload field in admin in core or custom implementations. Malicious JavaScript may be executed in a victim’s browser when they browse to the page containing the vulnerable field.

XML External Entity injection in Apache Ambari versions <= 2.7.7, Users are recommended to upgrade to version 2.7.8, which fixes this issue. More Details: Oozie Workflow Scheduler had a vulnerability that allowed for root-level file reading and privilege escalation from low-privilege users. The vulnerability was caused through lack of proper user input validation. This vulnerability is known as an XML External Entity (XXE) injection attack. Attackers can exploit XXE vulnerabilities to read arbitrary files on the server, including sensitive system files. In theory, it might be possible to use this to escalate privileges.

Improper input validation allows for header injection in MIME4J library when using MIME4J DOM for composing message. This can be exploited by an attacker to add unintended headers to MIME messages.

Ubuntu Security Notice 6662-1 - Yi Yang discovered that the Hotspot component of OpenJDK 21 incorrectly handled array accesses in the C1 compiler. An attacker could possibly use this issue to cause a denial of service, execute arbitrary code or bypass Java sandbox restrictions. It was discovered that the Hotspot component of OpenJDK 21 did not properly verify bytecode in certain situations. An attacker could possibly use this issue to bypass Java sandbox restrictions.

Ubuntu Security Notice 6661-1 - Yi Yang discovered that the Hotspot component of OpenJDK 17 incorrectly handled array accesses in the C1 compiler. An attacker could possibly use this issue to cause a denial of service, execute arbitrary code or bypass Java sandbox restrictions. It was discovered that the Hotspot component of OpenJDK 17 did not properly verify bytecode in certain situations. An attacker could possibly use this issue to bypass Java sandbox restrictions.

Ubuntu Security Notice 6660-1 - Yi Yang discovered that the Hotspot component of OpenJDK 11 incorrectly handled array accesses in the C1 compiler. An attacker could possibly use this issue to cause a denial of service, execute arbitrary code or bypass Java sandbox restrictions. It was discovered that the Hotspot component of OpenJDK 11 did not properly verify bytecode in certain situations. An attacker could possibly use this issue to bypass Java sandbox restrictions.

Talos has observed a phishing spam campaign targeting potential victims in Mexico, luring users to download a new obfuscated information stealer we’re calling TimbreStealer, which has been active since at least November 2023.

Apache James prior to version 3.7.5 and 3.8.0 exposes a JMX endpoint on localhost subject to pre-authentication deserialisation of untrusted data. Given a deserialisation gadjet, this could be leveraged as part of an exploit chain that could result in privilege escalation. Note that by default JMX endpoint is only bound locally. We recommend users to:  - Upgrade to a non-vulnerable Apache James version  - Run Apache James isolated from other processes (docker - dedicated virtual machine)  - If possible turn off JMX

### Impact When SAML is used as the authentication mechanism, Central Dogma accepts unsigned SAML messages (assertions, logout requests, etc.) as they are, rather than rejecting them by default. As a result, an attacker can forge a SAML message to authenticate themselves, despite the fact that such an unsigned SAML message should be rejected. ### Patches The vulnerability has been patched in Central Dogma 0.64.3 by updating its Armeria dependency to 1.27.2. All users who use SAML as the authentication mechanism must upgrade from 0.64.3 or later. ### Workarounds A user can manually upgrade the `armeria-saml` module with the one from Armeria 1.27.2 or later, either by replacing the JAR in the Central Dogma distribution or by updating the dependency tree of the build. ### References [`SamlMessageUtil.validateSignature()`](https://github.com/line/armeria/blob/0efc776988d71be4da6e506ec8a33c2b7b43f567/saml/src/main/java/com/linecorp/armeria/server/saml/SamlMessageUtil.java#L160-L163)

### Impact The SAML implementation provided by `armeria-saml` currently accepts unsigned SAML messages (assertions, logout requests, etc.) as they are, rather than rejecting them by default. As a result, an attacker can forge a SAML message to authenticate themselves, despite the fact that such an unsigned SAML message should be rejected. ### Patches The vulnerability has been patched in Armeria version 1.27.2. All users who rely on `armeria-saml` older than version 1.27.2 must upgrade to 1.27.2 or later. ### Workarounds There is no known workaround for this vulnerability. ### References [`SamlMessageUtil.validateSignature()`](https://github.com/line/armeria/blob/0efc776988d71be4da6e506ec8a33c2b7b43f567/saml/src/main/java/com/linecorp/armeria/server/saml/SamlMessageUtil.java#L160-L163)