Redlining the Smart Contract Top 10 – Shashank . – ASW #322

Mike Shema

1. Traversal-resistant file APIs – The Go Programming Language

   One of my favorite topics -- path traversal!

   It's great to see a language primitive for handling file names more securely.

   On the other hand, it's only going to benefit new code that takes advantage of these new functions. That's not bad, it just means there's work to do for existing and old codebases.

   The article also notes that the underlying OS and environment may still have some inconsistencies, such as node.js remaining vulnerable to TOCTOU attacks even when using these functions.

   And speaking of OS support. It mentions Plan 9(!?) lol. Does anyone use that!? The design philosophy of Plan 9 is that everything is a file, which makes traversal particularly relevant. But wow there's an OS I haven't heard mentioned for a few decades.

2. Sign in as anyone: Bypassing SAML SSO authentication with parser differentials – The GitHub Blog

   Another favorite topic -- parsers! More specifically, mismatched behavior between parsing engines and the consequences thereof.

   The underlying premise of the article is likely familiar to many orgs: Do I use an open source library with known design flaws (or missing feature)? Or do I create my own? If I create my own, is its security any better than the open source version?

   In this case, the ruby-saml library used two backend XML parsers that handled SAML signatures in two very different ways, which mean an attacker could use a known signature from one message (not too hard to obtain) to impersonate any other user.

   Check out this paper for more details on this class of vulns.

   And check out this blog post for why SAML's design probably isn't worth saving in the first place.

3. Lingua Diabolis | Analysis of CVE-2025-24813 Apache Tomcat Path Equivalence RCE

   Back in episode 318 James Kettle shared his advice on sharing research, and pointed out that not all research successfully ends in an effective exploit.

   Here's just the kind of article to illustrate that even a difficult-to-exploit flaw can provide a simple-to-understand information. It's a nice walkthrough of what needs to be in place for this Tomcat vuln to be exploited, the thought process of putting an exploit together, and the importance of getting intimately familiar with the inner workings of a target tech stack.

4. A 10x Faster TypeScript

   There's an implied lesson in here for appsec. Don't just tell devs to use a language because it's more secure, give them a more secure language that solves their programming needs and doesn't annoy them.

   Performance and compile times are one of the biggest annoyances to any developer. That's why it's nice to see this massive improvement for TypeScript.

   Also notable is Microsoft's decision to use Go. They could have made a business or ego-drive decision to use C#, but Go provided a better developer experience for the domain problems they encountered in making TypeScript faster. I love seeing these kinds of decisions based on architecture considerations and how developers work with code.

5. FLIPPYR.AM

   What if there was a cool memory attack that no one used?

   It's not that Rowhammer isn't unusable or purely theoretical. Security researchers have demonstrated many attacks, even ones using JavaScript.

   But the gist of this project is to evaluate how practical those attacks really are outside of labs and test environments. It's not so much about POC||GTFO as it is a way to evaluate the risks associated with an attack like this. We know its severity (bad, can leak memory), but its risk comes from that severity, exploitability, and threat scenarios.

   If your org has already deployed FIDO2 keys for all employee authentication, WebAuthn (or equivalent) for all customer authentication, and your devs keep package dependencies up to date at least on a monthly basis, then you've got the luxury to start thinking about how you'd want to mitigate a Rowhammer-style attack.

6. FUN: Super Nintendo Hardware Is Running Faster as It Ages

   This is mostly for all the hardware and emulator fans out there.

   I'm still thinking up what the appsec angle might be. Perhaps something about software quality degrading faster as it ages...

7. LibAFL | Testing Handbook

   I think I mention fuzzing at least once every episode. (This week's SAML article mentions fuzzing.)

   So I might as well highlight fuzzing education and techniques at every opportunity. Here's the latest update on fuzzing tutorials from the appsec guide curated by Trail of Bits.

8. FYI: open-source-llm-scanners

   I keep asking where LLM contributes to appsec tasks (as opposed to contributing to coding assistance for devs). Here's a good list of scanners to keep an eye on to see how they fare against the old school way of writing crawlers and fancy variations on the grep command.

9. FYI: In-Depth Technical Analysis of the Bybit Hack | NCC Group

   We covered the ByBit hack briefly back at the beginning of March in episode 320.

   Here's a nice update with more technical details that's worth reading through.

10. Apple’s Lockdown Mode is good for security — but its notifications are baffling | TechCrunch

    Lockdown Mode is good. Use it if the security and usability trade-offs match your comfort level and threat concerns.

    I'm highlighting this because good UX is critical to security features. It's also a very difficult area to get right and an impossible area to get right universally. There'll always be some subjective aspects to it, but whether you're writing tools for developers or interfaces for users, question whether they're accomplishing the tasks you intended them to do and whether you're providing the best context for them to understand those tasks.

    This topic reminds me of CISA's Secure by Design principle to take ownership of customer security outcomes.