ASW #242 – Ten Things I Hate About Lists

A segment of infosec became very concerned about new TLDs for .zip and .mov. The worry was how these familiar file extensions would be rich vectors for phishing.

I don't share that worry. If we're still relying on users to inspect URLs and decide they're safe or not, we're failing as an industry. People will click on links. Links are designed to be clicked on. Phishing countermeasures need to move on from thinking about visual URL parsing and more about countering the "post-click" consequences. This is why MFA and WebAuthn are important, as are browsers showing the visited domain, auto-updates, restrictions on downloads like the "mark of the web", and other controls that impede attacks that need user interaction.

If we're just going to focus on figuring out what makes a "safe" URL, we might as well implement RFC 3514.

Also check out the slides from Black Hat Asia.

We talked about eBPF programs back in episode 235 with Liz Rice. In the span of that interview, this fuzzer would have created about 1.2 million eBPF programs to run through the validator -- which is about 1.2 million more than I've written.

With fuzzers like this it's important to see how the investment in time and resources pays off. So far the fuzzer has claimed one flaw, CVE-2023-2163. As the eBPF codebase grows and changes over time, we'll hope to see this number grow as it finds implementation errors and potentially exploitable vulns.

Rust started at Mozilla. Its inroads into the Linux kernel took almost two years, of which most of that time was creating the build infrastructure and tooling support. Seeing a company like Microsoft embrace more Rust is good for many reasons. It's easy to point out that Microsoft needs more secure software -- just point to the 20 years of Patch Tuesday. But Microsoft also employs lots of developers, which adds to the population growing among open source and companies like Amazon. And, importantly, Microsoft can bring more Rust support into the developer ecosystem with its IDEs and GitHub.

Check out the slides and video.

Interoperability is critical to privacy-friendly systems.

The draft will also be interesting as a source of security research. They are threat scenarios to imagine, implementations to fuzz, and unintended side effects to discover.

We're talking a lot about awareness this episode, so it seems appropriate to highlight this survey from the folks at OpenSSF.

If you'd like to help influence the direction of OpenSSF and its projects, take a moment to complete the survey. We'll keep an eye out for the report on that should come out later this year.

This is a quick read since it mostly boils down to a brief analysis and affirmation of seven claims about AWS Nitro Security. It links to AWS documentation and a presentation about the design.

What would be really cool to see from these kinds of public reports is an expanded section on the assessment methodology in a way that highlights effective ways to approach threat modeling, gathering information about a system from its designers and developers, and documenting design principles that others could learn from. That's not the goal of this report, of course. But we'll keep searching for those kinds of resources.

Yes, after talking about top 10 lists I include a top 10 list in the news. But "Directory Traversal" made number one, so it was impossible to resist.

However, the list also seemed to have a low-quality bug bounty type of entry in number eight, "Sensitive Cookie Without HttpOnly Flag". And I was surprised to see number nine's "Cleartext Transmission of Sensitive Information" when we live in a modern world of browsers opportunistically using HTTPS.

Pointers to presentations that might interest you from this year's RWC.

Videos from this year's BSidesSF, which ran the weekend before RSA.

Not everyone has time to go through all 76 videos. Let us know if you attended any or have some favorites you'd like to highlight for the community!

For threat modeling, I've always found a document and a drawing surface to be sufficient tools. Everything else feels like too much overhead or too burdensome to bother with.

While I'm comfortable with the written word or the drawn diagram, some people prefer visualizations and find them useful for guiding discussions about threat scenarios. The Deciduous tool from Kelly Shortridge builds attack tree diagrams from bullet points. That feels like a not too-much overhead for a useful result.

Find more at Kelly's blog.

PyPI has been dealing with an increased volume of malicious users and packages.

This story is of interest to me in that as we remove legacy code, we may reduce potential vulnerabilities. But perhaps some new ones will be introduced as software is updated to work on newer CPUs?

What do we call the increasing pile of vulnerabilities that won't be fixed in IOT things?

Vulnerability debt?

VMs are great for security R&D work, as they provide a (usually) trustable environment. Snapchange takes this a step further by allowing fuzzing a program in a KVM VM, which allows repeatability by taking a snapshot of a running VM, and then being able to fuzz an application without having to set it up each time

The miscreants have figured out by configuring Windows execution options for programs that they don't want running (say, antivirus), the target program will crash at startup. In particular, they've figured out by setting a minimum stack commit size to a value larger than available memory, the app will crash with "Status No Memory" error.