Schneier on Security

Clive Robinson • July 16, 2010 8:46 AM

For those who are wondering about why this is a bad idea, as BF skinner notes,

“This is what I was thinking about when Clive was discussing asymetric risk yesterday”

It was actually MS handing over the source code yet again (remember China getting it?) that made me think about asymmetric risk.

You can find my comment here,

http://www.schneier.com/blog/archives/2010/07/internet_kill_s.html#c448468

Clive Robinson • July 21, 2010 5:22 AM

@ Nick P (july 19 6:27pm)

“I say we get several governments to fund”

Hmm they can not agree on how to deal with third world debt so… it’s best going to be done by the likes of a standards body (IEEE / CCITT / etc.).

“the creation of a team of programmers to rewrite the base OS (at least kernel-mode) using low-defect be functionally modelled, then the new system will be a drop-in replacement that matches the functionality.”

Yes it would be handy and the reason it has not happened is the near monopolistic position of the big software houses (the lack of distance vector and near zero production costs make standard market forces that economists rely on somewhat mute).

Arguably it can already be done with the various Unix standards (did I hear Xopen drift by on the wind 😉

The fact there was no clear Unix company ment they where forced to be co-operative in a competative way so the API’s got standardised.

But as it is only realy going to work as a framework at the API level, the interfaces need to be clean and enforcably policed independantly.

“The .NET runtime and MS Exchange should probably be redone.”

They are the easy ones. MS has a reputation for having two API’s “in house” and “for the competition”. If true (and some judges appear to think so) then those using the “for the competiton” API will be forever at a disadvantage.

As has been noted by Doug (DCfusor) the MS code is a real nightmare and worse it has to be draged forward for “compatability” because there is way to much “legacy” code and hardware with drivers. Worse because the MS code was so bad the third party code was even worse, so realisticaly you have a core of code that nobody now understands or wants to touch, but that has to still be supported (anyone remember IBM’s OS/2 well I’m told some banks still use it).

My view point has for some time (ever since the 16-32bit thunking issue) has been ditch the legacy support or run it in a VM and go for 32bit (now 64bit) clean code and dump the Intel segmentation model.

Realisticaly I think I’ll still be saying this in 2030 (assuming I’m still here to say it) when the current head of MS is scaring the staff in his nursing institution.

Clive Robinson • July 21, 2010 7:10 AM

@ Michael Lynn, BF Skinner,

It has become clear from reading your later postings with Nick P that we are not comparing apples with apples in our discussions.

I’m assuming 0-Day based on “new classes” of attack, and you appear to be thinking in terms of “new attacks” in existing classes.

For new attacks in existing classes I would agree that asembler level code reading will actually show up more new attacks than with the source code, especially if an optimizing compiler has been used.

However new attacks in existing classes have quite a short shelf life as malware writers are looking in this area most of the time.

However finding new classes of attack is better done at the highest level you can, and once found can have an extraordinary life time.

I guess the thought is crossing your mind about what’s the real difference. Well buffer overflow attacks are a class of their own and have many attacks based on them. Because the mechanism is so well know it is fairly easy to find especially at the assembler level as the usual code obsfication via libraries, inline code etc has been removed.

A new class of attack I have been looking at is via side chanels in protocols that can be used to change the flow of a programs code without having to inject a code sledge or other jump code to get the attackers required functionality, it simply uses the existing legitimate code differently.

The fact that you don’t need to add exacutable code or know where specific function exacutable code resides in memory gets around many of the current security protections such as those that detect a broken stack, or linkers that use random not fixed memory allocation for library code etc.

One reason for this is embeded systems where the executable code may not be mutable, or not even in the same code space (think strict Harvard Architecture for instance).

When you consider that a lot of I/O these days is actually done by an embeded processor in the interface card the potential for this type of attack is increasing.

As I’ve said a number of times before the areas of future attack are going to be by side channels be they passive or active and most side channels will be found at the interface and protocol levels not down in the code.

Clive Robinson • July 22, 2010 3:53 AM

Oh out of interest anyone else keeping an eye on the (apparently) SCADA targeted malware that jumps the “air gap” using a USB drive and an unfortunate feature of Win 7 (to do with the .lnk files that put up fancy icons in file managers etc).

I’ve been keeping an eye on “air gap jumpers” for a while now as “Fire and Forget” virusware with “specific target related payload” is a sensible way to move forward for those not involved with the very silly side of profiting from malware.

It has however aided a few of those “Infrastructure attack” “Cyber-warfare” weenies get “their panties in a wad”…

I fully expect as I predicted some time ago for “fire and forget” with “target sensitive payload” attacks to increase. I also expect them to develop “control channels” that cannot be predicted and thus cannot be blocked.

Hey ho it’s just a consiquence of the “malware market” developing as people learn how to “better capitalise” on their investment in the botnet idea…

Clive Robinson • July 23, 2010 9:01 AM

@ Nick P,

“OS extensions that mediate external devices combined with traditional security techniques, are the answer here. Well the technical answer”

Only for a subset of the issues, thankfully we have not yet seen any of those from the larger set yet.

Consider how a program is effectivly a hard coded set of rules with user entered data in one or more buffers and control information also stored as data.

Traditional attacks have revolved around breaking a buffer to insert executable code or the exercising of type casting errors to cause the program to make incorect control control choices.
With a mediating OS on a CPU that has separate code and data sections where the code section is “randomly” loaded your options as an attacker apear to be limited to playing with data or timing.

Even so, this is still sufficient in many cases, one of the failings of many “object orientated” programing languages is that an objects user data and control data are stored adjacently in data memory and likewise objects are stored consecutivly in memory. Thus it is still possible to find and manipulate data within this structure without having to know where the data is actually loaded in memory.

Thus (overly simplisticaly) for instance an attackers user input string that is in effect an SQL attack may simply bypass the input validation simply by overwriting control data adjacent to the input buffer.

The obvious solution (random data ordering) is just not practical in many cases, likewise writing random values between user data buffers and control data is difficult to get right and thus work effectively (due to amongst other things timing attacks).

Thus even with these measures an attacker is always likley to have an attack vector with just input data, as it is down to how the application code is writen, it’s available functionality and how user data is presented to it.

Even with the best written of code, because it is within the bounds of the programs legitimate behaviour the possability exists.

Thus technical solutions at the OS or lower layers is not going to be foolproof especialy on single CPU systems.

“Good policy and strong enforcement on personnel are the foundation of keeping malware out of air gapped systems.”

As we unfortunatly know all policy has required exceptions (think software updates and security patches) and even the best personnel are subject to manipulation in one way or another (like senior managment edicts).

Thus,

“But, we do have technical measures to pull it off now.”

Is only partialy true. We also need what we don’t have which is all code cutters being security gurus.

Which brings me back to my previous argument about “code cutters” being relegated to “scripting” and security gurus writing and maintaining the scripting language elements that rune in jails or sandboxes. Potentialy it is more secure but importantly it makes code cutters more productive at the expense of CPU cycles which generaly is unimportant.

“I think it would also help to restrict the data formats to those that aren’t really executable, like PDF-A rather than PDF.”

Yes but that has it’s own issues in the “groupware” culture that businesses now work in. Thus the “Senior Managment edicts” problem.

“Everything should be simple and hard to use to launch an attack.”

With monolithic applications this idea has it’s own hidden problems that make it impossible to implement, hence my point about scripting as oposed to code cutting.

There is very little application level production code that needs to be written in any kind of low level or “bare metal” language. And the little there is can mostly have those parts extracted out to be run in a highly controled environment.

Just about every study carried out shows that the number of programing bugs is related to the number of lines of code not the level of the language used. Also that again irrespective of the level of the language the number of actual “final code” lines per day remains constant irrespective of the level of the language.

Thus the simplest security measure to take now would be to move to much higher level languages and thereby cut down the number of lines of “code cutter” programing. From the managment perspective this would also mean higher productivity…

As has been known for some time properly crafted scripting languages are the fastest way to get working code for prototyping etc. The downside has always been the “perceived need for speed” which several studies have shown to be a compleat waste of time.

One study actualy showed that the time to “re-code” the prototype the customer had signed off on exceded the time it took for the hardware/price/performance to catch up with the prototype…

With more and more studies showing security issues have moved from the OS layer into the application layer we still appear to be fighting the same old battles over not having learnt the lessons of history (ie web browsers are effectivly multitasking OS’s in their own right, but without any of the current OS security features).

As security practitioners we need to look for a way to “sell our services” currently we do it by “Chicken little” FUD. Which tends to make us as popular as “lepers at a debutants ball”.

A much better way is to give security as “part-n-parcel” of systems that will add to their bottom line not detract from it. High level languages with built in security features are currently the way to go unless we can solve the human issues that give rise to the constant bugs/lines and lines/day isses.

As for “security training” for “code cutters” forget it very few software houses started doing it and now we are in a recession it’s a cost most managers are not going to add to the bottom line without the buy in of the very senior of managment.

Which brings me back to my old (cracked record 😉 point that “security” should be seen as a “quality” process and treated as such and thus “built in” from day zero (day one is a day to late 😉