Internal Jokes – ASW #183

This is some neat research that looked at the state machine within the HTTP/3 protocol implemented by the H20 server. HTTP/3 (and HTTP/2) introduced frames as a way to handle multiple streams of data within a single connection. This flaw arises when a server makes assumptions about how to put streams back together from frames that may or may not have arrived and may or may not have been initialized. At a high level, it sounds like a common weakness when dealing with buffered data that can arrive out of order or not at all. Mishandling memory due to buffer mismanagement also sounds like a flaw common to C and C++ (i.e. memory unsafe languages). It's nice to see the project has built-in support for LLVM's LibFuzzer and the corpus files to go along with it. But this sets up the questions of why a project like this chose not to adopt a memory safe language (Rust wasn't viable at the project launch in 2014, but Go was) or what the overhead of rewriting the project in a memory safe language would be. Of course, that wouldn't magically fix all the possible vulns, but it would be a great start. Check out the technical write up at https://medium.com/@emil.lerner/leaking-uninitialized-memory-from-fastly-83327bcbee1f

Supply chain security isn't about specific vendors or specific bugs; it's about having controls in place that limit the access and potential impact of vulns that might arise within dependencies or the tools used to build and deploy software. In this case, it's a CD tool, which is particularly impactful since that type of tool often has access to secrets, sensitive tokens, and the ability to modify software as it's being packaged. What's fun about this is that it's a directory traversal flaw within Go code that made assumptions about the trust levels between a local file (check for traversal) and URLs (don't apply the same checks). It's also a chance to talk about how "input sanitization" is often a misleading recommendation or too generic to be helpful. Path traversal touches on parsing, normalization (aka canonicalization), sandboxing, and how to enforce security controls. More details can be found at https://apiiro.com/blog/malicious-kubernetes-helm-charts-can-be-used-to-steal-sensitive-information-from-argo-cd-deployments/

We often like to highlight postmortems from companies that demonstrate how they react to vulns and the steps they took to identify and remediate root causes. Here's an insight into the side of fixing such a flaw in the first place, which is already under appreciated within open source and more stressful when it gets significant attention like Log4j. It can be a good reminder about how to set up collaborations with your own DevOps teams when they're responding to bug bounty reports or fixing security bugs. The scale might be different, but the principles behind coordination, communication, and empathy remain the same.

Log4j's legacy might not be an era of widespread compromises -- at least not yet. While the vulnerable code was clearly widespread, the fallout doesn't seem to be similar to the worms and ransomware we've seen from other vulns. But one legacy that it will surely have is being the most recent reference for teams scrambling to update their software asset inventories, improving their vulnerability scanning solutions, and patching often-unowned or previously-unknown software. DHS has stepped into the arena with the type of effort the industry has long been waiting for -- a review board to understand what went wrong, how systemic failures made the response harder for organizations, and what those orgs can do to avoid whatever the next log4j looks like. The initial members come from industry veterans with areas of expertise across government, policy, vuln research, threat analysis, and dealing with complex problems across large organizations. It shows great potential already and is something we'll be following as their work progresses. Another article on the topic is at https://www.zdnet.com/article/white-house-creates-board-to-review-cybersecurity-incidents-members-to-start-with-log4j/ Check out the DHS announcement at https://www.dhs.gov/news/2022/02/03/dhs-launches-first-ever-cyber-safety-review-board

Last week we covered the recent update to the Open Source Security Foundation's Scorecard. Here's another article on their larger push to directly work with critical open source projects on maturing their security, as well as setting up tools to help inform a larger population of projects about what they can do to secure their software. It's encouraging to see this sort of investment that combines manual work and automation. After all, a lot of open source projects already know what they need to do -- they lack the investment in time and developers to help them accomplish those tasks. Check out the project page and find out how to participate at https://openssf.org/community/alpha-omega/

We covered part 1 of this series two weeks ago in episode 181 (https://securityweekly.com/asw181). Part 2 goes into a lot more detail with 20 items that can set an effective baseline for a program. It's a good companion piece to the articles this week on the DHS Cyber Safety Review Board, the Alpha and Omega efforts from the OSSF, and even the comments from the Log4j developers about their experience with fixing Log4Shell. Each of those articles speak to areas that stem from concepts in this article, and they're a good reference for seeing the challenges in establishing security programs.

Here's a great resource on using Frida to instrument binary applications for reverse engineering and analysis. It's a great part of a home appsec lab and useful if you're interested in learning new skills.

We don't want to neglect educational resources or mobile apps -- so here's a great combination of both. It's an intentionally vulnerable app that's helpful for those who want to understand the basics of setting up a toolbox and lab for security analysis, followed by a target that lends itself to helping understand how to conduct that analysis.

Here's a list of resources for building your own lab and educating yourself on appsec topics with hands-on exercises. We covered some of the resources in the Security Weekly webcast on building a home lab for security testing, but there's always room for more!