What's the next tech problem to be solved in software security?

[leichter_jerrold at emc.com (Leichter, Jerry)]

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