Shifting Focus to Make DevSecOps Successful – Janet Worthington – ASW #258

Lots of advance warning about a high severity bug in Curl (library and client). Curl is pervasive (for good reasons!), but its client-side nature feels like this won't be similar in risk to Heartbleed or Shellshock. To quote the maintainer, Daniel Stenberg, "The severity level is a blunt tool. This is a HIGH severity problem but there is still going to be a large chunk of users who will not be affected by these problems."

I'm very curious to see the patch, especially since "this issue has stayed undetected for years for a reason." Curl has had security flaws in the past across memory safety, integer overflows, race conditions and the sorts of vulns you'd expect from C-based code. But those flaws have still been few and far between. The code is well designed and implemented, and that pervasive nature means a lot of eyes -- and tools -- have been scrutinizing it.

I've also been a fan of Curl because of the way its maintainers, Daniel Stenberg and others, have built and curated its community. I think it's been such a longstanding and successful project as much due to that as it is an important tool.

Our emerging theme this week is covering security bugs in C code. But the points I want to make are less about C and more about how we use and security the apps built in C. For example, with libcurl we could talk about potential exploit scenarios and the importance of egress filters and traffic inspection -- two things unrelated to C as a programming language.

In this article, I'm worried less about anyone who's relying on the X Window System and more interested in what these flaws show us.

There are "hardening" commits along with the "fix" commits -- the devs didn't just patch the obvious flaw and move on, they considered how to make these areas of code more resilient to errors.

In one of the patches, it was cool to see that the test cases for the fix for another CVE were being run under the compiler's AddressSanitizer and, sure enough, the sanitizer identified an out-of-bounds read. This sounds like a win for leveraging the compiler's security capabilities.

In another patch, the discovery of the flaw was attributed to clang's libfuzzer. Once again, this looks like a win for compiler security options.

Appsec loves its SAST, DAST, and similar tools. It loves talking about AI. It loves talking about shifting left, as if developers never thought about security. I love seeing security capabilities in compilers and IDEs and, even better, seeing them being used and successful.

More insecure C this week! But this time it's in parsing. The impact of the parsing flaw in this code does lead to an overflow, so we're in classic memory non-safety territory of C, but parsing problems can have many other security consequences in memory-safe code as well -- look at the URL parsing flaws in Python and Go we've covered recently.

But another point stood out for me on this one. The researchers found this flaw manually, but then they checked if it could be found with fuzzing. It could, but only after being seeded with a dictionary of "tunables". That dictionary is trivially generated, but someone has to do those steps -- attach a fuzz harness and give that harness useful context about the app's behavior and input. We've seen OpenSSF invest in that kind of security work, which seems like a smart investment.

Finally, a flaw this week that isn't in C! Researchers identified security bugs in PyTorch that enabled remote access due to an insecure default, an RCE because models could be loaded from any domain by default, and code execution due to a deserialization flaw in YAML.

So, two defaults and one deserialization. Time to talk more about secure by default and secure by design.

Bear with us as we cover yet another Linux article this week. This one is about one of my favorite secure coding methods -- deleting code! Reducing attack surface and deleting unused, old, and brittle code is a method that doesn't get enough appreciation.

But as this article shows, deleting code is also hard. This case boils down to a trade-off between removing a feature that would affect almost all Android phones vs. getting rid of a long-standing security risk within the Linux kernel.

NSA and CISA now have a list based on what their red and blue teams have encountered in real world environments. A lot of the content will provably be familiar -- bad defaults, poor asset inventory, slow patching and upgrade cycles -- but it has more actionable recommendations than many top 10 lists.

Check out PDF the here.

On a related note, NSA and CISA have also published a report on MFA and SSO Challenge, which is a nice complement to that list.

Prossimo, the org behind the push for more memory safety in critical Internet apps is hosting a conference in San Francisco on November 3rd.

One example of their work we've mentioned in the past is a memory-safe DNS server, which is now known officially as Hickory.

We covered this in the past, but just a heads up to those of you working on healthcare-related devices - the FDA now cares about how you manage their security, and may reject devices due to weaknesses.

It's possible we mentioned this one in the past, but as I'm talking about ebpf this week, I thought I'd re-mention. Really, IMHO ebpf is a little too powerful to be using as a security construct.

Haven't gotten enough eBPF yet? Good, 'cause here's a trailer for a documentary on eBPF that will be coming out at Kubecon/Cloudnativecon on the 8th of November

We haven't talked about Atlassian products in a few months, but we're back with another privilege escalation in everybody's favorite - Confluence

Python 3.12 now has better support for f-strings. This isn't a direct security improvement, but at least for me, string input/filtering/manipulation tend to be areas ripe for security issues, so hopefully more f-strings will allow some developers to write in a more secure manner.

Also, looks like Python replaced some of their hashing code with formally verified code from the HACL* project. Always good to see less wheel-rebuilding, or perhaps switching to a better built wheel.

Over the last few years, a corner of the container/cloud-native security space has turned to eBPF to answer all their questions and solve all their problems. But...eBPF wasn't created for security or monitoring. Trail of Bits has a good blog pointing out the issues here, and how to work around them (I had this listed for ASW 257, moving to 258 as we ran out of time)

Since this is now out in the wild, I figured I'd share one of the exploits published for CVE-2023-4911

But! Also! Let's compare and contrast! Here's another exploit for that same vuln. It's interesting to see how at least to me one of the exploits is easier to read and understand what's going on. I don't consider my C skills to be rusty, but one of these calls(ha) to me more... https://github.com/RickdeJager/CVE-2023-4911

A little surprising this hasn't been reported previously (I double-checked the publish date), but it turns out Cloudflare, too, has a secure-by-default issue. It's possible to use one Cloudflare "protected" node to attack another, due to a "feature" that intends to allow a customer's systems to access other systems "inside" a cloudflare protection zone.