This classical paper of Paul van Oorschot: Revisiting Software Protection, mentions in section 3.4 that by employing software diversity "an exploit crafted to succeed on one instance will not necessarily work against a second" software instance.

I know that software diversity does not eliminate the possibility of re-executing an attack on a different/diverse software instance. It simply causes an exploit built for one software instance to (possibly) not work against another software instance that has the same function.

My question is when will an exploit for one instance not succeed on a different instance? What kind of attack performed by an exploit will fail if software diversity is employed?

I've seen many papers stating that software diversity protects against code-reuse attacks, with Return-Oriented-Programming and Jump-Oriented-Programming being given as an examples. I'm wondering if there are some other attacks which diversity protects against as well.

  • 3
    Your question is misconceived. No kind of exploit is prevented by diversity. Diversity simply ensures that no one exploit can exploit all installations, so even though the exploit succeeds and destroys part of the system, the system as a whole survives.
    – Ben
    Jan 27, 2014 at 21:44
  • @Ben you are right. I realize that diversity does not eliminate any attack method. It simply ensures that an exploit does not work on all software instances. An exploit crafted for a software instance (using a certain attack technique), will not work on the "other parts of the system" as you mentioned. I'm interested in which are these attack techniques. Because even if there are more (diverse) parts they will not withstand all types of attacks.
    – Benny
    Jan 28, 2014 at 15:39
  • It isn't a question of any specific type of vulnerability. It's just a general rule that different systems will have different actual vulnerabilities, even though they might be the same type of vulnerabilities.
    – Ben
    Jan 28, 2014 at 16:00
  • @Ben I think there is some confusion as to what the difference between the terms "attack", "exploit" and "vulnerability" is. For me an attack is a general method, an exploit is an instance of an attack and a vulnerability is a type of software fault that can be exploited by an attacker.
    – Benny
    Jan 28, 2014 at 16:08

2 Answers 2


One example would be a buffer overflow attack. These are often very specifically targeted against specific versions of application software. If you had an exploit that worked against IIS 7.0, that same exploit would not also work on Apache.

A counter-example would be a cross-site scripting attack, which only attacks the client's browser, and is agnostic to the internal applications.

With a homogenous ecosystem, a virus that can infect one vulnerable system can easily spread to infect all identical systems, or an exploit that can be run one one machine can be scripted to run on many.

Diversity provides redundancies, and they can help limit your damage. If you have two brands of gas pumps in your store and a virus starts stealing credit cards, it may only steal half of your customer's cards.

The drawback to diversity is if it presents two attack surfaces for an attacker to choose from. The gas pump example above is one such scenario. As an attacker, I can try attacking the easier of the two pump softwares, and if I breach either, I get to steal half your credit cards. As a thief, stealing half your gold is still a lot of gold, and is worth it.


Diversity is now less valuable than this paper suggests. As security practices have dramatically improved since 2003, threats have become increasingly sophisticated as well. The paper concerns itself only with "dumb" attack vectors such as viruses, which were a bane a decade ago, but thanks to improved security are now far less successful than they were then.

Modern threats are targeted and tailored to the victim system. They identify the software through fingerprinting methods, then craft an attack designed to defeat it. Tools like autopwn mean that a diverse environment simply provides extra chances for a system to be vulnerable.

Diversity takes advantage only of security through obscurity. A diverse system might be considered safe only because so few of them exist that an attacker has never bothered to explore it fully to find its weaknesses, or that the target is of such low value that there was no reason to attack it. Advances in botnet technology mean that even ultra-low-value targets like refrigerators or thermostats can deliver value to an attacker either through spamming activities, or perhaps as a target for ransomware, so they're becoming increasingly studied by attackers for vulnerabilities. That means that a thermostat's cloud service on your home network may end up being the entrypoint for an attacker to get behind your firewall, where he can attack your banking PC at his leisure. In this case, diversity unwittingly enables the attacker.

Up until not too long ago, I had thought diversity was a good strategy. After watching attackers ply their trade, I am now convinced that it's almost irrelevant, and that effective security practices need to remain the primary focus of security teams. Simplifying systems, reducing their attack surfaces, application reviews and security analyses, separation of duties, isolation of credentials, key and certificate management, and clear security policies, those are the effective practices.

  • I would give you +1 because you understood my question, but I don't have enough reputation. Anyway, ROP exploits are actually include overwriting the elements on the stack as is the case for stack buffer overflow. I'm wondering if there is anything else.
    – Benny
    Jan 28, 2014 at 16:33
  • The thing to understand is that diversity does not "protect" you so much as it changes your risks. A buffer overflow attack against program X doesn't go away because the computer next to it is running program Y. It only means that Y won't suffer the same fate. Jan 29, 2014 at 4:54
  • Perfectly agree with you John Deters. The buffer overflow is a semantic bug, not a syntax bug. Since software diversity tends to change the syntax while maintaining the semantics of a program, the buffer overflow attack will not go away. The effect of diversity is that the exploit payload for one instance will (probably) not work on another (diverse) software instance.
    – Benny
    Jan 29, 2014 at 10:13

Van Oorschot is writing about redundancy. Imagine you have to balance the access to your network and you need to add two firewalls. This means that a user will face one firewall or another when accessing to your servers, so if one of them has a bug and the other one is safe, the user can't choose which firewall will be active.

Also, if you spot a bug in one firewall you can deactivate it temporarily and use the other one while upgrading it.

Also you protect your assets since a company may bankrupt and you may find yourself without assistance for your servers. If you have different servers/appliances you are diversifying your investments.

(I wrote this on mobile so it may need some rewriting)

  • Thanks for your answer. However, it seems that you are trying to explain n-version programming and its application to network firewalls. This is not what I was asking. I'm interested in examples of those "bugs" in the firewall (you referred to in your answer), which are "fixed" by software diversity.
    – Benny
    Jan 26, 2014 at 15:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .