That Will Bite Ya – ASW #147

Google Project Zero is tweaking their disclosure policy again this year. This time adding more consideration for users to have time to apply patches. In general, vuln disclosure is the trolley problem of the infosec world -- where dilemmas have contrived constraints in order to illuminate a decision process. In this case, Project Zero continues their commendable job of navigating this space in a transparent manner and with explanations of how and why they institute changes. Read their full explanation at https://googleprojectzero.blogspot.com/2021/04/policy-and-disclosure-2021-edition.html While the sheer volume of impacted users, devices, and systems have increased by orders of magnitude over two decades of disclosure discussions, many of the arguments and considerations have remained relatively static. There's the nascent "Full Disclosure Policy" from Rain Forest Puppy in 2001 (https://dl.packetstormsecurity.net/papers/general/rfpolicy-2.0.txt) and the formative work by Katie Moussouris at Microsoft Security Response Center in 2010 about Coordinated Vulnerability Disclosure (https://docs.microsoft.com/en-us/archive/blogs/ecostrat/coordinated-vulnerability-disclosure-bringing-balance-to-the-force). Moussouris continued that work in creating the ISO/IEC 29147 standard for Vulnerability Disclosure -- also notable for her work in making this a rare ISO standard freely available.

The typical ASW stance is to yawn at XSS, the cockroaches of web app vulns. It's hard to ignore a $35k bounty, let alone an excellent writeup on the researcher's thought process. But what really stood out was one detail that made this attack really work -- a NULL byte inclusion! Long gone are the days when %00 could bypass Perl and Bash CGI scripts (yes, even Bash was the server-side JavaScript of days gone by). So it's cool to see researchers tying together simple concepts into clever, and profitable, vulns!

We first covered BootHole back in episode 117 in August 2020 -- which is coincidentally also the number of patches that came out of those flaws. Many months later it's interesting to see what's been fixed, what hasn't, and what kind of new research and vuln classes have emerged from the initial disclosure. Secure Boot and roots of trust are critical to everything from supply chain to the cloud to personal devices, so it's important to understand where the shaky bits of a foundation are and distinguish implementation vulns from fundamental design flaws. Another challenging aspect is handling revocation in a highly constrained storage environment. Check out the secure and simple (despite a few bugs along the way) approach at https://github.com/rhboot/shim/blob/main/SBAT.md

"On April 6, 2021, we had a wildcard TLS certificate unexpectedly expire." It's the opening sentence of a familiar story and easily one where you could replace the date with one from a few decades back and it'd read just the same. It's a good example of a well-known issue -- certs have always expired -- that nonetheless still manages to expose weaknesses in process and automation. Managing certs is a great example of the difference in stating problems vs. presenting solutions. For the longest time, appsec presentations only ever just reiterated, "Use HTTPS everywhere. Turn on HTTPS!". Then an org like Let's Encrypt came along and not only provided free certs, but more importantly provided the means to manage certs through automation and the ACME protocol (https://letsencrypt.org). In other words, a DevOps approach to managing certs and understanding the engineering needed to do it right is more effective than eternally lamenting the lack of HTTPS.

More surreptitious supply chain changes, this time to a code coverage capability. What stands out once again is not that this happened, but that the duration from infection to detection was so long -- three months. It should force appsec and DevOps teams to re-evaluate how they ensure trust and integrity in their tooling, as well as determine if controls like egress filtering or simple network monitoring might have helped.

Set aside the topic of VPNs and what threat models they do (and don't) address. The interesting bit in this article is the emerging Internet of Secure Things alliance and what positive impact it may have in this area. Many of the principles covered in their Android and Mobile app profiles are applicable to non-IoT systems. It's always worth looking at other security domains to see how they're addressing common threats and flaws. Check out more at https://www.ioxtalliance.org/certifying-your-device.

In addition to bringing Rust into Android (check out this episode's other article about that), Google is also interested in seeing more Rust in the Linux kernel. The approach makes sense -- rather than expect to rewrite 30 million lines of code, kernel devs are looking at boundaries where it's smartest to introduce new code in Rust. Drivers are a great candidate since they're a common source of bugs and have relatively well-defined interfaces.

2021 seems to be shaping up as a year of appsec trends, and one of the ones we're seeing is the targeted use of Rust to fight security issues.

We've talked a lot about getting security and eng to work together. One could say it's what this podcast is about. So trying to keep an open mind, let's look at a perspective demanding the opposite approach