Fuzzing Strategies, Responding to CISA’s Open Source Security RFI, 35 Year Old Worm – ASW #263

This article collects some recent reports on fuzzing efforts conducted by the CNCF against several of their projects. It also introduces a fuzzing handbook that looks useful if you want to better understand the benefits of fuzzing and some of the basics in setting up an environment for your own projects.

I like the areas this covers, especially where to focus memory-safe improvements. It includes a recommendation to "encourage MFA" for repos and package managers. I'd love to see this as a requirement, but as the response also highlights, open source software has global participation. So, perhaps this needs to be a requirement driven by more social pressure than any regulations.

Unsurprisingly, there's a big push for ASVS and SAMM as projects to help improve the security of open source software. (I think ASVS needs a lot of work to make it more useful for secure design and reframing to make it less of a checklist mentality.) Like the OpenSSF, OWASP points out the need for developer eduction, which they highlight as one of their strengths.

Go has been bringing security tooling into its dev environment, from fuzzing to vulncheck to reproducible builds. It's no surprise that a lot of that evolution follows larger efforts from Google like SLSA, but it's a benefit to the community.

“In 1988, fewer than 100,000 machines were likely connected to the Internet…”

The lessons here aren't about a quaint era when the total number of systems wasn't equivalent to a budget item for most Fortune 100 companies. Long-lasting access, privilege separation, and type safety (and memory safety) remain technical challenges today. The article also discusses more social aspects of appsec, such as transparency and information sharing, as well as "the propriety of hacking into other people's systems" that this worm brought to discussions -- those concepts aren't far removed from the "we take security seriously" breach disclosures and bug bounty programs of today.

ZAP is kicking off a new series of advanced guides for the proxy. Check it out, provide feedback, suggest new guides, and help out where you can!

Zscaler's ThreatLabz has a really good writeup about how they reverse-engineered O365's new support for Sketchup, then fuzzed the support library and found a bunch of issues. While this is a fairly meaty piece, they do a good job of stepping through what they did.

Apparently this is only part one. I'll keep an eye out for part two...

An interesting paper is coming out that describes training an LLM to social engineer another LLM in a black-box style attack.

While I suspect this is similar to ML models that have been used in appsec tools for a while, the ease with which we can now train LLMs leads me to wonder if this could help teams roll their own custom threat LLMs for internal use...

There was a vulnerability in sudo-rs - the rewrite of sudo to rust to ensure better security. If a UNIX username contained a pattern of periods and slashes, a user can flush the session record file with "sudo -K" - but the username is concatinated with a path to determine the session file, so this could be used to zero out other files on the system.

This is a Medium piece, so take with appropriate grains of salt. That said - a few arguments are made for why some projects are moving away from TypeScript. Compile time and added complexity are the two main arguments. One idea is to use JSDoc to document types being used, without the overhead of TypeScript. The thing is, then you need to compile the JSDoc, so I don't fully see the advantage here.

Maybe just work on improving TypeScript compile times?

At the least, this is something worth thinking about...