Buffer overflows persist because unsafe languages like C and C++ power most operating systems, embedded devices, and legacy infrastructure. Memory-safe alternatives exist, but rewriting decades of production code is expensive and risky. The attack class is old. The incentive to fix it at scale is newer.
Pithy Security | Cybersecurity FAQs – The Details
Question: Why do buffer overflows still exist in modern software?
Asked by: Perplexity AI
Answered by: Mike D (MrComputerScience) from Pithy Security.
Why C and C++ Keep Producing Exploitable Memory Bugs
Buffer overflows happen when a program writes more data to a memory buffer than it was allocated to hold, spilling into adjacent memory. C and C++ give developers direct memory access with almost no guardrails. No automatic bounds checking. No garbage collection. You get speed and control, and you carry the full weight of getting it right every time. The Linux kernel, Windows internals, macOS core components, most embedded firmware, and a huge chunk of enterprise software are written in C or C++. NIST’s National Vulnerability Database still logs buffer overflow vulnerabilities regularly in 2025, including in widely deployed products. The language isn’t going away because the software built on it isn’t going away.
The Real Cost of Migrating Away From Unsafe Languages
Memory-safe languages like Rust, Go, and Swift eliminate entire classes of buffer overflow vulnerabilities by design. The NSA and CISA have both issued guidance recommending memory-safe languages for new development. So why hasn’t the industry just switched? Migration cost. A major OS or embedded system rewrite isn’t a sprint. It takes years, introduces new bugs, and requires retesting everything. The Android team at Google spent years incrementally introducing Rust into AOSP and reported a significant drop in memory safety vulnerabilities in new code. That’s a win. But “new code” is the key phrase. The legacy codebase underneath most production systems is still C, and it will be for a long time.
When Modern Mitigations Actually Contain Overflow Damage
Modern compilers and OS features do make exploitation harder. Stack canaries detect stack corruption before a function returns. Address Space Layout Randomization (ASLR) randomizes memory layout to defeat hardcoded exploit offsets. Data Execution Prevention (DEP/NX) blocks shellcode execution in data segments. Microsoft’s Control Flow Guard and similar technologies add another layer. These mitigations matter. Exploitation of buffer overflows today typically requires chaining multiple techniques, including return-oriented programming (ROP), to bypass them. That raises the attacker’s skill floor. But it doesn’t eliminate the vulnerability. Mitigations buy time and raise costs. They don’t fix the root cause. Attackers with enough motivation and skill still get through, as CVEs in products like OpenSSL, curl, and core Windows components continue to demonstrate.
What This Means For You
- Audit your software inventory for C/C++ components that handle untrusted input, focusing on network-facing services and parsing libraries first.
- Verify that compiler-level protections (stack canaries, ASLR, DEP) are enabled in your build pipelines and not disabled for performance reasons.
- Prioritize patching buffer overflow CVEs rated critical or high in CISA’s Known Exploited Vulnerabilities catalog over lower-severity findings.
- Evaluate any new internal development for memory-safe language options, especially for components that process external data or user input.
Related Questions
Want Cybersecurity Breakdowns Like This Every Week?
Subscribe to Pithy Security (Free) → pithysecurity.substack.com