The Biology of Network Security

Bob Brown writes "A University of New Mexico researcher is taking lessons from biology and using them to try to stymie hackers and viruses. Projects such as RISE attempt to secure computers and networks by promoting application diversity." From the article: "Diversity of systems and applications can play a key role in safeguarding computers and networks from malicious attacks, Forrest said. Her team published a paper last year on a system dubbed RISE (Randomized Instruction Set Emulation) (PDF) that randomizes an application's machine code to stymie would-be attacks, such as those launched via binary code injection."

Comments

Gee, ya think?

[Otter]

She said this idea didn't fly very well with hardware engineers at Intel with whom she spoke to last year, as they envisioned having to build different chips around all these different instruction sets.

Gee, ya think?

Forrest's team got around this issue by building its technology atop virtual machine software dubbed Valgrind that she said provided flexibility because it is open source but that is not as efficient as she would have liked.

Gee, ya think?

Forrest acknowledged that the RISE system is unwieldy in some ways and still has kinks to work out...

Gee, ya think?

Re:Gee, ya think?

[Nesetril]

correct if i am wrong but what kind of cop out is this to make yet another closed VM? of course that will make software that runs on it impenetrable to viruses... but then what about the VM itself?

Re:Gee, ya think?

[desdemona]

You foolish young man, it's VMs all the way down!

Re:Gee, ya think?

[Anonymous Coward]

Women and technology...

Gee, ya think?

Re:Gee, ya think?

[Jeremi]

correct if i am wrong but what kind of cop out is this to make yet another closed VM?

Unless there was a coincidence in naming, I think valgrind refers to the (really quite awesome) open source debugging tool for Linux. Valgrind's primary purpose is to let you run your x86 Linux executables in an emulation environment where any memory-access errors can be detected and reported; it makes debugging much easier than in the "real world", where an error might only cause a crash or other visible symptom 1% of the time. I suspect this researcher merely "appropriated" the valgrind source code as a test harness for her ideas. It's certainly much cheaper to do it that way than do build your own x86 fab...

As far as security holes in the VM itself: yes, that is a possibility, but keep in mind that the complexity of a VM is finite, which means that sooner or later (hopefully sooner) it can be fully debugged and thus be secure. The complexity of the programs it runs, on the other hand, is infinite, because new programs are being created all the time. So the advantage of a VM is that you can get the small amount of "golden" secure VM code to protect you against from the buggy code that runs inside it.

Consider this: an Intel chip is just a VM implemented in hardware. Hardware security flaws do exist, of course, but they are also quite rare compared to software flaws, mainly because there are so few hardware implementations being built.

Re:Gee, ya think?

[Otter]

I suspect this researcher merely "appropriated" the valgrind source code as a test harness for her ideas. It's certainly much cheaper to do it that way than do build your own x86 fab...

That's what struck me as funny -- she bothered to talk to someone at Intel about her scheme to implement the hardware counterpart to Gentoo. And the more realistic fallback plan was to run everything in a debugger!

Re:Gee, ya think?

[airConditionedGypsy]

Changing hardware to do ISR isn't that difficult; you essentially include another register that holds a secret key that has transformed the binary. During runtime, as an instruction is fetched, it is decoded with the key and then passed to the normal execution machinery.

Since not every university has their own chip fabrication facility, the next most logical choice is to run things in an emulation or binary translation environment. Valgrind itself isn't a debugger, although its most popular tools (Memcheck, etc.) are used as such.

Extinction?

[MECC]

Would that include extinction of species with inadequate immune systems?

Re:Extinction?

[Opportunist]

Unfortunately, no. The "new" kind of infectors don't aim at killing the host. They just want to "milk" it. They want its processing power, its connection speed, its information and its user's credit card number.

Re:Extinction?

[bsdluvr]

Only if they are unmaintained. One can not drastically change a biological species' immune system (yet), but one can improve a network's security measures.

Re:Extinction?

[LordKazan]

So you mean they're parasites since we're using biological terminology

Re:Extinction?

[TommyBlack]

>>So you mean they're parasites since we're using biological terminology

Yeah, just like end-users.

<g>

Re:Extinction?

[Random Utinni]

Yeah, that would make them parasites... which try to get resources without being noticed.

Interesting ideas, but I don't know how well the biological maps to the commercial. After all, in biology, you have a population of genetically different individuals. The idea being that, among this population, some will have the functional capacity to avoid/survive whatever impending disaster/predation/disease/parasitism comes up. That's all well and good. What doesn't work so well for commerce is the corrolary that the population *will* suffer death/disease/etc in large quantities over time. In biology, so long as some survive, the population continues. In commerce we're not looking for the overall survival of servers as a population. Each company is looking to protect all of its servers. Each company, therefore, would need a diverse population... but diversity between companies would be less important. Still, I don't think that a corp would be willing to sustain the kind of losses that biological systems do.

I suppose that the concept could be abstracted somewhat: you'd have to have a top-level population of anti-virus/spyware/whatever that contains your genetic diversity. In an attack, one of the defenses would hold. But isn't that what good SA's do already?

If you were to make it hardware based... well, then in addition to the costs others have pointed out, you're basically just fragmenting the population so that an attack would only work against a small segment of machines. So long as you were not the odd one out holding the dead machine, you're fine. But like I said, I don't know that commerce is willing to take that on.

In the end, it's all a matter of the Red Queen. Whatever anti-virus system we come up with, virus writers will find a way around it. There's no way to find a "winning" solution; all you can do is try to keep up.

Re:Extinction?

[gbjbaanb]

that made me think.. and I think the idea of security as an immune system response is quite a good analogy.

