Message-ID: <003c01c29e1b$fb639bf0$0200a8c0@nothing>
From: security at updegrove.net (Rick Updegrove)
Subject: UN support for "security by obscurity"

> ----- Original Message -----
> From: "Brian Hatch" <full-disclosure@...kr.org>
> To: "Richard M. Smith" <rms@...puterbytesman.com>
> Cc: <full-disclosure@...ts.netsys.com>
> Sent: Friday, December 06, 2002 5:10 PM
> Subject: Re: [Full-Disclosure] UN support for "security by obscurity"
>
>
> In the computer world we say relying on security through obscurity
> is bad.[1]  However in this case I might agree with them.  It's a
> very different situation.

No, it is not even slightly different.  Information is information.

> We constantly argue that Open Source makes a level playing field, and
> makes it more possible for us to secure our code.  If a bug is found,
> we can all fix it in the source even before our vendor supplies a new
> version, for example.  If someone writes an exploit, we can use it
> in legitimate ways test our servers for weakness and fix them.

Hooray for open source.  Hooray for full disclosure.

> I don't think comparing code to nuclear 'secrets' is the same thing.
> Does publishing the recipe for a bomb make it easier for me to secure
> anything?  We know that big bomb == lots of distruction.  We can prepare
> for lots of distruction equally without ever having the instructions
> to create the bomb itself.

Anyone can make a bomb of any type, anytime.  The information is already
available, and has been for many years even before the Internet was around.
Moreover, that is good thing, and should NEVER be restricted.  The materials
needed are a different story...

> I wouldn't call this security through obscurity.

Would you call it "keeping secrets" or "lying through omission"?

> I cannot think of a legitimate reason that I'd need the 'code' for
> a missle -- if I want to secure my house from missle attack, I know
> the results a missle would have.  I'd be vaporized.  No amount of
> knowledge about the makings of a nuke would help me there.
>
> I can see a reason I need the code for Apache.  That's something I
> use that I can effectively defend from attackers.
>
> And just to continue the analogy, those who posses nuclear technologies
may
> consider themselves the white hats, and want to keep that knowledge
> from the black hats.  Of course the'd define black hats as
> everyone except themselves.

Anyone with average intelligence could put together a nuke if they had
access to the materials.  The "instructions" are already available.  When
you got your degree, didn't you have to take physics?  Moreover, the people
responsible for "keeping this stuff secret" can't even get a BJ in the oval
office without the entire world finding out.  Do you really trust them, to
keep the information "secret"?

> [1] *Relying* on security through obscurity is bad.
>      However *adding* security through obscurity is good.
>      This distinction is too often overlooked.  Why say "I'm
>      running Apache 1.2.26 with mod_perl and mod_ssl version
>      BLAH" when you can just say "Apache"?  It only makes it
>      easier for crackers to mark you down on their well-
>      tailored lists.

There is no security through security.  ServerTokens Prod is a false sense
of security, and when you think about it offers no real security at all.
Script kiddies will still try the short list of apache exploits.

To me, "Apache" instead of the "Apache/1.3.27 (Unix) mod_ssl/2.8.11
OpenSSL/0.9.6g PHP/4.2.3" means "this admin is:

1.) Lazy and doesn't patch when needed.

and/or

2.) Gullible, and thinks they can somehow magically prevent an automated
worm or a determined script kiddie from compromising their server.

P.S.
The slapper worm variants don't go to netcraft and ask "what's that site
running" before they use root you.



Rick Up

Powered by blists - more mailing lists