lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: bkfsec at sdf.lonestar.org (Barry Fitzgerald)
Subject: No shell => secure?

Ron DuFresne wrote:

>	[snip]
>
>  
>
>>This is not security through obscurity. This is security through
>>incompatibility. The point of the idea is to make it necessary for an
>>attacker to rewrite an exploit for my system specifically. This is
>>something that over 99% of the potential attackers would not do, because
>>they don't care about my system. When you have an exploit that works
>>against all the RedHat boxes on the Internet, would you bother to
>>customize it so that it works against one single server of one single
>>random weirdo? It's not worth it.
>>
>>    
>>
>
>beleive and redefine well known terms and methodologies as you wish, it
>remains none-the-less as I and others have pointed out nothing more then
>security via obscurity.  and bears the dangers as some others have pointed
>out that you will most likely end up with an unusable system.  On a number
>of vender OS', if the sh shell of csh shell, hooked to root user and
>startup scripts is not the expected defaults, those OS's fail to function
>properly on and tween reboots.
>
>  
>

I think you guys need to stop arguing because you're both right.

Yes, changing the shell executable names is security through obscurity.  
Yes, it's also security through incompatibility.  If he builds the 
system from scratch, it doesn't matter what other distributions do -- 
that's irrelivent at that point.  It also doesn't matter if he breaks 
the standard, he can choose to do that if he wants.

Doing this won't stop all potential attacks and it will stop many of the 
automated attacks that exist in the wild. 

Those are the facts as they boil down.  I think we go a little bit 
overboard when we say that security through obscurity is bad.  I think 
that we've gained this knee jerk reaction because people try to pass off 
obscurity as security, but in the end, obscurity can be a useful 
security tool.

Part of the reason that people deploy firewalls is for obscurity.  
People munge headers for security.  People rename user accounts for 
obscurity.  The very purpose of using encryption is to obscure data. 

Do these actions stop crackers from gaining access to systems?  Do they 
make them less vulnerable?  Not really.  They do, however, cause the 
attacker to increase the amount of time it takes to carry out a 
successful attack - and that is worth something.

All theory aside, the fact of the matter is that if something takes too 
much time it will deter *most* people from trying.  (I say most people 
because there's a class of cracker that is actually motivated by a 
lengthy challenge, but if you've attracted their attention you'd have 
been cracked regardless of whether obscurity was used.)

Relying on obscurity is bad.  We know that closing the source code of a 
program doesn't make the program more secure.  We know that changing the 
port of your HTTP server doesn't make it immune to compromise. 

But, to go from that set of points and then to claim that there's no 
value to any form of obscurity is to make a logical leap that is not 
supported by strategic fact.

If he's willing to go through the trouble of maintaining his own flavor 
of GNU/Linux so that he can have renamed programs, then that's his 
prerogative.  It will buy him something.  I think tying that to never 
having been rooted is a stretch, but it isn't of no value at all.

             -Barry

 p.s. No offense meant to any party.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