Key Moments
Want to know something specific about what's covered?
We've already dissected every moment. Ask and we will deliver (with timestamps).
Key Moments
Computer security is fundamentally broken, not just in its current state but by design, leading to widespread compromise and a reliance on constant patching rather than inherent security.
Key Insights
Two-thirds of all desktops are owned, with malware installed, and hundreds of thousands of bots active monthly.
Buffer overflows, first discussed in 1974 and practically demonstrated in 1988, remain a significant vulnerability, even after decades of attempts to mitigate them.
Despite efforts to improve security, the top new vulnerabilities in the last five years are related to web scripting and programming errors like cross-site scripting, SQL injection, and PHP include, with no overall improvement in vulnerability counts.
Time-sharing systems, designed in the 1960s for massive mainframes, created security models (like access control lists) that are ill-suited for today's single-user, multi-functional computing environments.
Microkernels, while conceptually appealing for minimizing privileged code, historically suffered from severe performance issues due to excessive context switching, requiring 3-4 context switches for simple inter-process communication.
The presenter advocates for a 'separation of privileges' model, breaking down applications into small, independently verifiable tasks with minimal privileges, as a best practice for current technology.
Security is not just broken, it's accepted as broken
The speaker, Rik Farrow, argues that computer security is fundamentally broken and has been for a long time. He highlights that the acceptance of this broken state is the most unacceptable aspect. Evidence of this widespread insecurity includes two-thirds of all desktops being compromised, hundreds of thousands of active bots, and the normalization of monthly security patches. A particularly concerning design flaw is that web browsers, by their very nature, are built to execute remote code, making them inherently risky when visiting unknown websites.
Insecurity in depth: Layers upon layers of complexity
Modern operating systems and applications are built on layers of software, creating 'insecurity in depth.' Kernels alone can have millions of lines of code (e.g., FreeBSD with 3 million, Linux with over 5 million). With a typical defect rate of 3-6 defects per thousand lines of code, this translates to tens of thousands of defects. Furthermore, the extended use of third-party device drivers and multiple APIs means that even the OS vendor may not have full control over the code running with kernel privileges. This complexity makes it nearly impossible to find and fix all vulnerabilities. The fundamental issue remains that anything running with root or local system privileges has total control over memory and operations, making any exploit within these privileged contexts catastrophic.
Anatomy of a persistent vulnerability: Buffer overflows
Buffer overflows, a vulnerability first discussed at the NSA in 1974 and practically demonstrated in the 1988 Internet Worm, have remained a critical issue for decades. The concept became widely understood and exploited after a 1996 paper explained how to 'smash the stack.' Early mitigation attempts involved simple tools like 'grep' to find problematic functions like 'string copy' and 'get s,' and more sophisticated software like 'stackguard' which introduced canaries to detect stack corruption. Hardware solutions like 'no-execute' (NX) bits were also developed to prevent code execution from the stack, a problem exacerbated by older Intel and AMD processor designs. Despite these efforts, buffer overflows have only recently fallen from the top vulnerability spot to fourth place, supplanted by web scripting and programming errors.
The misapplication of time-sharing security models
Farrow traces modern security models back to the early days of computing and time-sharing systems in the 1960s. The goal then was to allow multiple users to share expensive mainframe resources securely, requiring protection between users' processes and their data. Techniques developed included segmentation and paging for process protection, and access control lists (ACLs) for file protection, concepts derived from systems like Multics. While these mechanisms were designed for sharing, most computers today are single-user machines. Applying the complex ACLs and multi-level security (MLS) models, originally designed for government and defense classified systems, to personal computers is a poor match and creates unnecessary complexity and overhead without solving the core security problems, especially those originating from user-facing applications like web browsers.
Searching for solutions: MLS, Capabilities, Microkernels, and More
The talk explores various proposed security solutions. Multi-level secure systems (MLS), like SElinux and AppArmor, aim to enforce complex security policies but are extremely difficult to use and configure, failing to protect users from their own web browsers. Capabilities, a model where programs are granted specific permissions to perform actions, were explored but never widely adopted, often due to lack of networking support (e.g., the Eros OS). Microkernels, designed to minimize the kernel's privileged code, faced significant performance issues due to excessive context switching between user space and the kernel. Hybrid kernels and experimental systems like Asbestos and Singularity are also discussed, with varying degrees of success and inherent complexities. Virtual machines offer isolation, but the security of the guest OS remains a concern.
The promise and peril of separation of privileges
Farrow presents 'separation of privileges' as a practical best practice for today's technology. This involves breaking down applications into smaller, simpler modules, each performing a limited function and running with minimal privileges. Postfix, a mail transfer agent, is cited as an example where functionality like listening on port 25 is handled by a privileged process, but email parsing and routing are performed by non-privileged child processes. This reduces the attack surface and the potential impact of a compromise. The core idea is to design for least privilege, especially for components that listen on network sockets, which inherently have a large attack surface.
A blue-sky vision: Multi-core processors and a truly modular OS
Looking ahead, Farrow proposes a radical redesign enabled by multi-core processors. His vision involves treating each small task (derived from the separation of privileges concept) as an independent entity with its own memory space, potentially running on dedicated CPU cores. The microkernel would be confined to one core, managed by a high-performance scheduler that minimizes context switching. Inter-process communication (IPC) would be optimized through shared memory and page mapping, avoiding data copying. This would allow for fine-grained control, where a JPG renderer, for example, could only process image data and output bits to the display, unable to access passwords or make network calls. This approach aims to address the historical performance issues of microkernels and create a system where security is built into the fundamental design of tasks rather than being an add-on.
The persistent challenge of human error and complex interfaces
Despite technological advancements, human error and the complexity of security interfaces remain significant hurdles. The presenter notes that users, when presented with dialog boxes or notifications, tend to click 'continue' without fully understanding the implications, making interactive security prompts unreliable. Furthermore, many current security problems, like SQL injection and cross-site scripting, operate at a higher level of application interaction and are not directly addressed by low-level kernel security. Farrow admits he doesn't have a definitive solution for these issues, likening the challenge to writing code without buffer overflows – aspirational but difficult to achieve for average programmers. He concludes that truly secure systems require thinking outside the historical box and moving beyond the limitations of past designs.
Mentioned in This Episode
●Products
●Software & Apps
●Companies
●Organizations
●Concepts
●People Referenced
Common Questions
The speaker notes that the same security problems persist repeatedly, and worse, society has accepted this broken state, which he finds unacceptable. This indicates a fundamental, unresolved issue in security practices.
Topics
Mentioned in this video
Processors mentioned in relation to the difficulty of implementing no-execute stacks until recently.
Processors mentioned in relation to the difficulty of implementing no-execute stacks until recently.
Mentioned in relation to its Trusted Computing Initiative, security patches, and proprietary schemes for stack protection.
Mentioned as a company that could potentially 'buy' a solution to security problems, and whose search function converts PDFs to HTML.
Mentioned as a database that can be targeted by SQL injection attacks.
Mentioned as a vendor with multiple APIs and as an example of an operating system (macOS X) that is not truly microkernel-based.
Inventor of the C programming language, which included features like string copy and unbounded arrays, contributing to security issues.
Co-author of a paper showing that OpenBSD has improved over time with a decline in new vulnerabilities.
The speaker, who has been involved in security since 1984 and is giving this talk due to persistent security problems.
Developer of the EROS operating system, a capabilities-based system.
The original author of Sendmail, who developed it as a student project in the early 1980s.
Creator of djbdns, mentioned as an example of a developer whose work is highly respected but also personally difficult to deal with.
Authored the paper 'Smashing the Stack for Fun and Profit' in 1996, popularizing the concept of buffer overflows.
Author of the 1988 Internet Worm, and involved in the experimental operating system 'Asbestos'.
Also known as Aleph One, author of 'Smashing the Stack for Fun and Profit'.
Presented as the closest example of a true microkernel, running device drivers as services and incorporating capabilities.
Mentioned alongside Java as a language that could potentially be used for security.
An experimental Microsoft project, described as an experimental microkernel design where everything runs in ring zero and relies on language features for security.
An older mail transfer agent with multiple buffer overflow vulnerabilities discovered in 2003, highlighting the need for alternatives like Postfix.
An operating system claimed to have a microkernel but is actually a hybrid approach, blending Mach 3 and BSD, and is not truly 'micro'.
Mentioned as a database that can be targeted by SQL injection attacks.
Mentioned as a concerning example of software with a large attack surface, related to Bonjour.
Cited as an example of an operating system kernel with approximately three million lines of code.
Cited in a study as showing improvement over time in terms of reducing flaws and seeing a slight decline in new vulnerabilities.
Computer Time Sharing System, an early time-sharing system developed around the same time as Multics.
Mentioned as an example of a programming language with an intuitive syntax.
A Microsoft project where device drivers and applications run as bytecode, aiming for security through restricted code and language features.
The speaker's website where references and the presentation slides can be found.
A mail transfer agent that serves as a good example of separation of privileges; it was rewritten from scratch to avoid the vulnerabilities in Sendmail.
A capabilities-based operating system developed by Jonathan Shapiro. It's considered a nice example but was limited by the lack of networking.
Related to mdns responder, mentioned as an example of a technology that should be compartmentalized due to its attack surface.
A tool that references CVEs for vulnerabilities.
An operating system that evolved from Multics, featuring a user/group/other permission model.
Software invented around 1998 that uses a 'canary' to detect stack corruption.
A platform that references CVEs for vulnerabilities.
A 'bytecode' language that, despite its security design, has had security issues like reflection allowing access to private methods.
Mentioned as an operating system that uses access control lists and runs services as 'local system'.
A RISC processor architecture the speaker has worked on.
An early system that used memory segmentation for process protection.
An early system that used paging (virtual memory) for process protection.
Cited as an example of an operating system kernel with over five million lines of code.
An influential time-sharing operating system developed in 1965, from which Unix and Linux descended. Introduced concepts like access control lists.
An experimental operating system discussed for its data labeling and mandatory/discretionary access control features.
A tool presented as a reference monitor that captures system calls and canonicalizes path names to create security profiles.
A microkernel (part of macOS X) that is considered quite large, contradicting the minimalist ideal of microkernels.
A RISC processor architecture the speaker has worked on (misspoken as 'i-64').
An early microprocessor that followed the Intel 4004, mentioned as part of the lineage of CPU design.
A real microkernel project with a small lines of code, but requiring additional layers like the Linux API and networking stack to be useful.
A RISC processor architecture the speaker has worked on.
The first commercial microprocessor, used as a basis for modern CPUs according to the speaker.
More from GoogleTalksArchive
View all 48 summaries
58 minEverything is Miscellaneous
54 minStatistical Aspects of Data Mining (Stats 202) Day 7
45 minKey Phrase Indexing With Controlled Vocabularies
63 minMysteries of the Human Genome
Ask anything from this episode.
Save it, chat with it, and connect it to Claude or ChatGPT. Get cited answers from the actual content — and build your own knowledge base of every podcast and video you care about.
Get Started Free