Schneier on Security

Clive Robinson • February 17, 2010 9:24 AM

@ Moderator,

Are you having “growing pains” as I’m getting the Apache “forbiden” on a daily basis (https pages) at US breki / lunch / tea times.

When I used to run a server I had similar and found it is sometimes caused by resource contention under load (sometimes just by two hits at the same time).

Clive Robinson • February 17, 2010 5:50 PM

@ Brandioch Conner,

“And yet so many people have claimed that you cannot automatically remove a rootkit on a remote machine.”

It depends on if you mean a rootkit as a “specific known instance” or a “general class of unknown” software.

In this case it is a “specific known instance” so yes it can be removed because you don’t have to “search for it” (though care would be needed to not crash the system and that is probably the hard part).

In the case of a “general unknown” you have to go search and part of the rootkit class definition is it “hides it’s existance (that is it prevents detection by providing false results to searches etc).

All rootkits can be found and removed if you do not alow the rootkit to start and thereby hide it’s self (the problem is knowing you’ve checked “it all” and that is another issue altogether).

Most rootkits can be found even when running if you can “search underneath” the point at which the rootkit lies to you.

Simplisticaly it’s a bit like phoning a person and their secretary answers and say’s “their in a meeting” unless you can check between the sec and the person then you are going to have to accept what the sec says.

If however the person has a window and you can look into their office through it and see them sitting at their desk, then you have got between the person and the sec, and thus know the sec is lying…

The other way of course is to ask questions where the sec/rootkit is caught out in a deception because their answers are inconsistant. Doing this to find a root kit can be done but it’s a lot of hard work and relies on your ability to find a question that shows the deception (say missing Inodes on a Unix file system, inconsistant used/unused cluster info and file sizes).

It is of course possible to design a “deadman’s switch” root kit. That is it encryptes the user files. If you remove or tamper with the root kit the encryption key is lost, and so are all the files so far encrypted. Thus sometimes it is not desirable to remove a root kit untill you have got all the user files off of the machine and tested them on an entirely different machine.

Clive Robinson • February 18, 2010 5:18 PM

@ kangaroo,

“It’s kind of a pedantic point, I know, but I’m a pedant. When I say “all” I mean the mathematical operator.”

This could prove interesting then 8)

One of the (so so) excepted attributes of a rootkit is it survives a full power cycle of the system.

IFF you agree with that then you must have some part of the root kit in a tangable form in semi-mutable memory on the system.

That is when the system is powered up there must be information (code) retreived from the semi-mutable memory WITHIN the system to activate the information that forms the rootkit (agreed?).

If not then the machine does not have a rootkit on it at powerup (agreed?)

Thus the rootkit can be said to have a tangable pressence on the system.

On a “known” (that is known to be good) system this information in tangable form will be in addition to that, that is “known”.

Because it is in tangable form it is using some of the systems resources whilst powered down.

It also cannot be hiding it’s self when powered down.

Thus examination of all the semi-mutable memory on a powered down “known” system will be able to find any additional or modified resources.

Thus an examination (by an imutable check agent) of the information in semi-mutable memory as data and not code will show where it has been changed and how.

Thus there is a level below which the rootkit cannot hide it’s self as it has to be available (in part) to be seen by the CPU as code on powerup.

So a scan of the memory before powerup compared to a scan of the memory after it is powered up will show a difference if the rootkit is hiding it’s self.

Now I would agree there may not be much you can do with the information IFF a difference is discovered but it is an indicator that something is unacountably different.

At which point you may simply oblitarate the contents of the memory concerned and re-load it with known good information.

I would however agree that you cannot ask the system it’s self to do the scan as there is usually semi-mutable memory within a modern CPU that does survive a power cycle.

Which gives rise to some issues if the design of the CPU is such that it’s semi-mutable memory is not verifiable via it’s pins.

So on a “known” system there are ways by which a rootkit or other unautherised change that has been made can be detected.

The problem is of course that the imutable resources required to do this put some interesting constraints on system design.

You will note that I’m avoiding the issue to do with the “known” system image actually containing a rootkit.

Thus if your instalation media comes with a built in rootkit, tough you are owned and there is I would agree little that you can do IFF the rootkit has been put in correctly.

However if we are going to discusse this in any real depth we do need to start nailing down meanings or we could easily argure at cross purposes.

Clive Robinson • February 18, 2010 7:14 PM

@ kangaroo,

I think for the sake of the Moderator’s blood presure I should explain something.

