Supply Chain Integrity, Format Strings, Systemd Bug, Instagram Bounty, & Refactoring – ASW #155

When was the last time you had to remember which type fields represented void* pointers, null-terminated strings, and adding characters written to the stack? When was the last time you even used a printf() family of functions? A recent Wi-Fi bug in iOS dusted off the ancient class of format string vulns to demonstrate how the wrong sequence of percent-prefixed placeholders crashes the networking stack. Despite this disclosure, this class of bugs represents a (rare?) appsec success story -- not only did programming languages introduce more secure versions of these functions, but developers largely adopted them. Of course, "more secure" doesn't mean inoculated to vulns, it's still possible to misuse them, but format string vulns haven't had the staying power of memory safety issues like heap overflows and use-after-free. Additional resources: - https://blog.chichou.me/2021/06/20/quick-analysis-wifid/ -- a quick reverse engineering of the error to demonstrate where the flaw originated - https://cs155.stanford.edu/papers/formatstring-1.2.pdf -- an excellent introduction to format string vulns from 2001 when they first gained widespread attention as a new bug class

We tend to see two values associated with vulns these days -- their rating on the CVSS scale (boring) and how long they've lived before public disclosure (curious). In this case, it's a privilege escalation in systemd that's been lurking for seven years. What's interesting about the age of vulns is whether we'll see a spike in long-lived vulns as fuzzing and code analysis becomes better, followed by a drought of vulns as old code becomes vetted and new code needs attention. The other appsec challenge this vuln highlighted is figuring out if your system is vulnerable or not. Despite being an old bug, it was more recent distros that picked up the flaw. Check out the write-up at https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/

A bug doesn't have to be sophisticated to be valuable in a bug bounty program. In this case, it's a simple bug (with a prerequisite for obtaining a token value) that bypasses an authorization barrier in a graphQL-backed API. The researcher bagged a nice $30K for a pretty simple four-step process. It's a good reminder that moving to new design patterns like graphQL requires maintaining attention to threat models and secure implementations. Check out the write-up at https://fartademayur.medium.com/this-is-how-i-was-able-to-see-private-archived-posts-stories-of-users-on-instagram-without-de70ca39165c

We've mentioned on a few episodes how being able to crawl an AST can give better context and accuracy for code scanning. An equally compelling use of the AST is dynamically patching a codebase. This article walks through an example of using the AST to modify a Python program. This kind of refactoring is pretty cool, but it has its limits. Even the article notes that quick patching can lose formatting and code comments unless considerations are taken to handle those nuances. Still, it's an approach that's been demonstrated across different languages and represents an effective way to refactor specific code problems. Plus, you have robust test cases to maintain confidence that the changes haven't broken anything, right?

Here's a followup to the supply chain story we covered about Codecov's bash uploader back in episode 147. Not only has Codecov refactored the uploader functionality from Bash to NodeJS, they document how this change is more beneficial from a software maintenance and security perspective. It's a great way to see how a deciding on a programming language based on engineering principles and support for DevOps workflows is far more useful than sticking with something because it's easy or just the cool thing to use.

We don't need strict definitions of "shift left" or "DevOps" in order to discuss the shift in responsibility for security to dev teams. Nor do we need a lot of appsec navel-gazing about labels when fundamental principles like feedback loops and security testing are more important to discuss. This article highlights that we shouldn't over-index on the security of the design and development stages for software. There'll still be new vulns reported in dependencies and coding mistakes than make it past security controls. So, as much as you're thinking about shifting left, keep the principles of observability and monitoring in mind when your app "shifts right" into deployment.

I think my favorite part is the threat model. Wish it was more than "just" a framework...