Root Cause

     

My name is Chris Rohlf. I've been a security and software engineer since 2003. 'Root Cause' is a space to post technical articles about computer security, obscure computer science topics, and US national security policy. You can reach this page at secure.dev or struct.github.io



October 19th, 2024 - A short essay with some thoughts on how AI agents might acquire the funds and resources necessary to replicate and adapt


October 6th, 2024 - A short essay on how AI and cyber security might affect and introduce additional complexity into the broader security dilemma between states


October 4th, 2024 - Comparing the similarities and differences between LLM emergent abilities and weird machines


April 21st, 2024 - A brief analysis of an AI research paper on using LLM based agents to autonomously discover and exploit vulnerabilities 1-day vulnerabilities


April 7th, 2024 - An article that briefly explores the concept of HEMs to enforce AI governance and national security policy.


February 19th, 2024 - A brief analysis of an AI research paper on using LLM based autonomous agents to discover and exploit vulnerabilities in web applications.


September 26th, 2023 - Published on the CSET Georgetown Blog. Memory safety issues remain endemic in cybersecurity and are often seen as a never-ending source of cyber vulnerabilities. But what exactly is memory safety? This explainer explores the topic of Memory Safety, and its origins, for policy makers.


September 23rd, 2023 - A short retrospective on how AI code generation has unfolded for cyber security since 2021.


May 20th, 2023 - Brief notes I wrote on what is required to support a functioning RISC-V system and security implications of architecture and design choices.


November 25th, 2022 - A brief overview of the Memory Tagging implementation in IsoAlloc inspired by MTECheckedPtr and ARM MTE.


April 4th, 2021 - I introduced a new feature to IsoAlloc that can detect uninitialized reads using the userfaultfd syscall. This article covers the technical details of how it works.


March 8th, 2020 - This post describes a new secure memory allocator I wrote that relies on an isolation strategy and other lightweight security checks to detect and mitigate memory safety issues.


July 28th, 2019 - A brief overview of the Map Guard library I published to github and how it uses Intel Memory Protection Keys (MPK) to dynamically mark all code in a process as execute only.


June 15th, 2019 - My review of 'Bytes, Bombs and Spies'. A quick recap of my thoughts on this collection of essays tackling the topic of strategic cyber offense. Originally posted on Dave Aitels CyberSecPolitics blog.


January 1st, 2019 - I wanted to briefly explore cross DSO CFI implementations and whether targeting their fast path 'Shadow' allocations was possible as an exploitation technique (it's not).


April 7th, 2017 - In this article I briefly cover the internals and some weaknesses of OilPan, Google's Garbage Collected heap for Chrome.


January 22, 2016 - In this article I dive into how PartitionAlloc works by first explaining its origins and how some of its basic allocation code paths work. I also introduce some basic hardening measures by randomizing the freelist and adding some basic double free protection.


September 9th, 2015 - In this brief article I explain how I ported the Chrome PDFium library to use the PartitionAlloc heap allocator. This brings the benefits of fine graned memory separation for objects allocated inside the PDFium code.


A quick look at the OpenSSL out of bounds read vulnerability from 2014. The internet went into panic mode and blamed the OpenSSL project for maintaining their own malloc. But this, like most things on the internet, was rooted in false assumptions.


Originally posted in 2010 on my first blog, this article explores how ptmalloc2 in glibc 2.11 attempted to stop the obscure House of Mind heap exploitation technique.


Originally posted in 2010 on my first blog, this article looks at an interesting type confusion vulnerability I discovered in WebKit. This was an extremely flexible vulnerability that allowed for an abitrary length read from an arbitrary address.