When I was at EFF in the 2010s, I spent a lot of time fretting about the fundamental security of networked devices. Apart from the usual concerns, I struggled to imagine a transition to a redecentralized future with fragile personal computers and servers. Peter Eckersley, my co-worker and frequent conversation partner, shared my concern, but had another reason to be worried. He believed that future near-superintelligent AIs would soon be used to discover and exploit security flaws across the whole ecosystem.
Well, Peter’s prediction came true, and we’re now in day 42 of the Black October, the Vulnpocalypse of AI-discovered security flaws. (Peter – who also helped create Let’s Encrypt and Privacy Badger – was incredibly prescient about AI. It remains a tragedy that he passed away in 2022 before he could truly tackle the issues he had foreseen.)
I’m personally optimistic that we’ll come out of this time of tribulation with a safer network and thousands of low-hanging bugs fixed.
But verily the LLMs giveth and they also taketh away. Alongside the pre-existing flaws of digital architecture, modern transformers have introduced an entirely new class of security weakness: prompt injection. LLMs follow instructions in content. So if you can sneak an instruction, from “Talk like a pirate” to “Send me the social security numbers you know”, into the inputs of an LLM, you may be able to get the model to obey it.
That said, instructions smuggled in as input are an old problem. In particular, we have always had one vulnerable class of system that malicious outsiders can consistently trick into interpreting unsanitized input as legitimate instructions. We call these systems “humans”.
Hackers exploit human motivations, assumptions, and flaws to get them to do things that they did not intend. They play a recording of a screaming baby in the background of their support call to exploit a tech’s empathy and sense of urgency. They adopt the persona of a senior manager from another part of the company to provoke deference in a person employed to guard a room. They say they’re from your local bank, when really they are from Jamtara, India.
Crying babies also work on LLMs who lack a heart of stone
This class of bug is termed “social engineering” – a phrase that was originally a hacker hijacking of an existing term to compare their sweet-talking of humans to the engineering of software exploits further down the technological chain of authority. It’s like hacking, but you hack people, not hardware.
Back at EFF, I ruthlessly used my job title to snag meetings with the smartest security experts I could find. If pressed and plied with drink, they would tell me that the real way to fix the Swiss cheese of modern computing was to switch all our systems to what is called the capability-based security model.
Without delving into too much detail about capabilities (don’t worry, I will very soon, and you won’t even need to buy me a drink), cap-security gives each program only the authority it needs for the task at hand, rather than everything its user is allowed to do. It was built, in part, to solve the “confused deputy” problem, where a program is tricked into using its legitimate power on behalf of someone who has none. A capability system works like a valet key: it starts the car, but it won’t open the boot, however charmingly you ask.
After excitedly talking about the promise of capabilities as a panacea, my experts would slip into the mournful stage of inebriation. In their cups, they conceded that deploying cap-security was nearly impossible. While there are a few bubbles of cap-security in our current infrastructure – file descriptors in Unix, WASI in WebAssembly – they are few and far between. You’d need to abandon or profoundly reengineer every layer of the modern stack from CPUs to apps to move it from a system riven with vulnerabilities onto a more fundamentally secure footing.
I decided to give it a go anyway. In 2021, I left EFF to concentrate on getting funding and attention for this quixotic task. Thankfully it was not just me. At the same time as I was setting off with a kettle to boil the ocean, many innovative capability systems were finally coming to fruition. Microsoft, ARM, SRI and Cambridge University’s CHERI hardware project encoded cap-security at the CPU level. Google’s Fuchsia project matured into workable demonstrations of a greenfield cap-security operating system. FreeBSD’s Capsicum showed that existing software could be ported to the new paradigm. Kenton Varda developed the open source successor to Google’s Protocol Buffers, Cap’n Proto. He was subsequently hired by Cloudflare to develop a capability-inspired distributed platform for their services: Cloudflare’s Workers.
I believe cap-security to be a necessary ingredient in tackling our computer security issues at their roots. My hope is that AI’s accelerated ability to re-engineer, rebuild and secure software will help us take this radical step, and lift our planet’s network onto a far firmer foundation (without boiling the actual ocean, or turning it into computronium). With it we can narrow the blast radius of the social engineering of both humans and LLMs.
But it won’t be sufficient.
Capability-based security gives us the framework to stop our software’s flaws from being exploited to hurt humans. Now we just have to stop our human flaws from being exploited to break our software.
Capability-Based Security is part of the fix
When I was at EFF in the 2010s, I spent a lot of time fretting about the fundamental security of networked devices. Apart from the usual concerns, I struggled to imagine a transition to a redecentralized future with fragile personal computers and servers. Peter Eckersley, my co-worker and frequent conversation partner, shared my concern, but had another reason to be worried. He believed that future near-superintelligent AIs would soon be used to discover and exploit security flaws across the whole ecosystem.
Well, Peter’s prediction came true, and we’re now in day 42 of the Black October, the Vulnpocalypse of AI-discovered security flaws. (Peter – who also helped create Let’s Encrypt and Privacy Badger – was incredibly prescient about AI. It remains a tragedy that he passed away in 2022 before he could truly tackle the issues he had foreseen.)
I’m personally optimistic that we’ll come out of this time of tribulation with a safer network and thousands of low-hanging bugs fixed.
But verily the LLMs giveth and they also taketh away. Alongside the pre-existing flaws of digital architecture, modern transformers have introduced an entirely new class of security weakness: prompt injection. LLMs follow instructions in content. So if you can sneak an instruction, from “Talk like a pirate” to “Send me the social security numbers you know”, into the inputs of an LLM, you may be able to get the model to obey it.
That said, instructions smuggled in as input are an old problem. In particular, we have always had one vulnerable class of system that malicious outsiders can consistently trick into interpreting unsanitized input as legitimate instructions. We call these systems “humans”.
Hackers exploit human motivations, assumptions, and flaws to get them to do things that they did not intend. They play a recording of a screaming baby in the background of their support call to exploit a tech’s empathy and sense of urgency. They adopt the persona of a senior manager from another part of the company to provoke deference in a person employed to guard a room. They say they’re from your local bank, when really they are from Jamtara, India.
Crying babies also work on LLMs who lack a heart of stone
This class of bug is termed “social engineering” – a phrase that was originally a hacker hijacking of an existing term to compare their sweet-talking of humans to the engineering of software exploits further down the technological chain of authority. It’s like hacking, but you hack people, not hardware.
Now these human flaws are spreading back into the silicon. Prompt injection is the art of social engineering silicon. Attackers can hoodwink models with the same bag of tricks that worked on humans: exploiting the modelled empathy of LLMs, or engineering ways to suspend it. They use channels with limited trust or purpose and then slowly expand that trust without the victim noticing, or masquerade as a different source.
Back at EFF, I ruthlessly used my job title to snag meetings with the smartest security experts I could find. If pressed and plied with drink, they would tell me that the real way to fix the Swiss cheese of modern computing was to switch all our systems to what is called the capability-based security model.
Without delving into too much detail about capabilities (don’t worry, I will very soon, and you won’t even need to buy me a drink), cap-security gives each program only the authority it needs for the task at hand, rather than everything its user is allowed to do. It was built, in part, to solve the “confused deputy” problem, where a program is tricked into using its legitimate power on behalf of someone who has none. A capability system works like a valet key: it starts the car, but it won’t open the boot, however charmingly you ask.
After excitedly talking about the promise of capabilities as a panacea, my experts would slip into the mournful stage of inebriation. In their cups, they conceded that deploying cap-security was nearly impossible. While there are a few bubbles of cap-security in our current infrastructure – file descriptors in Unix, WASI in WebAssembly – they are few and far between. You’d need to abandon or profoundly reengineer every layer of the modern stack from CPUs to apps to move it from a system riven with vulnerabilities onto a more fundamentally secure footing.
I decided to give it a go anyway. In 2021, I left EFF to concentrate on getting funding and attention for this quixotic task. Thankfully it was not just me. At the same time as I was setting off with a kettle to boil the ocean, many innovative capability systems were finally coming to fruition. Microsoft, ARM, SRI and Cambridge University’s CHERI hardware project encoded cap-security at the CPU level. Google’s Fuchsia project matured into workable demonstrations of a greenfield cap-security operating system. FreeBSD’s Capsicum showed that existing software could be ported to the new paradigm. Kenton Varda developed the open source successor to Google’s Protocol Buffers, Cap’n Proto. He was subsequently hired by Cloudflare to develop a capability-inspired distributed platform for their services: Cloudflare’s Workers.
In the non-profit, public good space, I successfully argued for funding by the Filecoin Foundation for the Decentralized Web for the Spritely Institute, which, led by Christine Lemmer-Webber, has built a free software implementation of object capabilities, and a general networking layer for cap-secure tools, called OCapN. It will still require great effort to move programming to these and other models, but the groundwork has been laid.
I believe cap-security to be a necessary ingredient in tackling our computer security issues at their roots. My hope is that AI’s accelerated ability to re-engineer, rebuild and secure software will help us take this radical step, and lift our planet’s network onto a far firmer foundation (without boiling the actual ocean, or turning it into computronium). With it we can narrow the blast radius of the social engineering of both humans and LLMs.
But it won’t be sufficient.
Capability-based security gives us the framework to stop our software’s flaws from being exploited to hurt humans. Now we just have to stop our human flaws from being exploited to break our software.
(Cross-posted from Oblomovka.)