Onderwerp: To diversify and survive: the application of population biology

Abstract:
On January 25, 2003, the SQL Slammer worm (w2.SQLSlammer.worm), also known
as Sapphire (F-Secure), w32.SQLexp.worm (Symantec), and Helkern
(Kaspersky) fully exploited known vulnerabilities in Microsoft SQL 2000
servers and caused tremendous network jam around the world. In this
article, the concept of population biology is proposed to apply to the
computer programming. The concept is to diversify the same software
functionality with a population of executables to avoid being eliminated
or exploited by a virus or worm like SQL Slammer.
---------------------------------------------------------------------------
-
In biology, it is a known fact that a species with a diverse population is
less likely to be extinct than a species with a "cloned" population under
selection pressure. It is one of important reasons why we want to keep the
biodiversity, I believe.

What the SQL Slammer has exploited during the last weekend exposed not
only the vulnerabilities in Microsoft SQL 2000 but also the
vulnerabilities in the normal delivery methods of software package. A
normal software package contains the same documents, the same executable
files. In other words, the package is just copied or "cloned" without
diversity. What just had happened taught us a lesson about the importance
of diversity in computing world as well, I think.

If we study the SQL Slammer worm in assembly language
(http://www.eeye.com/html/Research/Flash/sapphire.txt) carefully, we will
realize how selective or "laser-guided" this worm is. If the population of
the SQL 2000 server executable had been diversified, then the impact of
the SQL Slammer would have been much less noticeable.

So, I propose the concept of installation time linking to diversify the
same software functionality with a population of executables. In other
worlds, different executables have the same functions.

Installation Time Linking Of Object Files Into An Executable

The concept of the installation time linking is that it enables the
executable to be randomly laid out (including the Import Address Table
abused by the SQL Slammer). Functionally speaking, the executable image #1
and image #2 listed above in Figure 1 are the same even though the layouts
are different. Therefore, if a program like the SQL Slammer is targeting a
special executable program, it will lose its effectiveness on another
executable because of different image layout or addresses, (unfortunately
it might crash the application).

The disadvantage of this technique is that it requires more customers'
support if the software has problems. It might become more difficult for
the vendors to patch or provide so-called service packages, (well a
service package just simply overwrites existing files or adds new ones
currently, right?).

If this concept goes further, then the operating system does the dynamic
linking of libraries or object files in a randomized order as well to
diversify further.

Whether this concept is practical or not remains to be seen.
---------------------------------------------------------------------------
-

For the article with the figure 1, please visit
http://members.rogers.com/yinrong/ar...nComputing.pdf

Thank you and have a nice day.

Peter Huang
http://members.rogers.com/yinrong

--------------enig4C8C327E162B217EDE49E3EE
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Huang wrote:

>Abstract:
>On January 25, 2003, the SQL Slammer worm (w2.SQLSlammer.worm), also known
>as Sapphire (F-Secure), w32.SQLexp.worm (Symantec), and Helkern
>(Kaspersky) fully exploited known vulnerabilities in Microsoft SQL 2000
>servers and caused tremendous network jam around the world. In this
>article, the concept of population biology is proposed to apply to the
>computer programming. The concept is to diversify the same software
>functionality with a population of executables to avoid being eliminated
>or exploited by a virus or worm like SQL Slammer.
>
Read this paper to see the relative strenghts and weaknesses of the
biodiversity defense:

"The Cracker Patch Choice: An Analysis of Post Hoc Security
Techniques". Crispin Cowan, Heather Hinton, Calton Pu, and Jonathan
Walpole. Presented at the National Information Systems Security
Conference (NISSC) <http://csrc.nist.gov/nissc/>, Baltimore MD,
October 16-19 2000. PDF <http://wirex.com/%7Ecrispin/crackerpatch.pdf>.

The concept of biodiversity goes back many years. The first computer
biodiversity paper I am familiar with is this, but there are undoubtedly
earlier examples:

"Self-Nonself Discrimination in a Computer (1994)" (Make
Corrections) (44 citations)
Stephanie Forrest Alan S. Perelson, Proceedings of the 1994 IEEE
Symposium on Research in Security and Privacy.
http://citeseer.nj.nec.com/forrest94selfnonself.html

The biodiversity defense relies heavily on analogies to proper biology.
My counter-analogy is that yes, biodiversity works as a defense in
nature, but not anywhere near as well as skin does. Organisms have skin,
cells have membranes, and these organs do most of the work of keeping
pathogens out of the organism. Computer systems (even with firewalls)
have really crappy skin, if they have any at all. Investing in better
skin will return greater results than biodiversity for a long time to come.

But the trouble with analogies is that analogies are like goldfish:
sometimes they have nothing to do with the topic at hand :-) So without
resorting to anlogies, the concrete argument against the biodiversity
defense is that biodiversity induces incompatibility. For it to be an
effective defense, the biodiversity has to impose *more* incompatibility
on the attacker than it does on the defender. This is problematic,
because while you know what artifacts the defender depends on, you do
*not* know what artifacts the attacker is depending on, so you have to
change every artifact you can think of that does not inconvenience the
defender, and hope that works. Meanwhile, defenders are already feeling
the pain of diversity (heterogeneous systems) and are rushing to
*homogenize* their systems as much as possible, because the expense of
biodiversity exceeds the benefits.

Not to say that biodiversity won't work, just that it is more expensive
than you might like. On the other hand, very often for a given
biodiversity technique (varying some artifact) there is an associated
"restrictive" technique (controlling access to that same artifact) that
will be more cost effective. So go ahead and explore biodiversity
techniques, but don't forget to look around for associated restrictive
techniques that might work better.

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
Just say ".Nyet"


--------------enig4C8C327E162B217EDE49E3EE
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+PuP25ZkfjX2CNDARAc5lAJ4tGVlbGh5LO46EwWHcsk 2faLH2ywCfYt64
YfhvkMAhiiKTCk17LWL7mxk=
=wA1j
-----END PGP SIGNATURE-----

--------------enig4C8C327E162B217EDE49E3EE--