[Full-Disclosure] UN support for "security by obscurity"

From: Rick Updegrove (security@updegrove.net)
Date: 12/07/02

From: security@updegrove.net (Rick Updegrove)
Date: Sat, 7 Dec 2002 10:10:53 -0800

> ----- Original Message -----
> From: "Brian Hatch" <full-disclosure@ifokr.org>
> To: "Richard M. Smith" <rms@computerbytesman.com>
> Cc: <full-disclosure@lists.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
> 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.


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

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

Rick Up

Relevant Pages

  • RE: Concepts: Security and Obscurity
    ... resources are limited and thus there is a cost to life. ... It is not obscurity in the manner being ... more you spend on security the less of an advantage is gained. ... It also ignores the requirements of a control function. ...
  • RE: Re: Concepts: Security and Obscurity
    ... so long as you understand that the server location and port number ... security in the slightest." ... Beale's assertion that "Obscurity Potentially Slows Down the Attacker". ... BDO Kendalls is a national association of separate partnerships and entities. ...
  • Re: NAT external/Public IP
    ... I remember working for an ISP a long while back that was threatened to be disconnected from the Internet if they did not stop routing the 10.x range in their BGP tables. ... Any views expressed in this message are those of the individual sender and not necessarily endorsed by BDO Kendalls. ... Why not Security by Design plus Security by Obscurity? ...
  • RE: Concepts: Security and Obscurity
    ... Subject: Concepts: Security and Obscurity ... I have at no point claimed absolute security measures or cost ... It also ignores the requirements of a control function. ...
  • RE: Re: Concepts: Security and Obscurity
    ... Subject: Concepts: Security and Obscurity ... BDO Kendalls is a national association of separate partnerships and entities. ... Maybe we can all agree that "port obscurity" is a special case of STO. ...