Sorting Out Glibc Vulns, Apple’s Security Research Device, BoringSSL, Old C Vulns – ASW #272

More great research from Qualys. As a commentary on the structure of the article, I appreciate how it puts potential exploitation into context, provides useful technical details up front, adds some understandable marketing at the end (all vendors do this to a degree), and has links to more details at the end.

Apple took a unique path with making iPhones friendlier to researchers when it made a jailbroken device available in 2020 (if you went through some hurdles). Obviously, we've seen plenty of critical vulns before the advent of officially supported devices for research. But we've also seen significant security design and sandboxing that raises the bar for exploitation. Exploits and malicious apps don't have access to an evil bit or setting to trick users into weakening their device.

Apple has a few details in its platform security guide.

The first bar graph tells a great story of BoringSSL and all the cruft, obscure architectures, and unnecessary code that it removed from OpenSSL. We've covered different approaches to OpenSSL, including the Rustls implementation of TLS 1.2 and 1.3.

As the article notes, using BoringSSL comes with a huge caveat -- Google is essentially doing this project for themselves, so no easy versioning or external support. Amazon has their own flavor of TLS with s2n-tls, which is a complete re-implementation in C.

Heartbleed was the vuln that launched a 1,000 reconsiderations of OpenSSL, with fallout still lasting to this day.

This is a nice set of articles that walks through developing an exploit for an image-parsing vuln.

Sure, libX11 isn't the most relevant thing out there, but learning about exploiting C is useful. And the underlying premise of mucking about with image formats (or sound or video or PDF formats) should be part of any service's threat model that deals with user-generated content. So, even if you want to skip the X11 and C part of this, use it as a discussion seed for how your services isolate, sandbox, and monitor any file format that needs to be parsed.

Another alert from CISA in their Secure by Design series. I'm still thinking about these in terms of what can make them more impactful and avoid having them become referenced as some sort of "CISA's Top Ten Secure by Design Alerts".

This doesn't have an immediate appsec hook, but I highlighted it for a few reasons. One, Josh has been on the show as one of the few developers we've had. He's helped bring the developer perspective to our appsec conversations.

But it also made me think of how we position appsec tools for developers. Do we have an IDE plugin that does one security thing and that thing only, or introduce tools that handle many different security tasks and topics?

Josh last hung out with us last year in ASW 251 and ASW 262.

The nerds at Qualys posted more details about the glibc CVE on the OSS security list. Link above is for the buffer overflow in syslog(), and the qsort vuln is posted at https://www.openwall.com/lists/oss-security/2024/01/30/7

The folks at Watchtowr saw another network device with another PHP interface, and did the needful, opening with "please remember that we are discussing an appliance from a security vendor and thus we have to expect the [security] bar to be lower."

After a few moments of poking around, they manage to get the encrypted root password, leaving it as an exercise for the reader to decrypt and enjoy the riches.

While they're at it, they find some XSS, and a bit of deep thought: when doing research on a vuln, it's not uncommon to find a "cluster" of them near each other.

Also - Juniper needs to catch up with the times, as apparently they only release security updates quarterly.

Rory McNamara, now at Snyk, found a neat vulnerability in runc - the cli that's becoming standard for interacting with container runtimes. In a nutshell of types, he figured out that during runc init and runc exec, runc wasn't checking if a directory passed to WORKDIR - a command to tell the runtime where to look for files to build into the container. This leads to an order of operations type vuln, where by changing to a directory which the runtime has access to but a container shouldn't before privileges are dropped, then the container manages to keep those privileges.