Unauth’d RCE, “Regexploits”, Post-Spectre Web, & SigStore Signing – ASW #143

Unauthenticated RCE are two words that combine for about the worst case possible in an app vuln. As many have noted, the code has been compiled without support for ASLR or stack cookies, which would have been two things to make exploitation more difficult. Check out these two bug reports for additional insight into related flaws in how the app fails to correctly handle HTTP headers and IPv6 hostnames, https://bugs.chromium.org/p/project-zero/issues/detail?id=2126 and https://bugs.chromium.org/p/project-zero/issues/detail?id=2132. In other words, a simple parsing task turned into a familiar security flaw. We've mentioned Cyber ITL (https://cyber-itl.org) in the past; the safety features they call attention to should be enabled for any compiled software.

Platform provider creates a configuration-based approach to increase custom certificate validation logic security, developers fail to adopt it correctly or ignore it altogether, and users are stuck with apps that are missing common hardening steps. Even though the details in this case are exposure to intermediation attacks, the underlying challenge of turning security recommendations into security implementations applies to many DevOps situations.

In the era of CPU side-channels, browser and web security may boil down to a difficult principle: "Your data must not unexpectedly enter an attacker’s process." The threat of Spectre-style attacks remains relevant and imminent to browsers, with recent blog posts from Google (https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html) and research from academics (https://orenlab.sise.bgu.ac.il/p/PP0) highlighting new work that shows attacks getting better. While there are response headers that apps can set to mitigate some of the danger in terms of what might leak through a side-channel, the underlying problem hasn't been fixed.

Taking a page out of the Certificate Transparency playbook, the SigStore (https://sigstore.dev/what_is_sigstore/) project is looking to create a sort of supply chain of custody that attests to the provenance of software artifacts. Like the Reproducible Builds (https://reproducible-builds.org) we've mentioned in past episodes, this is a step towards ensuring the apps we deploy are what we think they are based on the code we think they built from.

Two of the roles are ancient and not a surprising part of a modern security team, but take a look at the others and consider how much engineering your security team is doing vs. how much it should be doing -- and what types of problems might be best to prioritize.

When we work with regular expressions, it's easy to assume the thing works as we (westerners) think - processing left to right. In reality it's quite complex, and usually more power than we need. As is often the case, that combination leads to potential for misuse...