In an immune system, once you catch a virus, your body will produce antibodies to fight it off, and then remember the virus so it'll be easily taken care of if it re-appears (hence we innoculate ourselves with a harmless attack).

In security system, once an attack is noticed, the system is fixed/patched/configured to prevent the attack, and what you (as a sysadmin) remembers what you did so next time that attack is tried it won't get anywhere. Similarly, if you want to follow tried and tested methods, you should 'innoculate' yourself by attacking your systems yourself (ie. a harmless attack).

The extinction of the species is the ones whose immune systems cannot cope with the attack, or have a poor initial response - ie. sysadmins who don't know what they are doing. In a perfect world, we'd get to the point where servers are configured correctly and maintained only by people who know what they'd about (I refer in particular to sysadmins who post to webhosting forums saying 'Ive been hnacked, what do I do', or 'how do I configure x y or z to be secure'.)

And yes, just like real life, we're constantly attacked, and constantly defending ourselves.

Re:Extinction?

[Opportunist]

Well, MS is trying to sell us a winning solution in DRM. Personally, I consider it a lot of fluff, more hype and all wrapped up in marketing speech, in an attempt to lure clueless managers into buying into that crap.

To ride the biologic analogy a bit further, computers are essentially "clones" of each other. Yes, they may have different makeup, they may have different graphics cards and so on, but then again, drivers nullify that difference again. The task of drivers is essentially to make "clones" out of different hardware: They react to defined interfaces, then translate these commands to the specifics of their hardware.

Now, as anyone with at least half an idea about biology can easily figure out, clones are incredibly susceptive to a parasitic attack. The parasite only has to overcome the defense of one clone. Got one -> got all.

Now, the creator of the parasite can easily obtain one of those clones. And develop his attack. A computer system is suffering from the "weakest link" problem: You don't have to defeat the whole system. You only have to beat the weakest link. You can have the best steel door if the walls are made of plastic, the attacker is in.

Ok, then we have evolution

[Opportunist]

"We already have malicious code that can replicate and spread itself. The only thing we're missing in terms of real Darwinian evolution is mutation,"

Nope. Polymorph viruses are not really unknown. Right now as we speak, they make a comeback.

Re:Ok, then we have evolution

[Anonymous Coward]

Nope. Polymorph viruses are not really unknown. Right now as we speak, they make a comeback.

That is not analogous to random genetic mutation.

Re:Ok, then we have evolution

[kurzweilfreak]

Great, next someone writes a virus based on a genetic algorithm and as the virus propagates across the world, by the time it reaches back to ground zero it's a totally different species! Or, erm, yeah, something like that.... viva la Darwinia!

Re:Ok, then we have evolution

[Opportunist]

By definition, computers cannot by themselves generate anything random, as they are computing everything. Hence the name.

If you want to compare it, it might be closer to "selective breeding". Usual polys don't have a lot of "offspring" that's not viable, mutated out of the ability to function. At least if the coder is good. :)

Why do I see a discussion about religion coming my way..?

Re:Ok, then we have evolution

[Anonymous Coward]

Parent is just absurd. Somebody who doesn't know what a genetic algorithm is at all.

Re:Ok, then we have evolution

[Maximum Prophet]

Every once in a while, networks will introduce an error into a file. Most often, this will be fatal to an executable, like a zero length file. But, there is a non-zero probability that someday an error introduced into a computer virus will change it from non-malicious to malicious. There's also the probability that an error will change a regular program into a virus. (or change a virus into a useful utility)

Also, the environment that the viruses live in is changing. It's possible that a security "fix" will make some virus worse, rather than cure it.

A really malicious virus writer could turn off the normal network checks that keep errors from getting into code so that his viruses will mutate faster than normal. (Or use some source of randomness, like keystroke timings)

Nothing new

[Anonymous Coward]

Although a good article, I'm sorry but I don't see the new angle on system diversity. Although it is true that it improves security, this has been going on for years in most mid to large size IT departments.

ajam at Hackbuzz.com

Diversity is the key

[mtenhagen]

The key point in network security is diversity and multiple layers of security. When there is a fault (due to whatever cause) in one of the layers only that layer will be comprimised but no real severe damage done.

Ofcourse it is important that those layers are created and maintained by several entity's.

A simple example:
- Have your network guys maintain your firewalls
- Have all traffic go through a application gateway which is maintained by a third party.
- Have system administrators to secure the system

Ofcourse adding layers increases costs and security.

Re:Diversity is the key

[muzzmac]

What you talk about isn't akin to Biological diversity.

If you took the Biological diversity to the nth degree, what you are talking about is designing systems with the goal that SOME systems will survive a given threat being realised. Hence the species survives.

Biological Diversity in IT Security people are stating that we should use all flavour of Operating Systems, application systems etc...

The problem is we (humans) are not really interested in "some systems surviving."

We are interested in "ALL systems being secure." Whatever that means.

In this regard, I assert that the goal of Biology is survival. The goal for IT or Information security is stability, reliability and predictability. (OR CIA if you like those terms)

This is why technologies that provide immunity (hardened well understood builds and lists of known pathogens AV) OR rapid response (AV signature updates) to threats tend to be the successful products.

It is a bit hard to update your very large fleet to defend against a known vulnerablity when you don't know what the hell is in your fleet. This is why I don't like the "Biology" model being pushed as an answer to security problems. (By some VERY big names in the IT security profession.)

Usually comes right before an attack on the most used operating system on the market. ;-)

Intel not so happy

[TubeSteak]

