Shifting Focus to Make DevSecOps Successful – Janet Worthington – ASW #258
Full Audio
View Show IndexSegments
1. Shifting Focus to Make DevSecOps Successful – Janet Worthington – ASW #258
What if all these recommendations to shift left were more about shifting focus? It's all too easy to become preoccupied with vulns, whether figuring out how to find them earlier in the SDLC or spending time fixing them within specific number of days. Successful DevSecOps approaches can be so much more than just vulns and so much more than just tools. Sure, tools are useful for identifying known vulns in dependencies and new vulns in code, but teams that emphasize people and culture will find it easier to shift their attention to the security of their product and creating secure designs.
Segment Resources: Shift Everywhere is the bullet-train to secure software: https://www.forrester.com/blogs/shift-everywhere-is-the-bullet-train-to-secure-software/?refsearch=35020611696872306356 Forrester Software Composition Analysis (SCA) Wave: https://www.forrester.com/report/the-forrester-wave-tm-software-composition-analysis-q2-2023/RES178483?refsearch=35020611696863504716 Forrester Static Analysis Security Testing (SAST) Wave: https://www.forrester.com/report/the-forrester-wave-tm-static-application-security-testing-q3-2023/RES178489?scrollTo=FHqjnkXmzX
Announcements
Security Weekly Listeners: We are celebrating the milestone of reaching over 1,000 members of our CISO community. The Cybersecurity Collaboration Forum is a one-stop shop for executive collaboration comprised of CISOs across various industries. If you want to be part of this growing community of CISOs, join us as a member or technology partner. To learn more, visit: securityweekly.com/cybersecuritycollaboration
Guest
Hosts
2. Curl’s Impending Patch, Glibc’s Looney Tunables, ShellTorch, Another Top 10 List – ASW #258
Anticipating Curl's upcoming patch for a high severity flaw, the Looney Tunables flaw in Glibc, ShellTorch flaw hits PyTorch and lots of AI, lessons from some X.Org security patches, eBPF security, and more!
Announcements
Follow Security Weekly Productions on LinkedIn for exclusive show clips, insights, and updates across our organization! Stay connected with our hosts and fellow community members, and join the conversation that's shaping the future of cybersecurity.
Hosts
- 1. Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
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.
- 2. X.Org Security Advisory: Issues in libX11 prior to 1.8.7 & libXpm prior to 3.5.17
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.
- 3. Qualys Security Advisory Looney Tunables: Local Privilege Escalation in the glibc’s ld.so (CVE-2023-4911)
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.
- 4. ShellTorch: Multiple Critical Vulnerabilities in PyTorch Model Server (TorchServe) (CVSS 9.9, CVSS 9.8) Threatens Countless AI Users – Immediate Action Required
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.
- 5. Linux tries to dump Windows’ notoriously insecure RNDIS protocol
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.
- 6. Joint Advisory on Top Cyber Misconfigurations Highlights Urgency for Software Manufacturers to Incorporate Secure by Design Principles
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.
- 7. CONFERENCE: Tectonics
- 1. FDA cyber security rules published, go into effect
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.
- 2. Offensive eBPF
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.
- 3. How ’bout a eBPF documentary?
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
- 4. Privilege escallation in Confluence
We haven't talked about Atlassian products in a few months, but we're back with another privilege escalation in everybody's favorite - Confluence
- 5. Python 3.12.0 out with more flexible string parsing
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.
- 6. Pitfalls of relying on eBPF for security monitoring
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)
- 7. How ’bout some exploit code for that LD_SO bug?
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
- 8. Using Cloudflare to bypass cloudflare
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.