LLMs & Security Tools, Shim Vuln, AI Threat Models, Configuration as Code with Pkl – ASW #273
LLMs improve fuzzing coverage, the Shim vuln threatens Linux secure boot, considering AI application threat models, a new language for a configuration file format, and more!
Announcements
Security Weekly listeners save $100 on their RSA Conference 2024 Full Conference Pass! RSA Conference will take place May 6 to May 9 in San Francisco and on demand. To register using our discount code, please visit securityweekly.com/rsac24 and use the code 54USECWEEKLY! We hope to see you there!
Hosts
- 1. GitHub – google/oss-fuzz-gen
- 2. Shim vulnerability exposes most Linux systems to attack
- 3. Analyzing AI Application Threat Models | NCC Group Research Blog | Making the world safer and more secure
- 4. Pkl
- 5. Google Online Security Blog: Improving Interoperability Between Rust and C++
Read the Rust Foundation's announcement.
- 6. FYI: DEF CON 32 Call Index
No more Caesar's, but not canceled. They have a FAQ about the venue change.
- 1. Why bloat is still software’s biggest vulnerability
An article over in IEEE's Spectrum not just laments the bloat of modern software, but argues (reasonably) that such unnecessary bloat is resulting in vulnerabilities that could be avoided. There's some great lines in here, including the idea that when your app/phone/thing has millions of lines of code - the bug density doesn't have to be very high to find an exploitable hole.
Looking at the case of a Internet-connected garage door opener - from the code running on the device, to the cloud services it connects to, to the app on the user's phone - "We are likely looking at over 50 million active lines of code to open a garage door," running on several different operating systems. Sure - it's not quite that simple when including the cloud service, but in a way - that's the author's point.
- 2. US studying “liabiliity regimes” for software flaws
The US Office of the National Cyber Director (ONCD) is trying to figure out what they can do to hold software manufacturers liable for "rushing code to market" in an insecure manner. The idea here is by defining regimes of where legal liabilities lie for publishing defects, they could then attempt to hold those publishers (more) accountable.
From a brief search of the Internet, it seems like while liability regimes sound great, in practice the results are mixed.
One of the reasons ONCD is working on this is because foreign actors are actively hacking or planning on hacking US Critical Infrastructure. The weakness in this whole argument is we (as a world) are still running vulnerable software from 5-10 years ago, so even if this idea was transformed to law in the morning, the chance of significant effect will take years.
- 3. Mastering Privilege Management for Developers
In part 3 in a series, Robert de Meyer does a good job explaining to developers why and when to care about privilege management in their SDLC. We know we should separate out privs to minimize blast radiuses when using cloud platforms, but he has several sketches that visualize why it's better to do this work early in the development lifecycle.
Part of why I like this post is it feels to me like a good way to break these concepts down to discuss with developers.
(h/t cloudseclist)
- 4. ZEN: Zane Lowe talking with Yo-Yo Ma
This in theory is an interview around of a musician, but listening to the two while driving home from the slopes this weekend I think there's some things for all of us to take from it.
From an appsec point-of-view...when we form an opinion of a vendor, developer, manager...maybe should look at what we can learn from that engagement, not so much what was wrong. I think this is a good conversation to give a listen on a quiet moment when you have the chance.