She said this idea didn't fly very well with hardware engineers at Intel with whom she spoke to last year, as they envisioned having to build different chips around all these different instruction sets. Forrest's team got around this issue by building its technology atop virtual machine software dubbed Valgrind that she said provided flexibility because it is open source but that is not as efficient as she would have liked.

I imagine that Palladium style code checking wouldn't be to happy with programs that did funny things like this. I could be wrong, but off the top of my head, it seems plausible.

As for mutation aka polymorphism (she talks about this at the end of TFA), doesn't she know about virii having built-in mutators? And metamorphic code does almost the exact same thing she's talking about in RISE.

Write your own

[digitaldc]

"This is a little tricky because we don't want to make everyone write their own operating system or e-mail reader from scratch or even learn a new interface," Forrest said.

Speak for yourself, this is a lifelong obsession.

A wise man once said - 'Never connect to the internet and your troubles will be few.'

So.... Computer CJD?

[weetabix]

So, what happens when someone finds a way to either a) run code right on the hardware and bypass the virtualization, or b) finds some small snippety of code (a binary prion, perhaps?) that plays hell with this RISE? I mean.... Mad Cow Disease is a prion.... Mad Computer Disease next?

Re:So.... Computer CJD?

[dalroth5]

According to p. 27 of the RISE paper (PDF),

RISE is resilient against brute force attacks because the attacker's work is exponential in the shortest code sequence that will make an externally detectable difference if it is unscrambled properly. We can be optimistic because most IA32 attack codes are at least dozens of bytes long, but if a software flaw existed that was exploitable with, say, a single one-byte opcode, then RISE would be vulnerable, although the process of guessing even a one byte representation would cause system crashes easily detectable by an administrator.

It goes on to explain that almost all of the time, the non-scrambled injected binary code, after being scrambled by RISE's unscrambler, causes an immediate crash, or a no-op, or an infinite loop. The point is that it won't execute.

And yes, it covers a number of both known attacks and theoretical ones.

And yes, it also covers the techniques they used to protect the RISE code itself; and relates RISE's techniques to those used in PaX, stack-smashing protectors (PointGuard et al), etcetera, etcetera. All in all an interesting read: not enough by itself but might make a useful additional layer.

Infrastructure doesn't work like biology

[Nos.]

Sure, in biology, differences help make the species stronger. Not true in IT. Which is harder to maintain, a shop full of [InsertOSHere] standard PCs, or a mixed environment with different hardware, different OSs, and different applications. Sure, it might lesson the potential vulnerability to various virus and other automated tasks, but at what cost? Suddenly instead of needing one or two specialized skill sets, you need lots. Not to mention the fact that the more environments you support, the more likely you are to have a security hardened environment.

Re:Infrastructure doesn't work like biology

[Whiney Mac Fanboy]

Sure, in biology, differences help make the species stronger. Not true in IT.

Depends how big the difference are.

