There’s a Gitlab vulnerability that you should probably pay attention to. Tracked as CVE-2023-7028, this issue allows an attacker to specify a secondary email during a the password reset request. Only one email has to match the one on record, but the password reset link gets sent to both emails. Yikes!
What makes this worse is there is already a Proof of Concept (PoC) released, and it’s a trivial flaw. In an HTTP/S post containing the password reset request, just include two email addresses. Thankfully, a fix is already out. Versions 16.7.2, 16.6.4, and 16.5.6 contain this patch, as well as fixes for a flaw that allowed sneaking unauthorized changes into a previously approved merge request, and an issue with Slack and Mattermost where slash commands could be spoofed.
VMWARE
We don’t want to over-dramatise this vulnerability, but VMware is calling it an emergency. This one affects VMware vRealize and Aria Automation. According to the the CVSS calculator, it’s a low complexity network flaw, but does require at least some privileges. Hopefully more information will come out about this vulnerability, but for now that’s about all we know.
IPV6 IS A WHOLE NEW WORLD (OF VULNERABILITIES)
The Open Source Tianocore project is the reference implementation of UEFI, and ends up being the upstream of pretty much every UEFI firmware. Tianocore implements PXE (“pixie”) booting, the mechanism for booting a machine from a network disk image. For the last few years, Tianocore has had IPv6 support for PXE boot, and it turns out that new-ish stack has some problems.
PXE Boot is fairly straightforward, but actually ends up needing quite a few features. DHCP, DNS, and Neighbor Discovery, to name a few. And because it’s low-level firmware code, most of those features are written from scratch for Tianocore. And of course, there are problems. To start, in handling a DHCPv6 Advertise message, a malicious option can trigger an integer underflow. Similarly, a very long server ID value sent in a DHCP Advertise can overflow the assigned buffer, leading to arbitrary memory write.
Additionally, there are a pair of infinite loops that can cause Denial of Service during boot, another pair of buffer overflows in DHCP, and some general weaknesses in random number generation. Many of these issues are considered severe. What’s noticeably lacking here is patches and updated firmwares from all the vendors that take Tianocore as their upstream. Looking at the disclosure timeline from Quarkslab, there seems to have been quite a fight over how long to keep the problems embargoed.
IVANTI EXAMINED
Last week we warned you about a new pair of Ivanti vulnerabilities. This week we’re back with The watchTowr Labs investigation into the mitigation. There’s some fun tidbits in here, like how to get to the raw unencrypted filesystem to find the changes made by the workaround. You can switch up the kernel boot command to simply run /bin/sh. Except the Ivanti kernel has a string compare for exactly that init command. The solution? //bin//sh
The key turns out to be the REST API, with multiple endpoints blocked with the XML update. This just happens to make it trivial to detect whether an Ivanti device has the mitigation installed. Now remember, this is just a mitigation, and the full patch is still a few days away from the start of a staggered roll-out. With that in mind, watchTowr has opted not to disclose the actual vulnerabilities yet.
TAKING THE MIRTH OUT OF DESERIALIZATION
The Mirth Connect platform is used to connect various Electronic Health Record systems, and back in October it was patched to fix an unauthenticated RCE. Now we have the whole story: it was a botched fix for an earlier vulnerability. Mirth Connect is a Java project, and as such it can be subject to deserialization problems. This one was an “unmarshalling” issue, which is taking XML data and converting to Java data objects.
The sign that something may have been wrong with the earlier fix was the claim that the problem was limited to Java 8. The previous solution was a limited list of class names that were blocked during unmarshaling, and the workaround was simply to find a missed class that was subject to exploit. A proper fix has landed, now using a list of allowed classes instead.
BITS AND BYTES
Cacti has a pair of vulnerabilities, that allow an authenticated user to execute arbitrary code. The first is a SQL injection, where a request to save settings takes a parameter that isn’t properly sanitized, and doesn’t properly use a prepared statement. Then a second flaw is to write shellcode to the cacti log, and trick the system into attempting to execute that file. Look to Cacti 1.2.26 for fixes.
Atlassian has released details on 28 high-severity vulnerabilities in Bitbucket, Bamboo, Jira, Crowd, and Confluence. Many of those are RCEs and other serious problems, so if yours is an Atlassian shop, it’s time to update.
Nvidia has sent out the warning, don’t put your supercomputer on the Internet without security updates. The DGX A100 system has a series of critical problems with its Baseboard Management Controller (BMC), including vulnerabilities in the KVM service, the BIOS itself, and input validation bypasses.
And last but not least, JFrog has discovered a pair of X.Org vulnerabilities that have been around for 35 years. There’s quite the history to the XPM icon format, but when libX11 tries to process an odd single-pixel-height XPM, it ends up in an infinite recursion loop. Look forward to the next installment from JFrog, which will detail an RCE in X11. Both of these vulnerabilities were fixed in releases back in October.
Tagged gitlab, Ivanti, This Week in Security, vmware
No comments:
Post a Comment