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: matthias at winterdrache.de (Matthias Benkmann)
Subject: No shell => secure?

On Thu, 8 Jul 2004 22:34:18 -0400 hax <uberhax@...il.com> wrote:

> I'm not an expert in shellcode, but that thinking seems flawed in a few
> ways: 1)  Tons of scripts rely on /bin/sh being present.  
> It'd be a huge
> deal to rework the system so that everything goes to a new path.

Not really, because a server doesn't need many scripts aside from about a
dozen boot scripts. But that wasn't the point of my question. I'm well
aware of the effort.

> 2)  That'd stop a lot of skript kiddies, I guess, but it'd be pretty
> trivial to just rework the shellcode to call some other command
> instead of /bin/sh.  Everything from vi to mozilla can execute
> commands these days.

As I've said in my post I am not worried about people attacking me
specifically. So someone rewriting an exploit to work against my server is
not at issue here.

> 3)  Changing the file system structure is a *bad* idea.  You'd be
> breaking standards 

Exactly. And that's why it's a GOOD idea. Standards are the whole reason
why worms and mass-exploitation of security holes are possible. 

> and you'd probably
> be breaking most applications.  

Of course I'm not thinking about doing this on an existing system, such as
a SuSE default installation. I'm thinking about building a system from
scratch to use the different paths. And as I've said I am aware of the
effort involved.

> The moral of the story is that security through obscurity is *bad*.

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.

Think about it this way. I create my own operating system. It's based on
the Linux kernel and common Unix programs, but it uses different paths for
everything. This operating system is only used by a single person on this
planet. Will anyone bother to rewrite exploits to work against this
system?
And I repeat that I'm NOT talking about people who want to attack this
system specifically. I'm talking about people/worms that scan IP ranges
for vulnerable systems to run standard exploits against.

There are people who argue that the reason why there are fewer worms that
target Linux than Windows is not Linux's superior security but it's lower
popularity compared to Windows. If all you care about is to get a huge
bot-net with minimum effort or maximum damage with minimum effort, you
target the most popular systems only. 

> You wouldn't really be making yourself much safer, although you'd stop
> some of the mass exploitation scripts,

You're contradicting yourself here. If I'd stop some of the mass
exploitation scripts that would make me much safer, because the mass
exploitation scripts that are run indiscriminately against random IP
addresses pose by far the greatest threat to someone who has no enemies.

And that's why I'd like to know how effective this method is against those
scripts. You say "some" of the mass exploitation scripts. Can you
elaborate on that? Which ones doesn't it protect against. That's what I'd
like to know.

So far the answers to my question were only theoretical arguments that I
was already aware of, but no one has pointed out a past exploit that would
have worked with my changed paths scheme. Maybe I should rephrase my
question:

======================
I tell you now that I've been running a Linux server for the past 5 years,
which I have set up so that all of my paths start with /root, i.e.
/root/bin, /root/usr/bin, /root/etc,...
Although I've been DOSed and some services have been crashed, I have not
been rooted a single time during those 5 years.

I claim that the reason why I was never rooted is my special setup. It has
made all of the exploits against Linux boxes that were used in the past 5
years non-functional against my system (aside from the DOS/crash aspect).

To prove that my claim is incorrect you'll have to point me to an ACTUAL
EXPLOIT/WORM/VIRUS (or report about such an exploit) ACTUALLY USED during
the past 5 years that would have worked WITHOUT CUSTOMIZATION against my
system.
======================

I hope that this is more clear. This is what my question is about. I'm not
interested in comments about the effort involved or how it would be
trivial to rewrite exploits or how obscurity is bad,...  I'm aware of
these theoretical issues myself. I'm asking about the practical side of
things, i.e. what actual root exploits do exist in the wild right now that
are ignorant of system paths (and by extrapolation how likely it is that
future exploits will be ignorant of system paths).


> Besides, if everyone tried what you suggest, shellcode would just move
> away from /bin/sh.

Fortunately this will not happen. The standards you mentioned protect me
against this. RedHat, SuSE,... can not implement this method, because they
can not break standards. This is a method that can only be implemented by
random weird individuals such as myself.

MSB

-- 
Who is this General Failure,
and why is he reading my disk ?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