IIS Bug, Browsers & Androids & Supply Chains Oh My! – ASW #152

Oops. Last episode we talked about the 20 year old double-decode bug in IIS and applauded the significant hardening IIS went through that helped it avoid repeating that situation for a long time. That hardening has still paid off, but internal Microsoft researchers found a recent flaw that threatens the long-standing record of security. What would be cool to learn is how the flaw was discovered -- fuzzing, manual analysis, compiler feedback -- and whether it was newly written code or some ancient area of the HTTP stack that had a chance to manifest now.

IE isn't alone in decades of bugs -- we've seen repeated and actively exploited flaws in Chrome just within the last few months, and Safari and Firefox have their own share of security bugs. This article gives us a chance to reflect on what's changed in browser security over the lifetime of IE. We've seen positive trends in how software architectures change and how HTML has become less quirky and more standard. But we've also seen security and privacy flaws continue to plague browsers, whether due to their legacy of memory unsafe code or due to new techniques to track users and leak information.

The infamous supply chain hack at the end of 2020 continues to blow through appsec conversations. This article gives a good overview of the need for an auditable way to track an artifact from source code to commit to packaging. It also includes useful references to the tools and standards that can help an organization mature their SDLC to the point where they can have confidence in their own pipeline as well as convey that trust to others who use their software.

Thirty-five pages isn't exactly light reading, but Android's security model isn't exactly for a lightweight platform. This open access article could be use to different audiences, like security researchers who want to understand the assumptions made within Android or technical product managers who want to improve their knowledge of complex architectures and engineering trade-offs to accommodate users and developers. Even if you're not working on a mobile platform, reading about the choices that go into designing the security of large systems and understanding in-depth threat models can reinforce security principles that can be transferred to other types of applications. As much as it's educational to read code written by others, it's just as informative to read about the software architecture and implementation choices made by others. Check out the PDF at https://dl.acm.org/doi/pdf/10.1145/3448609

Here's a tool-focused balance to this week's heavier articles on supply chain security. This tool, using eBPF to profile system activity, is surely part of the growing trend of shifting scrutiny to the CI/CD pipeline. In this case, it's taking the approach of improving observability in order to detect malicious activity that might corrupt artifacts or otherwise target the build-to-deploy process.

This video is a fun presentation from KubeCon that takes a journey from a developer's perspective through the trials and tribulations of working with Kubernetes securely. It has one of the scariest lines a security team might hear -- “I’m not calling the security people; they are not fun.” While security doesn't always have to be fun, they should at least be a partner with the DevOps teams working on Kubernetes (and any other tech stack, for that matter).

On the heels of last week's discussion about how bad design weakens any relationship between complexity and security we have an example of an outage that suffered from weak designs in tools and processes. Salesforce provided a rather detailed postmortem, although it leaves some ambiguity in how much they attributed the situation to the cliché of "human error" as opposed to poor processes and insufficient automation that failed the humans. Oh, and it's always DNS. Check out last week's episode for our thoughts on bad design. You can find the specific article we talked about at https://www.philvenables.com/post/is-complexity-the-enemy-of-security

Here's a reminder that supply chain security and the impacts of vendor breaches didn't suddenly appear out of space like an astral breeze. While the article might not have specific takeaways for a DevOps team since it's more focused on forensics and piecing together the history of a significant compromise, it can provide a seed for security tabletop exercises with a DevOps team. How isolated do you think critical areas are? How isolated are they really? How do you manage secrets, whether they're root certificates, user credentials, or service-to-service authentication? What about API keys? This isn't the kind of article necessary to lead with fear about a compromise, nor a sense of nihilism that compromise is inevitable -- it's the kind of article to use as a way to be prepared for security events and minimize the kind of surprise that comes with things like, "I didn't realize those networks were connected".