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.
And last but not least, JFrog has discovered a pair of X.Org vulnerabilities that have been around for 35 years.
One of these days a security researcher will discover a vulnerability older than they are….if it hasn’t happened already.
I turn off PXE boot as a matter of course. But I can see why it would be very useful in business. Can always use a seperate method for booting off the net if need be, but it would add greatly to costs.
Did anyone see what the method of persistence on PXEFAIL is supposed to be? With what I know about the architecture of PCs and the various firmware protections in place, it would be quite the accomplishment if they have a general exploit that gets executable code on the flash part and has it get executed by the firmware.
I suspect they are instead putting something on the UEFI system partition which would count as being ‘persistant’ but is something much easier to defend against and repair.
This will sound odd, but hearing how many vendors are affected because they are using the drivers from the EDK2 is actually a really good thing because it means the issue can be addressed centrally in the project and fixes can be downstreamed. the EDK2 may catch flack for using the BSD license, but this shows the power of using open source even if it’s not based on a GPL license.
The issue after that is the one that always crops up with embedded systems. The individual manufacturers need to integrate that update with their modified code and create new firmware images that the end users then need to update.
In the longer term, I really, really hope companies that make tools take note. Many if not all of the vulnerabilities highlighted would have been flagged by running a static analysis tool that supports the CERT-C ruleset. Even basic fuzzing could have been helpful. Hell, unit testing should probably have revealed something.
But many of the tools out there either work at too small a scale, or assume the software is wirtten to work under a popular OS and use standard libraries. Companies like Synopsis just don’t see any profit from doing the work to support something like UEFI.
The EDK2 only just got a unit test framework relatively recently (a few years ago) and that’s only because Microsoft saw firmware flaws as a big enough threat to take work they were doing internally and add it to the EDK2 project. But without some sort of incentive, I expect to see more stories like this until some organization steps up to help solve the tooling issue.