ASW #187 – Lebin Cheng

A vuln that potentially turns a malicious markdown table (i.e. one with more than UINT16_MAX columns) into an RCE. It's a classic C language error of integer math gone wrong with a bonus of unsafe memory handling. Notably the project has a fuzzing harness built in, but that fuzzing doesn't include exercising the size boundaries for markdown features. It's great to see the fuzzing capability (as well as explicit build options with clang's Address Sanitizer). Sadly, it's a reminder than integer overflow (and underflow) plus memory safety issues will always plague C, even when projects are well-maintained and curated. It's also a chance to review how the devs chose to fix this flaw. It requires tracking the overflow situation, being more careful how it tracks table columns, and -- since we're in C -- having to free memory for any dangling nodes that might be left behind when the parser needs to bail on errors. All in all, more than a one-line fix and makes us think again about what it would mean to track not only the payouts awarded to bounties, but also the developer costs to fixing flaws. Check out the commit at https://github.com/github/cmark-gfm/commit/cf7577d2f74289cb83de0a652afc1a8b08a37036

Our second markdown-based attack for this week -- with an added bonus of path traversal! It's not exactly a vuln that's going to lead to mass compromises, but it's a nice writeup that walks through the ideation, discovery, and refinement from being curious about an error to creating an exploit. What's fun about these markdown attacks is that they're relatively simple and have a high impact on a text-based feature, markdown, that's had parsers around for ages. It's easy to point to the complexity of HTML and JavaScript, where we hardly bat an eye at the idea of yet another vuln in code that parsers such content. But markdown is pretty simple, so seeing these kinds of flaws makes us question whether they were unavoidable human error, if they still could have been prevented by some type of better build analysis, or could have been detected in an automated way by some security tool. That's not to say we want to tune processes to specific flaws, but understand if these kinds of flaws have some underlying attribute that could be targeted. After all, the answer can't just be "use a memory safe language" --in the other article we had a mishandling of integers and heap corruption, but here we have a LFI and path traversal. Be sure to check out the researcher's writeup at https://blog.dixitaditya.com/pwning-a-server-using-markdown

A theme this week is more about a variety of vulns rather than the software they're in. This example boils down to a mistake in using Boolean AND (&&) instead of OR (||) within an if() statement. This example takes my mind to the idea that developers read code far more often than they write code. Hence, it's more important that code be clear and understandable to humans than to compilers or run-time engines. But even with relatively simple code it's still easy to make mistakes and, unfortunately, for those mistakes to have security consequences. I'd be curious what research has been done on logic statements and the mental overheard required for humans to parse them correctly -- both within a clause itself and within the context of a dozen or so lines of code. Are there better patterns to follow for cascading if() statements? Are some patterns easier for humans to read and reason through? Check out the writeup at https://blog.assetnote.io/2022/02/20/logicflaw-dynamicweb-rce/

Yes, we all know open source dependencies have been and will be sources of vulns. Log4j gave us a nice reminder of the pervasiveness (and lack of patch management) for open source. This study helps quantify the problem and prioritize efforts to improve the security practices of popular projects. It covers both npms and non-npm packages. It's a lot of familiar suspects (of course) and some packages that probably should have just been retired as no longer necessary, like isArray. Any time we can remove code, that's a security win. Check out the research page, which links to the PDF of the report, at https://www.linuxfoundation.org/tools/census-ii-of-free-and-open-source-software--application-libraries/

This article appealed to me as an example of appsec as building an application -- and architecture -- to protect the security and privacy of users as opposed to appsec as a matter of just fixing (or preventing) vulns. It's always nice to see security as a product feature. Plus, anything project that includes a "local pizza test" is going to get my attention.

I've linked to a few security-related cryptocurrency articles in the past and now it's time for the first (or one of the first) articles from a VC. This article has an important message, "A FAANG-like company is different from an SMB or your typical Fortune 500 company along many dimensions, including scale needs, stance on building vs. buying, and makeup of the engineering team." These ideas also apply to how companies approach security or security tooling. After all, not everyone has hundreds of dedicated security engineers. If appsec only focuses on how big corporations solve the hard problems of asset inventory, patch management, and software composition analysis (to name just a few), then we risk setting unachievable goals for smaller orgs.

We'll continue to highlight resources and tools that provide appsec capabilities. Bishop Fox put together this list of cloud-focused security tools for identifying flaws and misconfigurations within the major cloud service providers. They can also be a great educational tool if you're building your own home labs to learn about cloud security.

"Use after free" vulnerabilities found in both XSLT and WebGPU

This might not be completely new news, as bypassing WAFs has always been a bit of a (dark) art. The researcher here, though, put GCP at fault as they are not as transparent about how much of the request is inspected by the WAF. WAF inspection is expensive, especially for CSPs.