Schneier on Security

Clive Robinson • February 27, 2011 6:15 PM

@ moo,

“The world is run on insecure and badly-designed software because writing all software the way the space shuttle software was written would be utterly impractical.”

And if you remember even NASA’s Space Shuttle software has had a hickup or two…

@ mv,

The world is an imperfect place where the only absoluts we thought we had appear to be based on the “roll of God’s dice” which is why Albert got so upset.

We either live with it or as Albert did “paint ourselves into a corner”.

We new from before the first electronic computer was ever built that we were going to have a fun time with them. Kurt Godel showed that any system of logic that was effectivly practical to use could not be used to prove it’s self (undecidability). Church and Turing (halting problem) slightly later showed that this held with even determanistic systems.

And if you take it forward you will realise the implication is that any moderatly complex system cannot realy be known. That is if the flow of the program can be controled by the input data the program it’s self becomes as unknown in it’s behaviour as the input data. Further if this data can be stored within the program in some way and the data can make the program access other data you are basicaly back to the Turing Engine…

Only the simplest of programs can be “proved” in any way and this is generaly within several constraints with the proof itself. often resting on the assumptions we call axioms.

You can take these ideas forward to show that no useful program can be 100% error free and thus cannot be in turn 100% secure.

Is this a problem well actually no I don’t think it is.

Back when they were designing the atom bomb at Los Alomos they ran into a problem with some of the mathmatics involved. In effect they could not get answers determanisticaly in a meaningful way. So they used probability and ended up with what we now call Monte Carlo Methods.

I think the same reasoning can be applied to the functioning of all moderatly complex programs and thus in turn security.

I won’t go into the details but consider this.

We have a very limited number of programers who can write secure code is this an issue?

Currently yes, but does it need to be?

I think not. Consider the following proposition.

We get programers to use what are effectivly scripting languages, but these are slightly different to the normal scripting languages.

They actually have two parts the conventional sub function to be used in the program but also a security function that gets run in a hypervisor system. This has a signiture of how the sub function behaves and the level of resources such as memory and CPU cycles etc the sub function needs.

If the subfunction trys to excead the limits or it’s execution signiture becomes abnormal the hpervisor stops the function in it’s tracks and then goes in to perform a sanity check on the subfunctions current data and memory contents.

If things are not as they should be then it kills the subfunction and chucks it up to the hypervisor for human analysis.

If the subfunctions are written in the correct way then both the execution signiture and the limits can be set by the scripting engine as it compiles down to it’s version of byte code.

But this “right way” has many advantages in that it means that each subfunction can just like those in a Unix shell script run on any available CPU core so you will get implicit parallel processing with just a few other constraints on how the scripts are written.

Further the script sub functions need have no knowledge of the outside world their input data is “drip fed” to them by the hypervisor stack and their output is fed back a drip at a time to the hypervisor stack. This criticaly limits the need to store data in any function thus the ability to subvert the function by any input into it.

But as the subfunction is decoupled from the world and any sub function the hypervisor can halt it randomly and sanity check it’s code and data memory. If it has become suspect it can be stoped and kicked back up the hypervisor stack.

Now have a think about each sub function being written by three different teams and the hyporvisor randomly using one of the three versions to execute one iteration of the sub function.

If a signiture or limit exception is raised the hypervisor can present the same data to all three versions of the subfunction and take a vote and decide what to do.

Further the hypervisor can randomly send one small data set to all three versions if they all agree in the way they behave then the chances are the program is behaving functionaly correctly

There are a whole load of other things the security hypervisor can do such as out of order execution add random time delays and run through nonce data.

Effectivly the script programer is blisfully unaware of any ot this background activity by the hypervisor. However any malware writer wishing to put data into the script to subvert it in a meaningful way is going to have a much much harder time.

In this way the scarce resource of those capable of writing the subfunctions securely can do this, the everyday jobbing programmer needs not get involved with the actual security at this level.

Thus you end up with a script that is both inherantly more secure but also probabalisticaly check for incorect function by the hypervisor.

Such a system would not be perfect but it would certainly be orders of magnitude more secure from external malware attacks than current methods.

Have a think on it and see if you can come up with further benifits.

I’m aware that it has certain issues as well such as it is not “CPU cycle” efficient, but then neither is Java, PERL or just about any other post Java language.