Take for example address space randomization (part of execshield). I'll quote redhat's explanation of it (as it's quite good):

The idea behind Address Space Randomization is to put program code at a different address each time it starts. This way, an exploit can't know where the return address pointer should point to.

Protects against many buffer overflow attacks (regardless of the hardware), with no cost to your 'standardized environment'.

Pity windows & macOS don't have something similar.

Re:Infrastructure doesn't work like biology

[Pinball Wizard]

It may be easier to maintain a network of homogenous PC's, but once I've broken into one of your computers, I've broken into them all. That's something that management should consider as well as the supposed "ease of maintenance" a homogenous network would bring. What's easier - fixing one compromised machine, or an entire network of them?

Re:Infrastructure doesn't work like biology

[Anonymous Coward]

Take for example address space randomization

Protects against many buffer overflow attacks (regardless of the hardware), with no cost to your 'standardized environment'.

Sorry, that's a myth. There is a very real cost: many classes of bugs (notably, many bounds errors) become unreproducible, which has a severe impact on your ability to debug real-world problems.

Performance is not the only thing that matters when modifying code for 'security' purposes. Random behaviour is very rarely a desireable thing on production systems.

Re:Infrastructure doesn't work like biology

[Mathinker]

Are you talking from experience here? Because I don't see why this strategy would necessarily cause bounds errors to become unreproducible, as long as the randomness in the addresses was in units of memory pages. I'm talking about the bounds errors where you access my_array[end_index + something_reasonably_small], not the ones where you access my_array[completely_trashed_index].

Even in the trashed index case (in my experience, usually caused by a negative number somewhere being interpreted as unsigned) I'd be surprised if the randomization would cause it to be likely that you wouldn't dump core.

I find it hard to think of other ordinarily predictable common bugs which would become unpredictable, could you give more examples? I can see it making the ordinarily unpredictable bugs (e.g., bounds error on the stack overwriting the stack frame's return address with data) even less predictable, but don't think the extra unpredictability would be really significant.

Of course, in the best Slashdot tradition all this was just off the top of my head, so, anyone out there with real experience want to jump in?

What does this mean...

[__aaclcg7560]

The biology of network security... is that when the lead batteries in UPSes goes bad, spring a leak, and make the surrounding area smell like an open sewer for a few days before people realized it's not a sewer problem from a nearby restroom?

Or would that be when the air conditioning guys pump coolant fluid through a garden hose in the false ceiling space until the hose exploded and sent all this green goo crashing down on the sys admin's brand 19" monitor and nearly nailing the sys admin?

Does that make me a biologist since I witnessed these events first hand at one of the companys I worked for? Cool! I'll put that on my resume.

Lessons from Biology eh?

[Cheapy]

How about this lesson from biology: animals need to reproduce.

So the solution to stop having crackers breaking in to things?

Mandatory sexy girls for all geeks!

Great Solution For Small Networks....

[corellon13]

But this is exactly the kind of thing large companies are trying to get away from. FTA:

Making each computer unique would make life a lot tougher on attackers, she said.

This is costly for companies with large networks as it requires too much overhead to manage this kind of a diverse network.

"This is a little tricky because we don't want to make everyone write their own operating system or e-mail reader from scratch or even learn a new interface," Forrest said. "The look and feel of the program and underlying functionality when it computes needs to somehow be constant."

The solution to these problems used was VM software. The problem is that running this on each machine is going to consume valuable resources. Having said all that, I think this could lead to a valuable security solution but it sounds more useful for large networks/companies than it does for the everyday user. Thus, it needs to pass the Executive smell test (which is always dollars). IMHO, practicing a layered approach to security using several hardware and software layers is the closest and best currently available alternative.

What about bugs?

[bsdluvr]

Wouldn't allowing each app to have its own instruction set create yet another kind of programming bugs, and make debugging really hard?

Re:What about bugs?

[airConditionedGypsy]

Yes and no.

A similar paper is here: http://www1.cs.columbia.edu/~angelos/Papers/instru ctionrandomization.pdf (in fact, they both appeared at CCS a couple of years ago) and the basic idea is that the use of the 'new' instruction set is completely transparent to a well-behaved application.

An application that has code injected into it will behave differently, becuase the execution environment (i.e., Valgrind in RISE's case) will try to de-randomize the binary (including the injected code). Presumably, de-randomizing the injected code will fail and cause a signal that is visible to the operating system.

So, artificial diversity *does* make it harder to debug a system, but in this case, not really, and the system should save enough state in the alert to let you know where things went wrong.

Random?

[johnfink]

Her team published a paper last year on a system dubbed RISE (Randomized Instruction Set Emulation)

My Windows machine already performs plenty of "Random Instructions", thank you very much.

Marcus Ranum had an opion on this

[Anonymous Coward]

Marcus Ranum's opinion
-----------------------
Monoculture Hype Alert!
NSF Grants Two Universities $750,000 to Study Computer Monocultures (25 November 2003)
With the help of a $750,000 National Science Foundation grant, Carnegie Mellon University and the University of New Mexico will study computer "monocultures" and the benefits of diverse computing environments. "The researchers intend to create an application that could generate diversity in key aspects of software programs, thus making the same vulnerability less effective as a means of attack against the population as a whole."
$750,000 to sit around and whine about Microsoft? How do I get a gig like that?!

The Myth of Monoculture
Recently, my friends Dan Geer and Bruce Schneier (along with other smart people) published a paper postulating that our computing environments are at risk of security disasters because of a "Microsoft Monoculture." This paper has gotten a tremendous amount of attention lately. Unfortunately, I think that many of the papers' proponents have forgotten that the paper is an analogy and not real science. Arguing by analogy is illuminating but also distracting.

See link below for the full opinion on "The Myth of Monoculture".

http://www.ranum.com/security/computer_security/ed itorials/monoculture-hype/index.html

Re:Marcus Ranum had an opion on this

[dajak]

Arguing by analogy is illuminating but also distracting.

It does convince the clueless review board doling out the money. I wish I had this 1-2-3 profit! talent for making up distracting analogies.

Mozzarella and Prosciutto Sandwhiches w/ Tapenade

[Anonymous Coward]

1 1/2 teaspoons chopped anchovy fillet
1 teaspoon capers (preferably salt-packed), rinsed, chopped
1 garlic clove, minced
1 teaspoon finely grated lemon peel
1/2 teaspoon finely grated orange peel
1 1/4 cups Niçoise olives, pitted, divided
1/4 cup extra-virgin olive oil plus additional for brushing and drizzling
1 tablespoon (packed) chopped fresh basil plus 24 whole leaves for garnish
2 teaspoons fresh lemon juice
6 6-inch-long pieces ficelle or narrow baguette, split horizontally in half
6 thin prosciutto slices
2 8-ounce balls fresh mozzarella cheese, drained, cut into 1/3-inch-thick slices

Combine first 5 ingredients in mortar; mash with pestle to paste. Add 1 cup olives and mash to coarse paste. Chop remaining 1/4 cup olives and stir into mixture. Mix in 1/4 cup olive oil, chopped basil, and lemon juice. Season tapenade with pepper. (Can be made 2 weeks ahead. Cover and refrigerate.)

Brush cut sides of ficelle with additional olive oil. Place 1 prosciutto slice on bottom half of each ficelle, then top with mozzarella slices, dividing equally. Spoon tapenade over each. Sprinkle with pepper; drizzle lightly with olive oil. Garnish with basil leaves. Cover with top halves of ficelle.

Wouldn't work outside of Open Source

[gzearfoss]

It's a novel concept, but I can't picture how it would work outside of Open Source software.
To run a program on such a chipset, it must be specifically compiled for that chipset. So for commercial applications, you either require a separate version for every possible chipset, or a method for the user to compile it for their computer. The latter isn't rational - all it takes is a single unscrupulous user to leak the code, the program gets out of your control. As for the former, I can picture going to a store and being told, "Oh, sorry. We're all out of Office for Chipset 0xDEADBEEF. Is Chipset 0xDEADBEEE ok instead?"

Re:Wouldn't work outside of Open Source

[RexRhino]

You could compile your source code to some sort of abstracted binary code (similiar to a java virtual machine), and then compile that into your real machine code on the local machine.

If each computer is unique...

[Crussy]

How are companies supposed to distribute copies of their closed, binary only applications. I cannot see Microsoft willing to let users compile their own copies of windows, office, exchange, visual studio, etc to match their architecture. I cannot see Microsoft compiling binaries to match a user's given architecture. I even more cannot see the average person being able to successfully do this on their own. Imagine introducing the nearest lay person you know to Gentoo and telling them to get a system operating, they'd be dumbfounded even with instructions. "Compile from source? What does that even mean?"

The only solution possible is if there's a compatibility layer that will run binaries on any machine... A VM perhaps... and this would just allow viruses to run anyway and defeat the entire purpose of such an architecture to begin with.

This is truly wishful thinking at its finest

Re:If each computer is unique...

[Jeremi]

How are companies supposed to distribute copies of their closed, binary only applications.

I'd say, the same way they do now, except that the executable would contain enough information so that the installer process can swizzle the code around in a random fashion. To the user there would be no visible difference, but to a virus that was relying on the code or data being laid out in memory in a certain way, it would be completely different from what the virus was "expecting".

Re:If each computer is unique...

[airConditionedGypsy]

As the sibling poster says, there is no need to include source or ask people to recompile. The binary can undergo a reversible transformation at installation (or even at load time). Then, during execution, each instruction is essentially decrypted/decoded with the appropriate secret key.

One of the major benefits of instruction set randomization is that you *don't* need the source code or to recompile to get the security benefits.

The only *real* downside is the performance hit (and the fact that it doesn't counter all possible attacks, but then, nothing does.)

Re:If each computer is unique...

[Anonymous Coward]

Actually, I think the idea has a lot of merit, and there wouldn't really be an obstacle to distributed pre-compiled binaries this way. The obvious solution is to use a bytecode-based approach, but there are others which would be faster and almost as effective.

Basically, all you need to know is how to translate a binary in one of N ways, and you've basically defeated the practical ability to exploit most remote code execution attacks.

For instance, many buffer overflows can only send so much data in primary payload, so they need to make system calls to download the rest. If you randomized the system call numbers at the time the application starts, then there's no way for the buffer overflow to download its payload. And how do you change the system call numbers? Simple: Just have the compiler generate the information, and then have the dynamic linker make the fixups, just like it already does for dynamic symbol resolution.

Now, procedure calls are still at fixed addresses, so the buffer overflow can read the code segment to get at the real system call numbers, assuming the program uses them, so a better solution would be to randomize addresses, like execshield does. (Doing it at a finer-grained level than shared objects is probably a good idea, though.) And all this rewriting great diminishes the usefulness of shared libraries to keep down memory footprints, but that's probably an acceptable trade-off. After all, the code doesn't take up the majority of the space, the data does.

I think there'd be significant problems with JIT compilation, but it's probably not insurmountable, albeit with weakened security. (After all, if you have code to change canonical form to whatever randomized instance you're using right now, there's a big hole waiting for an exploit to take advantage of. But you can lock that part down as carefully as you can.)

Basically, binaries just need a little bit of extra information to allow them to be easily randomized, not a huge, extensive amount. Just the same order of magnitude needed for dynamic linking; information to scramble basic blocks. This does expose further information about binaries, but not enough to really greatly decrease the difficulty of reverse engineering, which is a pretty poor reason anyway. After all, disassemblers are already quite effective on the code generated by most compilers.

Another advantage of such randomization is that you can probably eliminate a lot of consistently pathological cases for free. This is the same approach taken by randomized hashing functions, which are used to prevent, say, maliciously-chosen symbol names from bogging down the performance of a compiler. Such names may work for a specific run of a compiler, but in any other run, the hash functions are randomized differently and the same names are no longer pathological.

I think it's also noteworthy that this research was apparently headed by a woman, and I think we should applaud more prominent female researchers in computer scientist in general.

Re:If each computer is unique...

[Crussy]

I believe both of you missed the point of the article. Code obfuscation wasn't the goal. That exists now. If I want to move around bytes in some form of reversible transformation I can download one of a plethora existing tools on the internet. The article suggested having the processor actually use a different instruction set. The binaries would be specific to the computer on which the code is run. It's not a polymorphism idea at all. It is creating unique executables for unique computers. The difference hear is that there is no reversible transformation. The code runs natively in it's altered state... which wouldn't be feasible with binary only installs.

Re:If each computer is unique...

[airConditionedGypsy]

I wasn't suggesting "moving bytes around." The binary undergoes a reversible transformation (like XOR with some key). This creates a "new" binary based on a "new" instruction set specific to the key used in the transformation. Then the binary is decoded at runtime with the key. Anything injected into the binary causes an exception (either invalid opcode or invalid memory reference, etc.) The idea is the same whether or not a software system does the execution (an emulator) or the hardware does it (special new chips from Intel).

Security through obscurity?

[npcompleat]

This would appear to be an attempt to increase security by hiding the instruction set. Security through obscurity is not effective for long and anyone interested in hardening their system would be much better advised to use defence in depth.

In the tradition of Slashdot, I have not RTFM but I imagine that this technique would not help with non-binary code injection (e.g. SQL).

However, increasing the diversity is a valid weapon against scripted attacks (including those real-world, RNA scripted viruses). Perhaps we should encourage the proliferation of incompatible GNU/Linux distros? Or encourage Bill to come up with even more versions of Windows Vista?

Unfortunately, Internet protocols work best when everyone uses the same rules. So the most important vectors for intrusion have to remain standard. Come to think of it, it's those pesky protocols that are causing all the trouble!

Re:Security through obscurity?

[Jeremi]

This would appear to be an attempt to increase security by hiding the instruction set. Security through obscurity is not effective for long and anyone interested in hardening their system would be much better advised to use defence in depth.

The idea is to protect against automated attacks that currently rely on undefined behaviour that is the same for all targets. Example: Currently, if you can figure out how to fool Internet Explorer into munging memory at the right spot, you can use that knowledge to inject code and take over Windows. So all you need to do is add that hardcoded routine to your virus, and pretty soon you've got your Legion of Spam Zombies.

Now imagine if Microsoft used a technique like the one described in this article. Suddenly, there is no "one right spot" that will work for every copy of IE, because now every copy of IE has had its configuration redone in a randomized way. Now your virus is only good for taking over the machine you developed it on -- it might make other machines crash, but it won't be able to take control of them. Hence your virus can't spread.

Re:Security through obscurity?

[shmlco]

"In the tradition of Slashdot, I have not RTFM but..." here's my opinion anyway.

Sort of a microcosm of the world at large, don't you think?

Re:Security through obscurity?

[airConditionedGypsy]

In fact, the general concept of "instruction set" randomization, where instruction set is loosely defined can be broadly applied. In particular, this paper looks at SQL randomization:

http://www1.cs.columbia.edu/~angelos/Papers/sqlran d.pdf

and this paper also looks at instruction set randomization, and randomizing Perl:

http://www1.cs.columbia.edu/~angelos/Papers/instru ctionrandomization.pdf

Re:Security through obscurity?

[An Onerous Coward]

So, what you're saying is that the idea is useless because it can't protect a given machine from an attacker that knows its key?

Isn't that like saying an immune system is no good to you because it doesn't stop your neighbor from running you down with his car?

Or staying closer to the original analogy, it would be like saying you shouldn't get a booster shot, because someone can always create a virus hand-tailored to exploit your genetic makeup.

Re:Security through obscurity?

[npcompleat]

What I'm saying is that most exploits start with a port scan to determine operating system and vulnerable services on the victim machine (ironically, it's the diversity of the responses to the scan that reveals the information). Then the attack generally involves supplying data to a service program to gain entry to the machine. Since most of these attacks do not rely on injecting binary code, this attack would work regardless of the instruction set of the machine. Once on the machine, determining it's key would be straightforward (since the 'plaintext' of many executables would be known) and wouldn't significantly slow an attacker. Also, many of the fingerprinting techniques used to spot malware would be less effective as the binary signatures of the executables would be different on each machine.

Re:Security through obscurity?

[An Onerous Coward]

I think you're wrong, in that most attacks do rely on the injection of binary code. Every buffer overflow exploit I'm aware of involves overwriting the stack, replacing the OS's instructions with the exploiter's code, then having that code execute. That's the step you identify as "sending data to the service", which is correct. But it needs to be the right data: the code that will make the machine do what you want.

While the plaintext of the executable may be known (sometimes you get custom compile jobs), the encoded instructions aren't known to the attacker, and cannot be discovered without executing instructions on the machine to read the memory where the executable resides.

Finally, I'm not sure about malware detection, but it might not be a problem. If I'm understanding properly, the software publisher would send the plaintext instructions, and the destination computer would translate those instructions into ones that worked inside this particular system. So either the program could be translated back into plaintext for matching purposes, or the signatures could be translated into the obscured instruction set. After all, the instructions are simply being translated, not encrypted.

I'm fairly sure I'm right about... well, some of this. But if I'm not, I do look forward to being enlightened.

Re:Security through obscurity?

[npcompleat]

I'm fairly sure that you're right about most of that too! You're definitely right about buffer overflows but canary values and randomised positioning of the stack (diversity again) are making those harder and more vulnerabilities seem to be non-binary attacks. I've no hard figures to support this though.

However, once on a machine using a non-binary exploit, I can use the executables on it to transfer a sample of known programs to my machine, where I can crack the code using standard techniques (in effect, it is a Caesar cipher). When I know the mapping from the 'standard' instruction set to the one used on the victim machine, I have circumvented the protection offered by randomising the instruction set.

If there is a program to take plaintext instructions and translate them so that they work on the victim machine, as you suggest, then I don't need to crack the protection at all.

You are right in as much as I cannot use binary attacks and I have some extra work to do but it doesn't seem as though the system is significantly more secure.

Here's a compsec / biology paper that ISN'T banal

[Anonymous Coward]

Wow, what a boring article. Is it just me or is this the old concept of address space layout randomization (first implemented in 2000 in PaX, then subsequently stolen for BSD), which has nothing to do with biology, except for the obvious tie-in with the monoculture argument?

Here's a real application of biology to computer security: automatic classification of malware. Know what family a new piece of malware belongs to without any human being having to analyze it manually. Fascinating paper.

Intermediate compiliation state

[hackwrench]

Essentially the final instruction sets are weak encryption on one base instruction set. If a virus were to attempt to inject itself as running code, it would be bypassing the encryption process.

That depends...

[CarpetShark]

Would that include extinction of species with inadequate immune systems?

That depends on whether the weakest creature happens to have a monopoly stranglehold on the PC desktop market, and a prooven interest in manipulating the political system to keep it that way.

But it would be hell to support

[Alhazred93]

Tech support for large companies is tough enough as it is - throw deliberate diversity into the mix and support would become a nightmare.

Re:herro

[neonprimetime]

that randomizes an application's machine code

I think they got ahold of your pc! Either that or you just can't type.

Microsoft and Cockroaches

[CustomDesigned]

Cockroaches don't fight off infections. Their systems are designed/evolved to work in spite of infection. This makes them dangerous for creatures that do fight off infections. This also seems to be the direction Microsoft Security is headed. And no, Paladium doesn't stop infection via security flaws. It only stops infection via idiot users.

Re:Microsoft and Cockroaches

[hr raattgift]

Cockroaches don't fight off infections. Their systems are designed/evolved to work in spite of infection.

No, B. germanica, like other arthropods, has two primary active immunocytes, namely the granulocytes and the plasmatocytes. The former are particularly cool in the cockroach -- their granulocytes (GRs) discover, encapsulate, and phagocytize foreign substances. In fact, unlike in other arthropods, cockroach GRs are particularly active in terms of encapsulation; they flatten and increase the number of microtubules and nuclear membrane pores. The latter mechanism enables the rapid production of tubulin by increasing the "channel width" between the ribosomes and the nuclear DNA. The former protects the GRs from the shearing forces the rapid encapsulation response creates within the cell. The cockroach GRs are in some ways closer to the human macrophage than to typical arthropod active immunocytes.

Plasmatocytes (PLs) adhere to foreign substances in a clotting response geared to isolate it from the rest of the cockroach. PLs also have a phagocytizing role in the cockroach.

Both the GRs and the PLs display an accelerated response if the organism is reintroduced to the same foreign substance. This suggests that the cockroach immunocytes have the same sort of "memory" as vertebrate neutrophils and macrophages.

Cockroaches meanwhile are also a host to a variety of microbes which provide a degree of passive immune response to common antigens -- various intestinal flora produce narrow-spectrum antibiotics which ward off dangerous infections.

Although cockroaches have somewhat weaker structural defences against infection (spiracles for breathing instead of cilliated, mucous-protected airways; low pressure in the hemolymph instead of a bleeding response which washes away microbes in the envent of a skin/chitin-penetrating trauma), they have a highly-reactive immunoresponse which is less-costly energy-wise for the individual than regenerating tissues destroyed by infection and more successful (in the evolutionary fitness sense) for the species as a whole than accepting a lowered production of viable offspring because individuals are debilitated by infectious disease.

In general the more cosmopolitan pests in Blattaria/Blattodea are biologically successful because they can cope with all sorts of toxins and microbes found in household detritus and waste that concentrates in cockroach feces, which is usually found near -- or in -- their food supply.

So you would be more right if you said that cockroaches are evolving in environments full of infectious agents, and are obviously pretty successful there.

Otherwise healthy household mammals that encounter cockroaches have little to fear from cockroaches, their "helpful" microbes, their "harmful" microbes (which are held in check by the cockroach immune system), or whatever concentrates in their feces, except that there are some humans (and probably other mammals) who suffer an intense immunoglobin-E mediated allergic reaction to many antigens which accumulate in cockroach poo.

Re:Microsoft and Cockroaches

[Anonymous Coward]

It's replies like this which keep my interest in Slashdot alive.

Thanks!

ObCondom joke.

[Rob T Firefly]

"But honey, with too many layers of data protection, I can't feel the Internet properly!"

....sorry.

Been there

[Anonymous Coward]

Our programmers already use "random instructions" in a lot of applications. As in, try this and see if it works.

Too much diversity is bad for management

[a55mnky]

New Page 1

In theory this might work to provide slower spreading infections, in practice it will cause more problems than it solves .

As a security practitioner for more than ten years, I can tell you that this type of diversity makes security management more difficult. Can you imagine trying to troubleshoot a problem when you don't know what the code is supposed to look like this time, or where it loads this time or how it interacts with other components this time.

I can also say that pretty much without exception, from a security perspective I recommend all of my clients create a standard base from which to build their enterprise systems. Standardization makes patching, maintenance and forensics much easier. This does not mean that I recommend all systems are deployed on the same platform, just that for each platform, application, system, the configuration and versions are the same.

While it is true that diversity can be helpful and a totally homogenous environment is bad for security - dynamic, morphing applications just smells like trouble to me.

Re:Too much diversity is bad for management

[Aram Fingal]

My experience has been quite the opposite. We have had many incidents in the last three or four years where we had to have IT staff go around to every computer of a specific type and do a particular procedure to handle a security issue. For example, a while back we had to go around and manually remove the PNP worm from every machine running Windows 2000 on our network. This was before the patch came out on Windows Update. It took about three days to get to every machine and it would have been a lot worse if the percentage of Windows 2000 computers had been higher (it was about 25% at that time). Three days was fast enough that there was hardly any down time for workers. Note that Windows XP was largely unaffected by this worm (at least on our network). Four years ago, when we had around 60% Windows NT, there was an incident where we had to fix every Windows NT computer (I don't remember exactly which virus that was right now) and some computers were down for almost two weeks because there were just too many for our staff to handle. We had some people unable to work for a few days.

We have a staff of several IT professionals and everyone has their own specialty but everyone knows the basics of the other specialties as well. When a major security incident like one of the above happens, we all pitch in to work on that one issue. For example, the Mac specialists are perfectly competent to go around and clean viruses off Windows computers according to a quickly thrown-together procedure.

Conventional wisdom of upper management seems to be that we would be better off upgrading all the Windows users to XP because it's more secure than Windows 2000. There is a lot of truth to that but there is also a down side. If we have 60% Windows XP, which would be the rough figure because we have around 30% Macintosh and you need to figure another 10% for others, including other versions of Windows (which you can never quite get rid of) then we would be set up for an incident like we had when we were mostly Windows NT. If something did happen that affected every install of Windows XP at once, we wouldn't have enough staff to deal with it in a timely fashion.

I should point out that my goal is to handle the broader issue by throwing some thin-client into the mix. It's something that everyone agrees is a good idea but it's a tough sell for almost every single specific case. In other words, everyone thinks it's a great idea to have more people using thin-client but hardly anyone wants to use it themselves instead of a Windows PC or Mac.

Genetic Programming

[cristij]

We already have malicious code that can replicate and spread itself. The only thing we're missing in terms of real Darwinian evolution is mutation

Actually there is code that does just that, but as far as I am aware genetic programming hasn't been used to make viruses.

Obfuscators

[audi100quattro]

how is this different from code obfuscators?

Proper Dawinian virus.

[caluml]

A computer virus that followed Darwinian evolution (as I understand it) would make copies of itself, each with a small change, and execute it. Eventually, (infinite monkeys at infinite typewriters) it will create a better virus. Repeat infinite times.

old idea, for me at least

[Anonymous Coward]

I came up with an idea like this many years ago - my company wasn't interested in patenting it, apparently because they already had their own pet virus-fix idea under development.

Implementing it would have been pretty trivial, with no run-time performance penalty and only a tiny hardware addition.

So how is sharing code going to achieve this?

[Anonymous Coward]

If everyone is sharing code from everybody else, how much code will be unique enough to really achieve diveristy?

The attacks will just be target to stuff that is used by more people. In order to do this you must use a bunch of proprietery stuff! Think about it.

Not being a Linux person, I ask - how much of the kernel is really diffrent between all the flavors?

Now granted, you can do some stuff to break exact binary injections, but what about the basic exploit?

Gentoo?

[solune]

Seems to me Gentoo is the ideal candidate for this type of thinking. With the variety of hardware out there, the combinations of assembly boggle the mind.

Effectiveness of Instruction Set Randomization

[cquark]

A 2005 paper by David Evans, "Where's the FEEB? The Effectiveness of Instruction Set Randomization", demonstrates how to remotely determine the key for this protection scheme in under 6 minutes. The paper goes on to examines diversity defenses more broadly to examine schemes that might be resistant to such attacks. The author also gave an interesting talk at USENIX Security Symposium on What Biology Can (and Can't) Teach Us About Security, which is probably a better paper for this article to point to.

Re:Effectiveness of Instruction Set Randomization

[Anonymous Coward]

Actually, no. They were not able to break RISE. They had to modify it in order for their attack to succeed.

From their paper: "We executed our attack on our constructed vulnerable server protected by RISE [3]. The RISE implementation presents a major difficulty in executing our attack because of the way it implements fork, pthreads and randomization keys. This necessitated a small modification to RISE in order for our attack to succeed.

Perhaps an attacker could control the execution enough to ensure that the necessary masks are initialized before the child process forks to ensure they would be the same on all executions. This would only happen, however, if the server legitimately ran code on the stack before reaching the vulnerability. Hence, the RISE implementation of ISR is not vulnerable to our attack.

In order to experiment with our attack, we modified RISE to initialize the masks for all used instruction addresses before the child process forks to ensure that all child processes have the same key. Obviously, a real attacker would not have this opportunity."

RISE... isn't that similar to PIC?

[Falcon040]

So, isn't RISE (Randomized Instruction Set Emulation) similar in concept to PIC (Position Independent Code)?

If you want to secure computers via the Linux route then with Hardened Gentoo is a good way (Follow the Resources links in sections 6).

PaX is a hardened Linux kernel using ASLR (Address Space Layout Randomization) to support applications built as a PIE (Position Independent Executable) and to provide non-executable memory (NX).
PaX home.

PIE/SSP (Position Independent Executable)/(Stack Smashing Protector) (follow PaX link)
When an application is built as a PIE (Position Independent Executable) the code is able to be randomize on load up and NX bit set on certain parts of the application. At run time, when a buffer is created, SSP adds a secret random value called the 'canary' to the end of the buffer.

MAC (Mandatory Access Control) (follow Hardened Gentoo link)
Hardened Gentoo supports 3 access control solutions, SELinux , grsecurity , and RSBAC .

PIC Introduction and Internals.

Other references:
Hardened Gentoo Primer
SeLinux is supported by the NSA (National Security Agency) of the USA.

Have we isolated the "stupid gene" yet?

[texaport]

Nature presents "tests" for advancement, here is today's email from postings@ic.fbi.gov

" The following Federal Bureau of Investigation job was just posted at https://jobs1.quickhire.com/scripts/fbi.exe "

Job # HO-2006-0045 (0080 Security Specialist) $108,145.00

Is this really just a test of whether a real IT person would:
1. Click a link from inside an Outlook variant?
2. Navigate to a folder called "scripts" using a Microsoft product?
3. Start an immediate download of a Windows EXEcuteable?

Submitted for your approval -- I am not making this up(TM)

simpler binary diversity is good

[thogard]

Its easy to make a binary that is less subject to unknown attacks than the factory versions. I've been doing this for years and its not too hard. Start by building everything from source. Find the link order and change that around. Look at the build options since you may not need that -O2. There are programs that will rearrange the order of the variables which changes the stack order and some will even rearrange the calling order. You can even add filler as well. If your going to rebuild an entire os, you could go far as to reorder the constants in /usr/include before you rebuild it. If a program expects syscall 4 to be open() and you've changed it to select(), their code is going to break real quick.

Nothing new...

[dalmozian]

This idea is an implementation of Automated Diversity, presented in 1977 (!!!), furthermore the RISE method is described here in a paper from 1995.

how about just fixing the Memory Management Unit

[rs232]

How about just fixing the Memory Management Unit so as it don't get buffer overflows etc. And don't say it ain't possible.

As for the above I recall reading something similar about scrambling the microcode table and the opcodes in the actual program residing on disk. Since each processor would have its own unique instruction set viruses/trojans would be stopped in their tracks. And what's more you don't have to learn Calculus

... just like Fermat

[Bruce Losis]

I have already produced a truly marvelous implementation of this proposition which this text box is too narrow to contain.