On November 8, 1996, a hacker called Aleph One published the recipe for exploiting a bug the US government had warned about in 1972. Hackers, engineers, and witnesses explain what memory unsafety is, how it got loose, and what it has cost us, from shuttered hospitals to surveilled activists.
Thirty years ago, on November 8, 1996, a hacker called Aleph One published “Smashing the Stack for Fun and Profit,” the recipe for exploiting a bug the US government had warned about in 1972. Host Sarina Gandy had never heard of memory safety before this project. In this episode, she learns what the bug is, how it got loose, and what it has cost us, from hospitals locked out by WannaCry to an activist targeted through his iPhone. Along the way, she finally tracks down Aleph One.
On mic
Rob Joyce, former NSA cybersecurity director
Dave Weston, Corporate Vice President for AI Security, Microsoft
Bob Lord, Chief Strategy Officer, Software Safety Institute
Lauren Zabierek, co-founder and CEO, Software Safety Institute
Tarah Wheeler, security executive and Oxford doctoral candidate
Pavlina Pavlova
Nicole Perlroth, journalist and author of This Is How They Tell Me the World Ends
Yael Grauer, author of Consumer Reports’ report on the future of memory safety
Adam Shostack, threat modeling expert
Elias Levy, a.k.a. Aleph One
Crispin Cowan, creator of StackGuard
Chapters
0:00 Governments switch off their own websites
2:07 Meet Sarina, and why she’d never heard of this bug
4:30 Why it’s your problem
7:42 WannaCry and the NHS
9:24 Audrey’s story
10:40 The invisible ankle bracelet: Ahmed Mansoor
12:20 What can an ordinary person do?
13:23 How the bug works
16:31 A warning from 1972, and decades of secrecy
19:00 Aleph One and Smashing the Stack
23:11 StackGuard and the Spartans
24:18 Thirty years of defenses
29:34 NotPetya
31:36 AI changes the map
33:40 Why the bug survives
Referenced in this episode
James P. Anderson, Computer Security Technology Planning Study, Volume II (October 1972), the volume with the description quoted in the episode
https://seclab.cs.ucdavis.edu/projects/history/papers/ande72.pdf
Aleph One, “Smashing the Stack for Fun and Profit,” Phrack 49 (1996)
https://phrack.org/issues/49/14.html
CISA and partners, The Case for Memory Safe Roadmaps (December 2023)
https://www.cisa.gov/resources-tools/resources/case-memory-safe-roadmaps
Yael Grauer, Future of Memory Safety: Challenges and Recommendations, Consumer Reports (January 2023)
https://innovation.consumerreports.org/Memory-Safety-Convening-Report-.pdf
Nicole Perlroth, This Is How They Tell Me the World Ends (Bloomsbury, 2021)
https://en.wikipedia.org/wiki/This_Is_How_They_Tell_Me_the_World_Ends
Credits
The Bug We Let Live is a production of the Software Safety Institute, with generous support from Cyber Florida. Produced by Sarina Gandy. Co-produced by Rex Wilson. Learn more at softwaresafety.org.
The Bug We Let Live
Episode 1 Transcript
An audio documentary from the Software Safety Institute, with generous support from Cyber Florida. Timestamps are approximate.
SARINA GANDY 00:02
Last month, governments from Finland to Australia did something almost unheard of. They switched off their own websites on purpose, because they couldn't be sure what would happen if they didn't. There was no foreign army or new weapon, just a mistake. Two of them, buried in software that runs a huge share of the web. One had reportedly been sitting there for 14 years. We've seen how this ends.
In 2017, a mistake of the same kind locked computers in hospitals across England. Within days, it had reached hundreds of thousands of machines in about 150 countries.
TARAH WHEELER 00:45
In the United Kingdom, WannaCry shut down a massive number of NHS facilities for more than three weeks. They were locked out. This is when all those screens started turning red everywhere.
SARINA GANDY 00:59
Here's what really gets me. This isn't a new kind of mistake. Microsoft counted. Google counted. Both found that roughly 70% of their most serious security flaws came from this one kind of mistake. 70%. And it has a name: memory unsafety.
LAUREN ZABIEREK 01:19
Memory unsafety affects anyone who depends on software, which is all of us.
SARINA GANDY 01:24
Honestly, it's old. A U.S. government report warned about this flaw in 1972. In 1996, a hacker called Aleph One published the recipe for how to use it. That was 30 years ago this week, and it's still here.
BOB LORD 01:42
At the end of the day, if we continue down this path, we're going to see more of the same.
SARINA GANDY 01:50
I'm Sarina Gandy. I've spent seven years helping explain security to people, and until this project, I had never even heard of memory safety. In this series, you won't hear a conversation. You'll hear a story, told by the people who have lived it: the hackers who found the bug, the engineers who have fought it, and the people who have witnessed the devastating consequences. You'll join me on my journey of uncovering why this bug matters far beyond our screens. In this first episode: what the bug is, how it got loose, and what it cost us. This is the story of The Bug We Let Live.
ROB JOYCE 02:33
But I'm betting you did know about it. You just didn't know it by name. Like Heartbleed. You heard about the famous Heartbleed issue, right? That was a memory safety leak.
SARINA GANDY 02:43
That's Rob Joyce. Rob spent 34 years at the National Security Agency and later served on the White House National Security Council. He's seen these flaws from both sides, breaking into networks and defending them. He's responding to what I asked him: how he felt about me never having heard of memory safety bugs.
ROB JOYCE 03:00
Well, it makes me a little sad, Sarina. You know, memory safety bugs are kind of the bread and butter for exploit developers across the internet. And I don't think that the general community understands what a big impact this class of vulnerabilities had on both offense and defense across the years.
SARINA GANDY 03:23
Dave Weston is the corporate vice president for AI security at Microsoft. For years, he ran security for Windows, and he's pushed the industry toward solving the memory unsafety problem. In the tech world, he prefers to go by his hacker handle, Dwizzzle. When we spoke, Dave reminded me that I'm not alone in this. I am not the only one who hasn't heard of this problem.
DAVID WESTON 03:45
Within a nerdy industry, this might be the nerdiest. Besides crypto, that's the nerdiest. I'm also a crypto guy, so I don't blame you.
SARINA GANDY 03:59
Crypto here means cryptography, the math of keeping secrets, not cryptocurrency. And Dave is right. Unless you're in the memory safety bubble with Bob Lord and the other memory safety experts of the world, it's probably not something actively on your radar. But unfortunately, that doesn't mean it's not your problem.
BOB LORD 04:19
Sarina, I'm sorry to tell you this is your problem.
SARINA GANDY 04:22
This is Bob Lord himself, the Chief Strategy Officer of the Software Safety Institute. He spent more than 20 years defending some of the most attacked organizations in the world. And most recently, he served as the senior technical advisor at the federal government's Cybersecurity and Infrastructure Security Agency. Now, he's trying to stop the memory unsafety problem at the source.
BOB LORD 04:47
This is the problem of everybody who's using software that has memory unsafe code in it. You know all those alerts that you get to update your phone and your tablets and your laptops, and maybe even devices like your TV, which I got the other day? Well, enterprises that deploy software get even more of those, by a lot. For each of those updates, there's a pretty good chance that one of the reasons the software companies are pushing out new updates is tied to a really old kind of bug called memory unsafety. So this is the memory safety problem. At the end of the day, if we continue down this path, we're going to see more of the same. The movie's gonna have the same ending no matter how many times you watch it. You are gonna be asked to update your laptop and your home routers and all of your devices. And by the way, we all have so many more devices than we've ever had before.
SARINA GANDY 05:41
Lauren Zabierek is the co-founder and CEO of the Software Safety Institute. After 23 years in national security and leading Harvard's Belfer Center cyber project, she helped push the federal government's Secure by Design effort at CISA, the idea that software makers, not users, should carry the burden of safety. Now she's working to get the fix into the software we all depend on.
LAUREN ZABIEREK 06:08
Memory unsafety affects anyone who depends on software, which is all of us. When a memory flaw lets an attacker take control of a device or a system, the consequences can reach far beyond the screen: disrupted hospitals, exposed personal data, or really, disruption of critical services that people rely on every day.
SARINA GANDY 06:32
No big deal, right? Yeah, no. Like I said earlier, this problem isn't something small that we can just sweep under the rug without consequences. Memory unsafety has the power to impact our daily lives, and it accounts for a major share of the security vulnerabilities that we're seeing pop up every day.
ROB JOYCE 06:52
Roughly 70% of the serious vulnerabilities that Microsoft and Google found in their code bases were memory safety issues, right?
SARINA GANDY 06:59
This is NSA's former cyber director, Rob Joyce, again. He told me there was also a study done in 2019 on Apple's products.
ROB JOYCE 07:07
They found like two-thirds of the vulnerabilities in their iPhone software were related to memory safety. It is pervasive out there. We can find so many examples of things that are tied back to this issue.
SARINA GANDY 07:26
The 2017 WannaCry attack is one example you might have heard of that truly shows the potential of memory unsafety. To summarize it, WannaCry was a ransomware attack that moved from computer to computer undetected. The root cause? A memory unsafety flaw. The same thing that Rob Joyce called the bread and butter of exploiters, and the same thing that Bob Lord explained is making us update our devices over and over again.
Tarah Wheeler is a cybersecurity executive and doctoral candidate at Oxford. She studied the psychological impacts of the 2017 WannaCry attack on the people defending Britain's hospitals at the time. She's seen the very real effects that this problem can have.
TARAH WHEELER 08:11
In the United Kingdom, WannaCry shut down a massive number of NHS facilities for more than three weeks. WannaCry caused the cancellation of approximately 13,500 chemotherapy and other critical patient care visits. And to the best estimate of the physician actuary I spoke to at the time, caused 300 severe premature deaths. An unbelievable amount of medical facilities, hospitals, doctors, practitioners, patient care was deeply impacted by it. They were locked out. This is when all those screens started turning red everywhere.
SARINA GANDY 08:49
Once I began talking to the people who have actually watched these attacks for years, it was pretty easy for me to understand the human impact of memory safety flaws. They've had serious effects on real humans like you and me, people just trying to live their lives. One of those people was a woman named Audrey. Pavlina Pavlova runs Critical Cyber, an organization that collects firsthand accounts from people who have lived through cyberattacks. She told me Audrey's story.
PAVLINA PAVLOVA 09:20
So Audrey lives in London, and she was 31 when a knee injury collided with WannaCry, which was one of the most disruptive ransomware attacks in NHS history in the UK. And what she couldn't have known was the attack would leave her waiting far longer for a diagnosis than the injury itself warranted.
SARINA GANDY 09:44
Audrey had torn her ACL and her MCL in a skiing accident. She went in for a scan, but the scan couldn't be read because the hospital systems had been hit by WannaCry.
PAVLINA PAVLOVA 09:54
So her muscles atrophied more than they needed to, and that added a lot of extra time to her recovery. It was months before she could walk without a limp, and years before she could run or go downstairs without pain. She's still dealing with the consequences. Weaker, and the knee simply less stable.
SARINA GANDY 10:19
A two-month delay, and nine years of recovery. And it isn't only hospitals. Nicole Perlroth covered cybersecurity for The New York Times for more than a decade, and she wrote the book This Is How They Tell Me the World Ends, about the market for exactly these kinds of flaws. I asked her what it really means when someone says they got hacked.
NICOLE PERLROTH 10:39
I liken getting hacked to wearing an invisible ankle bracelet. It can give anyone access to your location, your photos. You know, it's your contacts, it's where you are, who you're talking to, what you're saying, and these days, what you're thinking. It's not just your search history, it's your AI chat history. So it's your innermost thoughts.
SARINA GANDY 11:10
In 2016, researchers found that text messages sent to Ahmed Mansoor, a human rights activist in the United Arab Emirates, carried links that exploited memory corruption flaws in the iPhone. Nicole had spent a lot of time talking with him.
NICOLE PERLROTH 11:25
It's the case that I'm probably the most emotional about, because I did spend a significant amount of time speaking with him. And he has been in prison almost ever since, for something as inane as tweeting. He was too scared to move. And in essence, he was on house arrest without being on house arrest. He said something to me like, imagine being labeled and treated as a terrorist when you don't even know how to hold a gun.
SARINA GANDY 12:00
Ahmed's story is devastating, and there are so many more like it. So what can someone like me, just an average person, do about it? Yael Grauer spent years at Consumer Reports helping people stay safe online, and she wrote its report on the future of memory safety. She ran into this problem when she was worried about her own phone.
YAEL GRAUER 12:21
I came across it, actually, as a journalist. Everybody was panicking about Pegasus. I have a friend, Jonathan Rudenberg, and I was like, help me figure out if I have Pegasus on my phone, because I was doing all this reporting on China and I had sources on my phone. They helped me figure it out, and I did not have it on my phone. And then they told me, until we solve memory safety, I can't help you with the Pegasus we don't know about. If you are writing on a phone that's unsafe, there's not like a safe setting. It's not like you can go to your phone settings and change it. It's how your phone is built. You can't tell people you should buy this thing, use this app, or change this setting. It's something that has to be done before they even start using the product.
SARINA GANDY 13:03
No settings to change, nothing we can buy. Whatever protects us has to be built in before the product ever reaches us. What I still didn't understand was, what actually is the bug, and how does it work? Rob Joyce helped explain it to me.
ROB JOYCE 13:19
Probably the easiest way I can break it down is, computer programs set aside a box of a certain size for data. And if nobody checks the size of what goes into that box, the extra spills out into the space near the box. And that could spill into where the computer keeps the program and the instructions about what to do next. So if an attacker can control what spills out, then the attacker really controls what the machine does next.
SARINA GANDY 13:58
So every app is written in a programming language. Two of the oldest and most widely used, C and C++, are fast and powerful, and much of the software we depend on in our daily lives still runs on them. Unfortunately, these programming languages, despite how widely used they are, are the root of the memory unsafety problem. That spillover that Rob described is actually a bug known as a buffer overflow. Microsoft's Dave Weston puts it this way.
DAVID WESTON 14:30
The way I would talk about memory safety is like, try to send your text fast every day, all the time, and never make a spelling mistake. That's what programming with a memory unsafe language is like. No matter how good you are, everyone's gonna make some percentage of mistakes.
SARINA GANDY 14:46
So memory unsafety isn't about better programmers. It's about better tools. Newer programming languages, called memory-safe languages, do all of that checking automatically. And we already have them. Adam Shostack is a leading technology expert who's been called the founder of modern threat modeling, which means thinking like an attacker before the attacker shows up. He spent almost a decade at Microsoft building its threat modeling program. And he helped me understand what exactly this memory unsafety problem has cost.
ADAM SHOSTACK 15:17
We're spending an inordinate amount of energy discovering these vulnerabilities, writing patches for them, putting those packages into update packages, applying those updates, and all of that energy that we are spending to address these problems. Imagine what we would be doing with that time and energy if we had made different decisions around memory safety ten years ago, twenty years ago, forty years ago, fifty years ago. Had we not let the problem fester in secret, we'd be better off.
SARINA GANDY 16:01
Secret. That's a powerful word, and one that takes us all the way back to the start of the memory safety story, when it was simply a new bug being discovered for the first time. In October 1972, a computer security consultant named James Anderson delivered a study to the U.S. Air Force. Adam Shostack quoted the paper in a 2008 blog post, saying:
ADAM SHOSTACK 16:23
One of my long-term interests in security is the ongoing cost of secrecy. My current favorite example is the stack smashing buffer overflow. These were known and understood no later than 1972, and clearly documented in James P. Anderson's Computer Security Technology Planning Study.
SARINA GANDY 16:45
Adam then goes on to share what Anderson actually described in this paper. When I listened closely, I realized that it sounded pretty familiar.
ADAM SHOSTACK 16:54
This is what he wrote: "The code performing this function does not check the source and destination addresses properly, permitting portions of the monitor to be overlaid by the user. This can be used to inject code into the monitor that will permit the user to seize control of the machine."
SARINA GANDY 17:15
Anderson wrote that description in 1972, and it's almost identical to the description of buffer overflows that Rob Joyce gave me 50 years later, in 2026.
ADAM SHOSTACK 17:27
It was tribal knowledge. If you knew the right people, if you talked to someone, they would let you in on this secret. So I think the first problem was the secrecy. And the second problem is, during the period when that secrecy existed, there was an awful lot of important code that was being written. And that important code was written without the benefit of understanding this problem. And when I say important code, I mean things like Unix, Windows, Microsoft Office. And all of that work was done, and now we'd have to redo it to make the changes. Right? And we did a lot of it, but there's more to be done. That's why it's still the case: there's simply so much C code out there.
SARINA GANDY 18:26
So for decades, the people who knew the problem kept it close, and the software the world would run on was built largely in C and C++ by people who had never been told. But the secret wasn't intended as a cover-up. The thinking was that if nobody explains how to break in, nobody can. In 1996, one of those secrets got out. It appeared in Phrack, an online magazine written by and for hackers, in a paper called "Smashing the Stack for Fun and Profit." The author signed it with only his hacker name, Aleph One. In the paper, Aleph One described exactly how to use a buffer overflow in C. The paper spread throughout the security world and changed the memory conversation forever. People built their careers on it, but the person who wrote it stayed out of the story for 30 years. In fact, almost 30 years to the day of this episode releasing. I knew that in order to understand this problem fully, I needed to understand its roots. And there was one person who could really help me with that. One person whose name kept coming up over and over again in conversations about the problem. Bob Lord puts it best.
BOB LORD 19:37
Who the hell is this Aleph One guy? Literally everybody's talking about him. This is a hacker from the '90s. He didn't have a name, it was just Aleph One. I gotta find this guy.
SARINA GANDY 19:51
So we found him.
ELIAS LEVY 19:53
My name is Elias Levy. I was known as Aleph One back in the '90s and maybe early 2000s. That was my hacker handle. The paper was really, to a first approximation, something for me. It was simply me wanting to understand it.
SARINA GANDY 20:15
At the time, a friend was the editor of Phrack magazine and asked if Elias wanted to contribute.
ELIAS LEVY 20:20
And I said, well, I guess I'm working on this, so why not? You know, I didn't discover buffer overflows. Certainly other people were researching how they worked. I just happened to write a pretty good description of how they worked that got widely publicized. Nothing that I wrote about was new. This had all been exercised and demonstrated in a number of exploits on Bugtraq, and people had been sort of toying with it themselves. I think the effect of it was more slow burning, in the sense that it really democratized this little bit of knowledge to a lot of people.
SARINA GANDY 21:03
Once anyone could access and understand the memory unsafety problem, two things happened.
ELIAS LEVY 21:09
Over the next year or two, that's when you sort of see a significant increase in the number of buffer overflow vulnerabilities of this type. So there's definitely a cost to be paid in the short term for making information available that someone can use to harm systems.
SARINA GANDY 21:27
Attackers could now see and exploit the problem in a different way than ever before. But for the first time, defenders like Dave Weston could now see it too.
DAVID WESTON 21:38
This paper really brought widespread attention to the problem, but also, in my opinion, maybe more, it was inspirational to people. That paper was sort of like the instigator, so to speak, of many other people who were gonna go and do other types of data structures. And so I'd see it referenced time and time again. And so yes, it was super instrumental in my development, my understanding, but more importantly, it inspired an entire research community.
SARINA GANDY 22:04
Aleph One wrote that paper for himself. Instead, it set off a flood of engineering work. Here's Adam Shostack.
ADAM SHOSTACK 22:13
The value that Aleph One brought in writing a clear paper that explained it was, he unlocked this flood of engineering work to address it. And so specifically, the work that Crispin Cowan did on StackGuard, the work that folks at Microsoft did on GuardStack, both of them were empowered by the work that Aleph One did in making this visible.
SARINA GANDY 22:43
The developers got to work. They were brilliant, and they won battle after battle. And yet, 30 years later, here we are. But that certainly isn't because nobody tried. Adam mentioned one of those developers by name, Dr. Crispin Cowan. In 1997, a year after Aleph One's paper, Crispin was a computer science professor in Oregon, doing research funded by DARPA, when he built one of the first real defenses. He called it StackGuard.
CRISPIN COWAN 23:12
The one I use to explain it to completely non-technical people, you have to have seen the movie 300, about all those glossy men. And the point of the story is that for Persia to invade Greece, they had to have a hundred thousand men march through this slot that's thirty feet wide. And so the Spartans deployed there. And 300 Spartans cannot defeat a hundred thousand Persians, but they can defeat three hundred Persians. And so they sat there and did it. And the stack canary sits right at the pass where people attempting to do a stack smashing attack, which is what Aleph One's paper describes, have to go through me. And they can't.
SARINA GANDY 24:02
What I really want you to know is this: this problem has not gone ignored. This is Bob Lord.
BOB LORD 24:07
People have really worked on this. So there are numerous efforts to help with developer training, or to find ways to improve code coverage, and building coding guidelines, and fuzzing, and static code analysis, and using these subsets of C that are more memory safe, and using non-executable memory, and control flow integrity, and ASLR, which is address space layout randomization, sandboxing, and hardened memory allocators, and hardware support. People have really tried a lot.
SARINA GANDY 24:42
None of that was in vain. Those defenses have protected us for years. But every one of them sits on top of the same foundation, C and C++. None of these defenses could fix the true problem: the languages.
DAVID WESTON 24:58
About twelve to forty times in my career, I've been like, we have this solved, including rolling out protections that were specifically around this. I've learned the reasons we didn't solve it time and time again, and they're always actually slightly different reasons.
SARINA GANDY 25:13
A different reason every time, but the pattern was the same. Each defense made the attack harder, and attackers adapted. Adam Shostack remembers how simple it once was.
ADAM SHOSTACK 25:25
In 1996, writing exploit code for buffer overflows was trivial once Aleph One's paper came out. If you understood how a computer worked, you could read that paper and write yourself a buffer overflow. And the world was a target-rich environment. There were buffer overflows everywhere you looked. If you had told me it would become an art form in and of itself, with deep technical skills, I would be like, look, this is three lines of Perl. It's six lines of Perl to write the overflow. How complicated does it need to be? I think it's important at a tactical level to respect the amazing engineering work that has gone into making these problems harder to exploit, while simultaneously not losing sight of where we are.
SARINA GANDY 26:33
Every defense bought some time, but the attackers kept finding a way through. Aleph One has watched this game play out for 30 years.
ELIAS LEVY 26:41
It's been a cat-and-mouse game for a very, very long time, where new sort of countermeasures and mitigations are developed, and then attackers are very clever, and they find ways to poke holes in them and jump through a number of hoops.
SARINA GANDY 26:56
Bob Lord asked the obvious question.
BOB LORD 26:58
How can both of those things be true? How can it be true that these mitigations are effective, but we still see these vulnerabilities popping up, and we see them being exploited?
SARINA GANDY 27:09
Part of the answer is that the bug itself never went away. It's still sitting in C and C++ code, and it keeps coming back. Tarah Wheeler has been in security long enough to watch it happen.
TARAH WHEELER 27:21
I wish I had to update my technical knowledge more. I wish that what I learned when I started in technology wasn't still relevant. We don't get new classes of vulnerabilities. What we get is a new syrup on top of a pancake of buffer overflows. We get memory unsafe issues in code that no longer has an excuse for it.
SARINA GANDY 27:44
The WannaCry attack we discussed earlier was a memory flaw, the same kind of mistake Aleph One described in 1996. And Microsoft had already released a fix for it two months earlier.
TARAH WHEELER 27:56
Two months, in fact, before WannaCry, Microsoft had released the patch for it. So anybody that had patched was fine.
SARINA GANDY 28:02
NHS Digital had told hospitals that spring to install the update, but safely getting it onto hospital systems was no simple task. Hospitals run huge interconnected networks. A change to one system could disrupt another, and patching a live clinical system meant weighing the security risk against the possibility of interrupting patient care. Some equipment was in use around the clock.
TARAH WHEELER 28:26
For many of these people, the prior two months had been spent trying to get permission to do the updates. In at least one hospital, they already had provisioned Windows 10 laptops ready to go for everybody in a cabinet, because they couldn't get permission to get them to replace the devices that everybody was holding. The long-tail problem here is that it is the most vulnerable institutions that are the most damaged: rural hospitals, the kinds of organizations that still need to use, like, fifteen-year-old X-ray machines and radiography and diagnosis machines, the kind of stuff that you can't turn off. You can't turn it off and back on again and pull in vendor updates. They can't be patched, because hospitals can't afford to replace them, and they're scared that if they patch them, they will cease to function. And that's a very meaningful fear.
SARINA GANDY 29:19
Six weeks later, on June 27, 2017, it happened again. An attack called NotPetya hit Ukraine first, hidden in an update to tax software that almost every business there used. It spread using the same flaw as WannaCry. Nicole Perlroth went to Ukraine to see what it left behind.
NICOLE PERLROTH 29:40
They all sort of seemed to remember the moment that everything went dark, and, you know, the inability to communicate. They remember screens going dark. They remember not being able to get gas at the gas station. They described not being able to get cash out at the ATMs. They told me about, you know, the inability to buy tickets at the train station. There were small stories, you know, someone who had an online knitting shop, needlepoint shop, I think it was, whose business went down that day. You know, it was, I believe, to this day, the most destructive and costly attack on record.
SARINA GANDY 30:31
Two attacks in six weeks. Both used a flaw that already had a fix. Here's Lauren Zabierek.
LAUREN ZABIEREK 30:38
We just can't keep asking people to patch harder in order to get us out of this mess. You know, it's really striking to me that there are challenges that we can control, and then there are challenges that we can sort of mitigate. And this is one that we can control. This is something that we can solve, and make us all safer for it.
DAVID WESTON 31:05
If we were in any other industry, driving cars, we wouldn't be saying, you know what, we need safer engineering practices. We would implement it. I don't want to be overly dramatic, but depending on the software, human lives could be on the line.
SARINA GANDY 31:19
Now that AI has entered the chat, the math has changed in both directions.
ROB JOYCE 31:25
The good news is AI is exceptionally good at finding those types of issues. The bad news is that they can find those flaws faster than we can fix them. So we've got this period of time where AI is going to shine this bright light on the piles of tech debt we have, and it will take a long time to then rebuild out of that tech debt. On the other side, we're going to be so much more secure, much stronger, with really high-quality code bases.
TARAH WHEELER 31:57
The time is running out where I am willing to accept excuses on older code bases. There's a lot of problems with the modern use of AI, but there are a lot of good ways to use the tools that are available to rewrite memory unsafe code in memory-safe languages. It's 10% of the cost that it was four years ago to do that.
CRISPIN COWAN 32:25
Now it is feasible. Get on with it.
ELIAS LEVY 32:29
We hoped that things would get better faster. Hopefully there's a light at the end of the tunnel pretty soon.
LAUREN ZABIEREK 32:41
The risk is that we keep treating preventable software failures as an acceptable cost of doing business.
SARINA GANDY 32:46
Some of the world's most talented engineers are working on this problem. They've taken me on a journey that leaves me feeling hopeful, and also confused. I believe Elias when he says there's a light at the end of the tunnel. But I was also told this is my problem. I don't write code. I just use it, like all of us. And that's exactly why it's my problem. When it fails, I'm the one who pays. So the question isn't whether a solution exists. It's when we'll start demanding that the software we depend on is built with memory-safe languages. I asked Crispin if it would have surprised him back in 1997 to learn that 30 years later we would still be finding these bugs.
CRISPIN COWAN 33:31
Not in the slightest.
SARINA GANDY 33:33
Why not?
CRISPIN COWAN 33:34
Because that's the behavior I expect from perennial bugs. Look, this pattern keeps on happening. It's like asking if I'm going to be surprised if there's still corruption in government thirty years from now. Nope.
SARINA GANDY 33:58
Secrecy explains why the bug got a head start. It doesn't explain why it's still here, 30 years after that secret got out. Crispin's answer is economics. On the next episode of The Bug We Let Live: why a bug we know how to fix is still cheaper to ship than solve, and how it's still surviving.
SARINA GANDY 34:21
Thank you for listening to The Bug We Let Live. This audio documentary is a production of the Software Safety Institute, with generous support from Cyber Florida. Produced by Sarina Gandy and co-produced by Rex Wilson. For more information, visit softwaresafety.org.