We are both right and both wrong….

Which is why I said,

‘This could prove interesting then 8)’

We are actually talking about to seperate things, that look very similar.

You are saying that “inside a system” the system cannot prove it is not infected (Alan Turing’s halting and Kurt Godel’s undecidability theorms).

I’m saying that by “being outside” the system you can detect unautherised changes made to the system (by malware etc) by simple image comparison.

As Brandioch and I have crossed foils over this in the past it needs a little further explanation for others (especialy as some may think I have changed my position).

There is a problem with Alan Turing’s little state machines that is not talked about very much.

They process “information” on a tape (memory). The information can be used as data or code or both.

The issue is there is no segregation between information that is data and information that is code.

From a security asspect the Universal Turing Machine is a foot with both barrels of a loaded shotgun with a hair trigger pressed very firmly up against it.

However the problem is a little deeper than that.

Broadly there are two types of computing engine.

1, those that change data but do not react to data

2, Those that change data and do react to data.

The difference is not immediatly obvious but has significant implications for what can be done with data and security.

A Digital Signal Processor is an example of the first type of computing engine. It reads data in and performs a set of instructions on the data such as multiply by a constant and add a previous value and outputs the changed data.

The data it’s self is never looked at by the DSP program, thus it is not working as a Universal Turing Machine because it’s behaviour is not modified by the data therefore there are certain things it cannot do (branching on compare).

From a security asspect such a computing engine is highly desirable as you can prove exactly what it will do under all circumstances.

Of the other type of computing engine there are again two basic types. Those where instructions and data are on seperate tapes (Harvard) and those where they are both on one tape (von Neumann).
From a security asspect the Harvard architecture is preferable to the von Neumann. However for many reasons the von Neumann architecture is prefered for “general computation”.

From a security asspect the “Pure Harvard” architecture has the advantage that data can never be used as code. Although data can change the flow through the states of a program the data cannot add new states either deliberatly or accidentaly.

Thus with a “Pure Harvard” architecture any insecurity has to be “built in and excercised by the data”, the data cannot add insecurity.

From the security aspect the von Neumann architecture is Argh…

Clive Robinson • February 23, 2010 12:43 PM

@ Nick P,

“How did this discussion take off without me?”

Well it could have something to do with other more popular posts pushing it out of the 100 new comments list in less than 24H (which is why I sometimes mis replies to my comments).

“Well, I’m reading this under the positive[-feeling] influence of vodka and I’m thinking: OMG! way too much abstract stuff!”

Yup but some people will look at your post and think,

‘OMG! way too much technical stuff!’

Just kidding 8)

Kangaroo is correct in making the point that theoreticaly a single general purpose system cannot do what we want it to do. Due as we have said to the little problems of Turing and Goedel.

But as I also said we humans not being constrained by such mathmatical proofs do find end runs around them.

And my viev point is that yes a single general purpose system is going to be vulnerable and no there is nothing we can do to stop it happening by working within that system.

That is we need to step outside the system and look at it’s operating signitures with another system.

The question then arises does this second system have to be,

1, General Purpose.
2, Mutable in operation.
3, Accessable from the first system it is monitoring.

And the answer to all three is definatly NO to the first two and should not for the third. Depending on your view point the second system can see the data on the first and if the second system alows it then this could effect the behaviour adversly of the second system.

Which then brings forth two more questions.

The first being is this second system still subject to the issues arising from Turing and Goedel’s little problems. And the answer is probably not.

The second is what effect does this have on the first system.

Well to answer that you would have to look at how it works.

In a simplistic case it would halt the first system and check every piece of mutable memory held the correct values (how you know what they are is not of relevance at the moment) and therefore the first system is still “correctly known”.

Thus the second system time (SST) would take a time slice out of the first system time of operation thus you could have a first system availability (FSA) calculation of,

FSA = FST / (FST + SST)

However this availability figure is granular in nature. That is say SST was 0.1% of the total over 24Hs or ~86 seconds. This begs the question what happens in the other 23Hs 58mins.

Thus you also need to work out a minimum window time (MWT) between the second system monitoring runs. Obviously MWT should be sufficiently small as to reduce the effectivness of any untoward activity on the first system.

Thus you start looking at the probability of harm on the first system. In a different way.

The reason being that as you cannot do a simple check as frequently as required to prevent an attack and still get usefull work done.

The first thing that comes to most peoples mind is to do delta type checks on the file system. That is once it’s in a known state you keep an eye on what gets changed/accessed by the first system. This leads on to the notion of operating signitures etc.

