[lug] NFS

[Pedersen, Michael J]

> 2) If I can determine which version of NFS you are using, I 
> can hack my
> version to specifically send yours information which gives me 
> privileged
> access to your system, possibly.  After all, your NFS is open 
> to the world,
> which means I can read the source, find the weaknesses, and 
> then try to
> exploit them.
[snip]
> Incidentally, #2
> is the whole reason behind "security through obscurity", 
> which has been
> shown to be a very bad idea far too often.

After reading my post, I realized that I hadn't explained precisely why
security through obscurity is a bad decision, but will try to do so now,
with one of the most public examples I can provide.

Many of you have probably heard of DES as an encryption mechanism. This
algorithm was derived only 20 or so years ago (or was it longer?  I can't
remember the exact time span).  However, after it was developed, it was
published, and made available for people to use.  Then the atacks began.

People studied DES.  They explored possible weaknesses.  They pounded on it,
hard.  And you know what?  Except for one detail, DES it still holding up
strong enough that it's used by banks to secure financial transactions. That
detail? It has either 40 or 56 bit keys.  Keys that small are actually
crackable within a day anymore, with special purpose hardware (that costs
less than $100,000). So, DES is being phased out.

However, DES is considered secure.  The best cryptographers in the world
have analyzed it to death, and the algorithm itself still holds.  Only the
hardware has gotten fast enough to break the key.  The value of open-ness is
displayed here, and is added to with one other detail: During the
development of DES, the NSA helped out to strengthen it. Two groups, working
together, created an algorithm that has stood the test of time.  If the key
were a full 128 bits, it would be considered uncrackable by any computers
which have been built or would be built for the foreseeable future.

What has security through obscurity provided?  One glaring incident comes to
mind: Netscape 1.1.  After it was released, complete with the SSL that they
wanted people to use, somebody asked to see how secure it was.  Netscape
told them that they would absolutely not release their source code.  Well,
Netscape DID make a mistake.  It turns out that their random number
generator (a crucial part in the process) was flawed.  A pair of college
students, doing some reverse engineering, found this out, and showed
netscape how they could crack the "secure" encryption that Netscape
provided.  Suitably chastised, Netscape made 1.2, with a better random
number generator.  But still didn't want to let people see their code.

Such lessons have happened repeatedly.  When things are open, they are
secured faster, and better, than their closed counterparts.  Quite often,
when a closed product has a security hole, the costs to fix it are
exorbitantly high (just ask Windows NT administrators how much time they
spend on installing each service pack to get an idea of the lost time, and
therefore cost, of such fixes). Then ask Linux admins how much time they
spend on such service packs, to get an idea of the differences.

Anyway, sorry for the lecture/ramble.  I'll be quiet for a few minutes :)