Minimum Safe Distance – ASW #148

Mike Shema

1. Homebrew Security Incident Disclosure
   A clever RCE that took advantage of automation intended to make simple pull requests safe to automatically approved. The attack took advantage of a GitHub Action, showing the importance of understanding not only the impact of code changes on the artifact to be built, but also the tooling that builds those artifacts. It also put successful coordination into coordinated vulnerability disclosure. Read more of the researcher's notes at https://blog.ryotak.me/post/homebrew-security-incident-en/
2. Designing sockfuzzer, a network syscall fuzzer for XNU
   Kernels are newsworthy favorites this week. We covered the "hypocrite commits" from UMN in this week's discussion topic. Security millions of lines of ever-changing code requires more than just code reviews. Fuzzing has been demonstrably successful against the Linux Kernel, as well as large projects like Chrome and smaller projects with large surface areas like video codecs and image libraries. Now more fuzzing is coming to the macOS kernel. We'll expect to see security benefits -- in terms of finding many flaws -- soon within the family of macOS, iOS, and tvOS.
3. New Warning For WhatsApp Users Over Account Suspension ‘Hack’
   Here's a good reminder to two common themes we return to: there's more to security than memory safety and availability is an important peer to confidentiality and integrity. As app security improves the implementation side of things with language choices like Rust, fuzzing, and better compiler defaults, appsec practitioners should continue to broaden their threat models into how workflows can be abused and misused. These are the kinds of "business logic" flaws that deserve a richer discussion than just saying business logic.
4. 7 most common ways to fail at DevSecOps
   Nothing too earth-shattering or insightful on this list, but it does tie into this week's theme of healthy collaboration between security and DevOps. Modern appsec should be very cognizant of the need to communicate business value as much as it should under the business behind the products DevOps teams are working on. And here at ASW, we'll always push against the pitfall of being too risk averse if you're using overly simplified threat models or, even worse, using threat models grounded in some sort of security purity vs. a reasoned evaluation of the context around a feature. It's a short article that goes hand in hand with a similarly brief article on avoiding these failures by closing the gaps in your security and DevOps practices. Check it out at https://devops.com/devsecops-practices-gap-assessment/
5. AirDrop bugs expose Apple users’ email addresses, phone numbers
   Protocols are hard to design well and fun to analyze. This research into AirDrop is a good way to discuss threat models -- when and in what situations are close-proximity attacks of more concern -- and a well-written example of analyzing the effectiveness of privacy safeguards within a protocol. In this case, the researchers demonstrate attention to security, engineering, and UX by recommending improvements that can preserve privacy without degrading the usability of the feature -- something that security and DevOps collaborations should strive for. Check out the research paper at https://www.usenix.org/system/files/sec21fall-heinrich.pdf
6. Data Ordering Attacks
   Cryptographers have long known and appreciated the need for secure random number generators. This paper looks at how training models can be subverted by reordering the data used to train them. It's an intriguing threat model where the adversary need not introduce their own data nor corrupt existing data, but merely order the training data in a way that introduces biases. Plus, "stochastic gradient descent" would be a great name for a cyberpunk synthwave band. Check out the research paper at https://arxiv.org/abs/2104.09667

John Kinsella

1. Leveraging your Role as Technical Product/Project Manager to Improve Application Security
   As we search for others to bring into our circle of securing the applications, many organizations now have "technical" project managers - a position that isn't dev, sec, or ops, but nonetheless can help us think of security by how they prioritize the work we do
2. How we think about safety vs security
   Argo released their 50 page safety report, which includes one page on information security. Useful to read how safety is addressed in a methodological manner, compared to what usually happens in information/application/operational security.
3. Looking at the security of a commercial phone hacking device
   Cellebrite develops tools for governments to gather data from cell phones in their physical possession, more than likely without permission of the phone's owner. Leaving politics aside, Signal happened to find some Cellebrite gear and performed some security analysis on the product. It looks pretty bad...