Thus you have moved from activly getting into the first system to looking at what it is upto.

Which eventualy gives rise to thinking about the relationship between the two systems and what constitutes a system.

In a single system view point the CPU is king of all within it’s perimiter this is the Castle mentality system. The problem with it is that it requires “trust” where trust is not possable.

However in a system with multiparts that you watch over you get the idea of each sub system is effectivly a prisoner in a cell.

From this new view point you actualy realise you don’t realy care if you trust the general purpose computers (GPC’s) or not. You just have to worry about what goes in and what comes out.

Thus you can have I/O signitures for all of the programs etc.

You can follow this logic all the way down and partition programs to run on diferent GPC’s.

This get’s you into an interesting state where programs become programlets and then just functions. You effectivly script the runtime together with mainly trusted component parts and a few untrusted parts.

The untrusted parts run in a prison cell and have no knowledge of the rest of the system. A prison warder provides inputs and takes away outputs.

It is very similar to the idea of hypervisors and minimal kernals just more so.

Effectivly splitting a program up this way alows each part to be “known” and thus decreasing the level of trust required for it.

The other thing is it alows a minimum of resources to be given to each part of the program. Malware that hides needs lots of resources, if it can not get them then it can not hide…

Clive Robinson • February 24, 2010 6:40 AM

@ Nick P,

“Well, your coprocessor idea is interesting. Indeed, something similar was implemented for running integrity checks on main memory to identify rootkits.”

That’s a small part of what the idea can do. That is once you think “I’ve got to do this, thus what other benifits do I get” you suddenly see a whole load of rather interesting ideas spring up.

“The problem that I see is that, if you don’t trust the TCB, then you now have two instances of the same problem.”

Ahh my lack of explaining. The idea is you have a TCB that is a hardware hypervisor etc. Or more traditionaly it runs the schedular and security aspects of a more traditioonal kernel. Thus the Prison Gov trusts (to a certain extent) the warders but not the prisoners in their jail cells.

“Additionally, relying on IO signatures has the same pitfall the antivirus and IDS industry currently has: the IO signatures of malware can be made indistinguishable from innocent traffic.”

Yes and no. The problem with AV is it is looking at only inbound signitures, not signatures within the system.

That is if you have a function that loads a file of a given size from a given location, you know fairly well what you expect to see on the IO buss in terms of sectors accessed and at what times and in which order. Anything outside of that signiture should be flagged up as suspicious.

Likewise you usually know how long a program takes to load and in what order various parts of it are called. Anything outside of that signiture should be flagged.

The problem with most programs is they are complex and have complex signitures.

But… those complexities are based on simple signitures. If you split the program right down into constituent functional and IO parts etc you can have a more generic signiture for each functional part.

Thus you are not looking at a single complex signiture that malware can easily hide in you are looking at relativly simple expected signitures that any malware would find difficult to hide behind.

“If the communication protocol and grammer were designed to facilitate signature-based detection, then I could see it working.”

That’s the whole point defeate a single almost impossible to deal with complexity by breaking it down into many well understood and well charecterised simplicities instead.

“But they aren’t”

Currently that’s the point of doing the design to see if the extra work required to implement them is worth the security gain.

That is make a trade, a small reduction in efficiency to gain a lot security 😉

“and you still have attacks on the coprocessor being feasible.”

Yes and no. It depends on what the co-processor does and how.

If it is effectivly immutable and looks only to see if a signiture is within bounds, and if not fails safe, then it is effectivly a very simple state machine that can be fully modeled. Thus all the malware can do is trigger it and cause a DoS.

Likewise if you are running systems in parellel to look for diffs, it is effectivly a simple vote system that goes to fail on significant differences (The NASA ok to go type system).

The point is to make the warder as simple as possible and go for “lock down” at the sign of any odd behaviour from code in the jail cell.

“I’ve yet to software like this have no flaws.”

Which is why you make it as simple as possible to do the job (complexity is rarely security friendly).

“It’s a combination of hardware, firmware and/or software that does pattern-recognition and interacts in a distributed system.”

Yes it is the difference being unlike the normal systems to do this you manage the complexity by fundemental design criteria.

Not as a bolt on after thought on systems that are not designed to support it which is currently the norm. And as you say,

“That’s a recipe for trouble.”

“The other idea you had, of partitioning the program into pieces, is basically MILS architecture.”

