Rust in Android, Vuln Disclosure, Postmortems, & BootHole Follow-Up – ASW #147
Full episode and show notes
This week in the AppSec News, Mike and John discuss Rust in Android and the Linux kernel, vuln disclosure policy changes from Project Zero, security and DevOps collaboration, XSS with NULL, & a BootHole follow-up!
Do you have a specific guest or topic that you want us to cover on one of the shows? Submit your suggestions for guests by visiting https://securityweekly.com/guests and completing the form! We review suggestions monthly and will reach out to you once reviewed!
Security Partner at Square
- 1. Google’s Project Zero updates vulnerability disclosure rules to add patch cushionGoogle 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.
- 3. BootHole: How It started, How It’s GoingWe 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
- 4. Expiration Date 4-6-2021"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.
- 5. Backdoored developer tool that stole credentials escaped notice for 3 monthsMore 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.
- 6. Google backs new security standard for smartphone VPN appsSet 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.
- 7. Google backs effort to bring Rust to the Linux kernelIn 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.
Co-founder & CTO at Cysense
- 1. Google is now writing low-level Android code in Rust2021 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.
- 2. A VC says we should stop forcing security and engineering to collaborate…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