Oh and one other benifit you can make the subfunction of the scripting language much more highlevel. It is known that the number of “bugs” a programer introduces into any program is related more to the number of lines of code than just about any other metric, which is why the likes of LISP programers are generaly more productive than C++ programmers and they in turn than assembler level programmers.

Clive Robinson • February 28, 2011 11:20 AM

@ Jay,

“Security flaws are all about when our problem model didn’t match the domain…”

Yes they are and this is a major part of the problem.

As a general rule of thumb large complex models are not that usefull (due to many reasons) and can be effectivly as close to usless as makes no practical difference.

So we have eveolved ways of reducing the model into parts and then dealing with those as seperate bits with less complexity and thus more usefull.

Likewise we break the inputs and outputs into types and deal with those seperatly.

We end up with a multilayer model with each layer consisting of multiparts.

Likewise with a dwelling such as a house which has foundations, possibly a celler, walls, floors, ceilings, lofts, eaves and roof tiles.

The building design / techniques for foundations are generaly different to walls although they may look the same at the damp course interface. Thus the layers have distinct and different purposes that usually have different design requirments and rules

Likewise the internal and external walls which also have doors and windows the doors internal to the building being very different to those in external walls. Thus at the various layers there are multiple parts that may conceptually be similar (ie doors & windows) still have very different design requirments (internal doors to keep noise down, external doors to keep intruders etc out).

A mistake we often make with ICT is to make a “one size fits all for all things” mentality. Thus building huge and compleatly unnecessary complexity, usually with insuffisient internal compartmentality to deal with it.

We normaly don’t see this in any other walk of life, afterall how many cars have you seen with beds and kitchens and swiming pools in, and where you have would you real want to drive it or pay for the upkeep and cost of keeping it on the road?

No so why do we do this with software?

It’s partly because we cann’t see software as a physical object and thus the distortions and inconsistencies these “features” create are mainly hiden not just from view but perception as well.

Worse the desire for additional “features” to be “bolted on” either post design or post build are driven by “marketing”. And as we cannot perceive the ugliness that has been created we don’t reject it as not fit for function.

Thus the complexity at any level is getting compleatly out of hand and thus compleatly unmanagable at any given level.

But it getts worse applications are not only feature bloated sidewards within a layer they are also with the advent of the web app taking on (badly) the roles of other layers as well.

One such example is a web browser as an application it sits above the OS and effectivly runs many applications within it.

The OS in many traditional models supplied much of the security by ensuring that independant functions (originaly apps) do not have access to each others memory space etc etc. Thus the OS security model was “seperation” both verticaly and horizontaly with “mediated” (by the OS) and “controled” (by the OS) data communications.

Most apps especialy the likes of web browsers are designed to offer ease of use and easy data sharing etc etc in a single “efficient” memory model. Thus the web browser bypassess the majority of the security that used to be provided by the OS and few of the “apps” are now in any way realisticaly secure from each other (the same applies with MS products like Office where individual apps at some level they have free access to eachothers data).

One of the ideas behind the hypervisor is it builds the more traditional OS security model into the application by default. Thus external malware etc finds it difficult to get in.

However at the bottom end of the hypervisor stack where the scripted app runs it does not address the asspects of policy.

That is if a user decides to do something stupid it is not at this low (anti malware) level the hypervisor provides security.

Without going into the details of the upper layers of the hypervisor (partly because I’m still working through them) you have layers that deal with “policy”.

There are a number of ways of doing policy but in general the more traditional models fail because they deal with “entities” that “own” or have rights over objects.

Humans don’t work as “entities” they have “roles” thus at higher policy layers the hypervisor deals with “entities” that have “roles” where “access” across “objects” and their “roles” is controld by the matrix of the particular policy of the role the user is carrying out.

Thus over simplisticaly the administrator who owned the password file could not edit it unless they had switched into an appropriate role.

Thus a web browser could have several windows open but would only alow access between them based on a particular role. So it could have a window open to “Myloot Bank” and to “robmeblind music downloads” as the role for one is “banking” and the role for the other is “download MP3s” the security hypervisor would stop access between the two.

Unless of course the policy of either alowed it which is a failure of the human setting the policy not the hypervisor script. That is a hammer cannot be held responsable for having beaten in you brains because some nutter had it with them to do just that.