This Week In Security: Glibc, Ivanti, Jenkins, And Runc

There’s a fun buffer overflow problem in the Glibc __vsyslog_internal() function. This one’s a real rollercoaster, because logging vulnerabilities are always scary, but at a first look, it seems nearly impossible to exploit. The vulnerability relies on a very long program name, which can overflow an internal buffer. No binaries are going to have a name longer than 1024 bytes, so there’s no problem, right?

Let’s talk about argv. That’s the list of arguments that gets passed into the main() function of every Linux binary when it launches. The first string in that list is the binary name — except that’s a convention, and not particularly enforced anywhere. What really happens is that the execve() system call sets that list of strings. The first argument can be anything, making this an attacker-controlled value. And it doesn’t matter what the program is trying to write to the log, because the vulnerability triggers simply by writing the process name to a buffer.

There is a one-liner to test for a vulnerable Glibc:

exec -a "`printf '%0128000x' 1`" /usr/bin/su < /dev/null

and the Qualys write-up indicates that it can be used for an escalation of privilege attack. The good news is this seems to be a local-only attack. And on top of that, a pair of other lesser severity issues were found and fixed in glibc while fixing this one.

48 Hours to Rip and Repave

We’ve briefly covered the vulnerabilities in Ivanti Connect Secure/Policy Secure devices, but it seems we’ve failed to properly grasp the severity of this threat, given the latest Emergency Directive from CISA. Issued January 31st, it gives all of 48 hours for every US government network to yank the power cord from these devices. This is significant, as we’ve seen plenty of directives to install updates or mitigations, but this may be the first directive that includes full removal.

And then the instructions for getting a device back into service are fairly extreme, too. Complete factory reset, revoke all the certificates associated with the machine, and generally assume that your box has been completely owned. It seems like CISA knows something that maybe we don’t, and it’s not great news for Ivanti users. Do note that this even applies to devices that have had the XML mitigation applied. Yikes.

Jenkins

The Jenkins automation server just fixed a pair of vulnerabilities, both of which have the potential to be pretty bad. Up first is a data leak, where a the parseArgument function will interpret an “@” symbol to mean expanding a file location into a series of arguments. It works out to provide a file read primitive, which can be accessed by any users with read permissions.

There’s also a cross-site scripting problem with the websockets Command Line Interface functionality. Some of the normal protections against XSS problems aren’t applied to websockets connections, so a malicious link can trigger CLI actions when clicked by an authenticated user.

Both of these issues were fixed in 2.442 released on the 24th, but the file read issue now has Proof of Concept code out in the wild. It’s likely not long until those are used in attacks, if it hasn’t happened already.

Leaky Vessels

Researchers at Snyk have identified a quartet of vulnerabilities that threaten the sandboxing guarantees of modern containers. There’s one that is in the runc binary itself, where a host file descriptor can be leaked into the container process, exposing the entire host filesystem. This means a docker run or docker build command could have access to the outside system. The other three issues are specific to Docker Buildkit, and also allow system access of varying degrees.

There aren’t any signs of active exploitation, and the runc program has been updated. Snyk has also released a pair of tools to look for Docker images attempting to exploit these issues.

Bits and Bytes

It’s another chess hack, but thankfully this time there’s no buzzers in shoes or other places, this is an XSS of chess.com. This one is a throwback to the original Myspace worm — gaining friends automatically on pageview. The next step was actually running JS on pageview and getting cookie data out. Check and mate.

The FBI hit the killswitch on a few hundred compromised Cisco and Netgear routers in December. These are Internet-connected devices that are either end-of-lifed or simply unpatched, and have been compromised and made part of a botnet. The most fascinating bit is that the disinfecting process included adding a mitigation to prevent reinfection, but one that only lasts til the next reboot. Maybe next time we can get the FBI to upgrade those hacked routers to OpenWRT instead.

The Fortra GoAnywhere Managed File Transfer solution has joined the ranks of the critically vulnerable, as versions 6 and 7 of this software allow unauthorized users to create administrator users via an authentication bypass. The fix landed in 7.4.1, and this is the sort of juicy vulnerability that ransomware groups just love to take advantage of.

And this is your reminder that not every reported data breach is real, and not every online fake is the result of AI. Europcar.com was reported to have lost records for fifty million customers, with the database being offered in the usual places. Except the data didn’t make any sense, with plenty of those users apparently living in imaginary cities. The explanation quickly came out, that it was obviously ChatGPT-generated data — which is apparently now describes any faked data, as this has no signs of actually being produced by a Large Language Model. Ah well.

4 thoughts on “This Week In Security: Glibc, Ivanti, Jenkins, And Runc

  1. > There is a one-liner to test for a vulnerable Glibc:
    > exec -a “`printf ‘%0128000x’ 1`” /usr/bin/su < /dev/null

    You want to put that one-liner in parens: (exec -a "`printf '%0128000x' 1`" /usr/bin/su < /dev/null) – otherwise, the shell will exit immediately after running the exec, which doesn't give you much information on whether or not the exploit succeeds.

    If you see a segfault, you're vulnerable. If you see a ton of 0s with a 1 at the end and 'Authentication failure', you're not.

    Annoyingly enough, the Raspberry Pi Foundation built their own glibc package for Bookworm (which, despite standardizing on glibc 2.36, is indeed vulnerable, as they backported the buggy patch from 2.37 to Bookworm's glibc, d'oh) due to their inclusion of libwidevine. If you're running Raspberry Pi OS Bookworm on a Pi, it's vulnerable, and there's no official updated glibc package available for it as of yet: https://forums.raspberrypi.com/viewtopic.php?p=2188171&hilit=cve&sid=978b68aa3b0bf814302f217256d010b1#p2188171 – you can install Debian's fixed package on a Pi, but it'll uninstall core dev packages, and you'll lose libwidevine, if that's important to you.

    That being said, I threw together the Debian patches for 2.36-9+deb12u4 (the fixed package) and the Foundation's 2.36-9+rpt2+deb12u3 (vulnerable, with widevine) package last night, and it appears to work on my Pis:

    pi@schwartz:~ $ grep Model /proc/cpuinfo
    Model : Raspberry Pi 4 Model B Rev 1.4
    pi@schwartz:~ $ dpkg -l libc6
    Desired=Unknown/Install/Remove/Purge/Hold
    | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
    |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
    ||/ Name Version Architecture Description
    +++-==============-===================-============-=================================
    ii libc6:arm64 2.36-9+rpt2+deb12u4 arm64 GNU C Library: Shared libraries
    pi@schwartz:~ $ (exec -a "`printf '%0128000x' 1`" /usr/bin/su < /dev/null)
    Password: 0000000000000000000000000000000000000000000000000000000000000…000001: Authentication failure

    I can put my unofficial packages up on my own site, if there's any interest. Otherwise, I'd imagine the Foundation will have a new package soon.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.