Re: [Full-Disclosure] No shell => secure?

From: Matthias Benkmann (matthias_at_winterdrache.de)
Date: 07/09/04

  • Next message: Wall, Kevin: "Re: [Full-Disclosure] No shell => secure?"
    To: full-disclosure@lists.netsys.com
    Date: Fri, 9 Jul 2004 20:27:44 +0200
    
    

    On Thu, 8 Jul 2004 22:34:18 -0400 hax <uberhax@gmail.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 ?
    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html
    

  • Next message: Wall, Kevin: "Re: [Full-Disclosure] No shell => secure?"

    Relevant Pages

    • Re: Tipping in LV + real estate commissions
      ... >>I'm terribly sorry that I don't come up to your standards>concerning my level of tipping. ... God knows what the server you stiffed the last time you ate there will do to your entree. ... As home prices>increased, not only did the commission level increase, so>did the rate. ... > In the real estate business, this meant that the broker>and agent got a bigger slice of a bigger pie. ...
      (alt.vacation.las-vegas)
    • Re: NTP on local networks
      ... Given all the mention of NBS, someone should point out the the OP appears to actually be working at the National Bureau of Standards, which has been called NIST for... ... How can I configure a client/peer to always accept a server as "good ... Just about every country has it's own "standard" clock and they go to great lengths to ensure that all these clocks are accurate and stable. ...
      (comp.protocols.time.ntp)
    • Re: Why is an eMail to karl@202.34.123.45 not possible ?
      ... and a running mail server but NO domain associated with it. ... I tried to send several times from serveral mail accounts from all ... format specified as part of the IPv6 standards. ... When I tried it without the brackets, Outlook accepted the address, but the message never arrived. ...
      (microsoft.public.windowsxp.network_web)
    • Re: How to return a user-defined data type object from a webservice?
      ... John Saunders | MVP - Windows Server System - Connected System Developer ... It's just not how Web Services works. ... Web Services standards. ... when you create a Service Reference (the WCF equivalent of a Web Reference), ...
      (microsoft.public.dotnet.framework.webservices)