Secure Coding mailing list archives
What's the next tech problem to be solved in software security?
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 8 Jun 2007 11:03:12 -0400 (EDT)
On Thu, 7 Jun 2007, Steven M. Christey wrote: | On Wed, 6 Jun 2007, Wietse Venema wrote: | | > more and more people, with less and less experience, will be | > "programming" computer systems. | > | > The challenge is to provide environments that allow less experienced | > people to "program" computer systems without introducing gaping | > holes or other unexpected behavior. | | I completely agree with this. This is a grand challenge for software | security, so maybe it's not the NEXT problem. There's a lot of | tentative work in this area - safe strings in C, SafeInt, | StackGuard/FormatGuard/etc., non-executable data segments, security | patterns, and so on. But these are "bolt-on" methods on top of the | same old languages or technologies, and some of these require | developer awareness. I know there's been some work in "secure | languages" but I'm not up-to-date on it. | | More modern languages advertise security but aren't necessarily | catch-alls. I remember one developer telling me how his application | used Ruby on Rails, so he was confident he was secure, but it didn't | stop his app from having an obvious XSS in core functionality. | | > An example is the popular PHP language. Writing code is comparatively | > easy, but writing secure code is comparatively hard. I'm working on | > the second part, but I don't expect miracles. | | PHP is an excellent example, because it's clearly lowered the bar for | programming and has many features that are outright dangerous, where | it's understandable how the careless/clueless programmer could have | introduced the issue. Web programming in general, come to think of | it. I think this all misses the essential point. Safe strings, stack guards, non-executable data segments - these are all solutions to yesterday's problems. Yes, they are still important; yes, the solutions aren't yet complete. But the emerging problems are exemplified by your comment about XSS. The real issue that we still have not internalized is that the "field of operations" has changed dramatically. We still think of a "program" as something that runs on some box somewhere. The "programming model" is the hardware and software inside that box. "Security" is about making sure that that box does what it's supposed to do - no more and no less. Everything that crosses the boundary of that box is "just I/O". But increasingly that boundary is dissolving. Yes, much of the Web 2.0 rhetoric is overblown, but much of what it's selling you - the applications that live in the network, the storage that lives in the network, etc. - is already here to one degree or another. An XSS attack cannot even be described within the confines of a single box. It's an attack against a distributed "program" running on a distribute "machine" consisting of at least three different "boxes", each doing exactly what it was designed to do. Nothing we do to the hardware in the individual boxes only will make the slightest difference at this higher level of abstraction. Nothing we do in programming languages that only deal with a single box will help. We don't today even have any formalisms for describing these distributed programs - much less safe ways for building them. So I would say that the grand challenge today is to move on. Start thinking about how to secure the global network - not the wires, not the individual boxes, not the API's, but the emergent properties of the whole thing. This will require very different thinking. Some things are clear: We gained safety within the individual boxes only by giving up some freedom. Self-modifying code? No thanks. Unstructured control flow? We can do better. Everything is just bits? No, everything has a type. And so on. Meanwhile, on the network side, what do we have? Untyped byte streams; mobile code; anything-goes paste-ups; no effective, enforced distinction between between code and data; glorification of any hacky means at all that gets something out there *yesterday*. The techniques we are applying with increasing success inside the box today - hardware enforcement of executability constraints and stack overflows; type-safe, memory-safe languages; static analysis; and so on - are ideas that go back 30 years. What's making them practical today is (a) years of refinement on the basic ideas; (b) much faster hardware. I can't recall any really new idea in this area in a *long* time. When it comes to these new problems, we're not much further along than we were in the early 1960's for traditional programming. We don't have any real models for the computation process, so no starting point for defining safe subsets. We don't even know what "safe" means for a global computation: At least for a program I've run on my box, I can in principle write down what I expect it to do and not do. For a "program" using resources on my box and a bunch of other boxes, many belonging to parties I know nothing about and who generally don't know each other either - who even in principle can write down the correctness properties? The only thing we as field have to offer in this situation is interface specs - which capture way too little. -- Jerry
Current thread:
- What's the next tech problem to be solved in software security?, (continued)
- What's the next tech problem to be solved in software security? Michael Silk (Jun 06)
- What's the next tech problem to be solved in software security? Wietse Venema (Jun 06)
- What's the next tech problem to be solved in softwaresecurity? Michael S Hines (Jun 06)
- What's the next tech problem to be solved in software security? Steven M. Christey (Jun 07)
- What's the next tech problem to be solved in software bugtraq at cgisecurity.net (Jun 07)
- What's the next tech problem to be solved in software security? Benjamin Livshits (Jun 07)
- What's the next tech problem to be solved in software security? Stephen de Vries (Jun 08)
- What's the next tech problem to be solved in software security? ljknews (Jun 08)
- What's the next tech problem to be solved in software security? der Mouse (Jun 09)
- What's the next tech problem to be solved in software security? ljknews (Jun 09)
- What's the next tech problem to be solved in software security? Leichter, Jerry (Jun 08)