Rust in the Linux Kernel, Uber Security Verdict, Prototype Pollution, PHP Composer – ASW #215

The appsec angle to this story is the use and misuse of bug bounty programs -- they're not a mechanism for laundering and silencing breaches. It's also a topic that has received a variety of framing for a story that is ultimately about lying to the FTC. It doesn't seem like the harbinger of doom for CISOs that many headlines make it out to be.

Rust finally gets a merge into the mainline Linux kernel. It represents about a year and a half of work from over 170 contributors. So, this is both excellent to see for the future of memory safety in the Linux kernel, and a slightly daunting amount of effort from the perspective of refactoring an existing code base. Note how a significant amount of the commit is wrangling makefiles and build scripts to support Rust.

The main appsec takeaway here is how overwhelmingly remote command execution vulns make up this list. Yes, memory safety issues plague plenty of apps and lead to exploitable vulns, but memory safety clearly isn't the only critical vuln class out there. Plus, the list includes a path traversal vuln! Read more in the PDF report at https://media.defense.gov/2022/Oct/06/2003092365/-1/-1/0/Joint_CSA_Top_CVEs_Exploited_by_PRC_cyber_actors_.PDF

Including this article as an educational followup to a recent prototype pollution flaw we covered. A lot of times the articles we find on vulns include good background and explanations on the underlying problem. But sometimes it's helpful to have articles dedicated to explaining a class of vulns rather than a specific instance of one. Also check out another resource on this topic at https://labs.withsecure.com/publications/prototype-pollution-primer-for-pentesters-and-programmers

Yes, yet another example of supply chain issues -- this time in PHP. But I grabbed this article and the other about about the JavaScript vm2 flaw for a tangent on how articles frame the impact or criticality of vulns they cover. In this case, we're told that Composer "serves 2 billion software packages every month", which is impressively large and sounds like a pretty fundamental tool in the PHP supply chain. At what point do numbers matter? Or not matter? This is like repeating the CVSS rating of a vuln. What would be more informative to readers?

The article tells us vm2 "has more than four million downloads per week", which sounds like a similarly large scale to the PHP vuln also mentioned this episode. What would be a more interesting metric than downloads or installs? What would be more useful than rattling off CVSS numbers? But that meta-question aside, this is also an interesting vuln for an RCE that has a one-line fix (and about seven lines of test code for the fix), which brings up a question about code review and how difficult it can be to review code for correctness, let alone for subtle security flaws.

One of the news sources I review every week is the CloudSecList (https://cloudseclist.com/). The maintainer of the list also curates CloudSecDocs, which covers a variety of hardening and security aspects of cloud computing.

This article is from August 2020, but it remains relevant and fits with the career theme we've touched on in a few recent episodes.

Google invested in good production quality for a series of videos about the different security efforts within the company and the various teams tasked with keeping the org and its products safe. For an appsec focus, check out episodes 4 and 5 on bug bounties and the Project Zero team.