SAML & Secrets, Serializing AI Models, OWASP ISTG, More Memory Safety – ASW #275

Given the prerequisites in the threat model (namely, the attacker must obtain access to a private key), this risk is perhaps more copper than silver. But the article still provides a good background on SAML, points out how the management of these certs differs from others (like skip bothering with CRL or OSCP -- just delete the cert), and provides good general guidance on managing SAML-related secrets.

I already included a similar article on "Silent Sabotage" last week in episode 274. This is pretty much in the same vein -- pickling is dangerous because its deserialization can lead to arbitrary command execution.

The safetensors project looks like the right solution for this problem space. It's a format that doesn't have the code execution danger and it addresses usability concerns around performance and compatibility.

It also makes me wonder if the object serialization with potential code execution in the manner of Pickle (and Java) will be a candidate for widespread replacement to follow in the steps of memory safety.

The ISTG has officially launched version 1.0. This is a guide that does feel like it needs to distinguish itself from the similar Web and Mobile Security Testing Guides (and overlaps with the Firmware guide).

It's easy to get lost among the abbreviations, but it seems useful to have physical access levels defined for IoT devices since that's more relevant to their usage. There are also a lot of components to go through in the catalog of test cases, but that also seems like a reasonable way to organize and document the physical testing of such devices.

Check out the ISTG project page.

There's also an IoT Security Verification Standard that's in a pre-release phase and welcoming reviewers.

Maybe Security Verification Standards are the new Top Ten...

I find it curious that Log4Shell got a prominent mention. To be fair, it highlighted the challenges of identifying security bugs, fixing bugs, deploying fixes, and the lack of secure defaults -- no one really needed or used the feature that lead to the pervasive vuln.

But Log4Shell wasn't a memory safety issue. It feels like there were other opportunities to point to the memory-unsafe ecosystem from browsers to kernels to smart devices.

But if Log4Shell is highlighted for the open source angle, it's good to highlight that new open source projects should be choosing memory safe languages now and existing ones should be deciding on what their future should look like.

Check out the PDF.

Seriously Risky Business has a nice write-up on this.

It took a decade to get to 2.0, which doesn't quite match the pace of application development -- although it may (sadly) reflect the pace of appsec effectiveness.

For the show, I wanted to draw attention to the Awareness and Training in the Practice section (which gets the unfortunate acronym of PR.AT). CSF shouldn't lead to more slideware about phishing taxonomies and top ten lists -- make that awareness about something more meaningful around implementing MFA by default and creating secure account recovery processes.

This boils down to a 6-digit nonce with a 2-hour lifetime that can be brute forced in 1 hour -- largely because the specific endpoint didn't enforce rate limiting.

It's a short article that shows a positive interaction with a bug bounty program, a narrowly-scoped problem, and the challenge of deploying consistent security controls across a large API.

This is a new category of articles that probably won't get mentioned on the podcast due to time constraints, but that I wanted to highlight. I often forget about the FIPS aspect of TLS and how standards influence software and their adoption.

I also wanted to use this as a chance to mention the Feisty Duck newsletter. It's a good resource for all things TLS-related and TLS-adjacent.

We talked more about Rustls at the start of the year back in episode 268.

I think we've covered similar in the past, but I bring this in this week after the White House's latest publication on memory-safe languages. Picking the "right" language unfortunately isn't a simple choice...

A 24-year old vulnerability was found in the design of DNSSEC, which would result in massive exposure to DOS attacks while negotiating signature keys and signatures. The authors call it "The worst vulnerability ever found in DNS."