Only more so. If you use the ideas of parellel computing to break your program down into very small functional units. You can more easily quantify what is and is not acceptable functioning.

“I agree with you on that one making it easier to prevent flaws: I’ve been promoting it for months. In fact, MILS architecture is the main source of my one-processor Castle mentality.”

The trick I’m promoting is to still have your castle to the outside world, but not make the mistake of trusting the slaves that do the work, just the warders that watch over them. Specifficaly you design the system like a prison not a castle.

“With verified trusted components, mainly processor, firmware, drivers and MILS kernel, one can prevent all kernel-mode exploits.”

I’m not sure you can 99.99% yes but at some point you have to say “I need real segregation” because as you noted some hardware (DMA & VM controlers in particular) can do an “end run” attack in a single processor space. It’s an efficiency security trade off that is not worth paying the price for.

“From that point, it’s on to defending userland.”

The idea of the system is it is not just kernel and userland, it’s much more structured than that

Look on it as,

1, Prison Gov
2, Gov’s deputies
3, Block warder
4, Floor warder
5, Trusties
6, Prisoners

A traditional system would only have two levels kernel and user with a hard trust transition, which is very brittle.

The idea is to have compleatly untrusted but heavily controled code at the prisoner / trustie levels rising through the levels to full trust and little controle at the Gov level.

“One can use a combination of MILS, verified components, and a careful security policy to make for a high assurance system.”

Yes this is the same but more so, the idea is to also be able to use untrusted and unverified components in a controled and monitored way.

“Anyone who doubts that the castle mentality can work should look to XTS-400 and GEMSOS-based Blacker platforms. They are very layered, but follow the centralized castle approach for client-side security.”

Yes they do work but generaly not down to the point of being able to run untrusted/unverified code.

The big bottle neck on systems development it programer time.

It has been obvious for many years that the “Unix Method” of components and scripts beats the “All in one Method” of compiled code in all but two areas,

1, Efficiency
2, Performance

But in a modern environment neither of these are actually that important and are becoming less so with time (think Cloud computing for instance).

The real problem with the Unix Method of “components and scripts” in a security environment is trust and verification.

On a unix system the command line tools that can be scripted are not what they once where. They have become overly complex and thus are difficult to verify and turn into trusted components.

The simple idea I had was to minimalise them and put them in a framework whereby they could be more effectivly controled.

That is the framework they run in provides the “instrumentation” by which they can be monitored effectivly. The build process actually produces two pieces of code. That that does the work, and that that builds the signature to pass on to the control side. The work part is “general purpose” and therfore insecure by definition, the signature part is not “general purpose” and can be secure by definition.

Likewise this duality goes on up through the script building as well.

Thus the “verification” process is built into the framework and the components don’t need to be.

This should reduce the verification bottle neck considerably as it removes the current formal verification issues.

“[The] Point being, even if we want to use your coprocessor, we still have to build it like a fortress using COTS hardware components.”

That’s the point you don’t have to have the jails built like fortresses, just solid walls and bars on the door and windows.

If you use say PC104 cards as the jails you can connect them across a PCI or SCSI coms bus in a way that can be effectivly controled by another PC104 card acting as the hardware supervisor.

Thus your jails have CPU memory and a comms bus nothing else. All the code communicates with an external comms stack (think Unix Streams as a model).

If you have to use DMA it’s under the control of the control framework not the jail CPU.

Thus you starve the jail of the resources to hide behind. Things like library code and executanble code is made read only to the jail CPU and thus immutable to it call stacks etc are protected, passed values are not passed in CPU registers only on the stack. And the CPU can be halted and release it’s bus so that the memory can be checked (via DMA) etc.

The idea is that if you accept that no “general purpose” code can be secure you find ways using to make secure (state machines) parts that supervise.

At the end of the day other than resource usage it does not matter if malware runs on your system, IFF there is nothing it can do to communicate data out of the jail. Likewise malware will get removed each time the jail is “reloaded” with a new function and that can be done quickly and easily by DMA.

It is not actually that much less efficient than other semi-secure systems, but is one heck of a sight more secure.

It also scores highly on availability as well as on reliability (as you would expect).

However it does not work with standard off of the shelf code. It is much like any other parrellel processing cluster just with a security framework.

So from that point of view it is not currently that usable for end users nor those that want to use off the shelf closed source code.

But as a test bed for the way to go it is most definatly interesting especialy as cloud computing to be effective is going to have to be done in a massively parrellel form…